Almost every development organization is now experimenting with AI. Yet the results often fall short of expectations: individual employees work faster, but the team as a whole doesn’t always. At The Product Owner Event 2026, we co-hosted the “AI-Augmented SDLC” workshop three times with our strategic partner, Trivium eSolutions. In this article, we share the key takeaways: why organizations get stuck, how they can assess their AI maturity, and what steps they can take tomorrow.
On October 1, about a thousand visitors came to Rotterdam Ahoy for the fifth edition of The Product Owner Event. We were a sponsor of the event. In all three workshop sessions, our CEO Jaap Merkus introduced the speaker: Maarten de Jong, Managing Director of Trivium Benelux. During the interactive portion, Jaap and our colleague Anneke van der Putten helped the participants get started. Later that day, Jaap delivered the keynote address titled “AI: An Ill-Posed Problem.”
It’s no coincidence that we ran this workshop together with Trivium eSolutions. Since June 2026, NetRom and Trivium have been part of the Software Engineering Group, a growth platform backed by Investcorp Technology Partners. Trivium has approximately 180 employees in Germany, the Netherlands, and India. The company specializes in Industry 4.0, smart infrastructure, IoT, and AI applications for manufacturing companies. Both companies retain their own identities but invest jointly in AI solutions.
Context Determines the Outcome
Maarten opened each session with a statement that divided the audience: ChatGPT is not a large language model (LLM). One participant immediately saw why: ChatGPT is the application that allows users to work with underlying language models. “Exactly,” Maarten replied. According to him, the LLM is behind ChatGPT, which serves as an interface. For those who want to integrate AI into the software development lifecycle (SDLC), what matters most is how such a model handles context.
“A model doesn’t know facts, only probabilities,” Maarten said. Such a language model estimates the probability of possible subsequent tokens - pieces of text that make up a response. Which tokens it generates depends in part on the context it’s given. “The tokens themselves aren’t that exciting,” Maarten explained. “It’s the context you provide the model with that makes all the difference.”
The game of telephone in the development pipeline
It’s precisely when passing on context that things go wrong in many organizations. A product owner has a complete picture of a new feature and has the AI turn that into a requirements document or wireframes. The UX designer then refines that output in a new session using their own AI tool, followed by engineering and QA - each time without the original context.
“It’s a bit like the game of telephone you used to play,” said Maarten. In the end, QA tests something that leaves the product owner wondering where it all went wrong. According to Maarten, technology won’t solve that on its own. “In fact, AI will only amplify the problem.”
In his view, AI is nothing more than a mirror of the processes you already have. If those processes have gaps, AI will only make them bigger. A developer who works faster because of AI, but lacks context, is more likely to build the wrong product.
Four Levels of AI Maturity
To determine where an organization stands, Maarten used a framework inspired by McKinsey. It describes four levels at which AI supports software development and provides a framework for discussing an organization’s AI maturity.
At Level 1, software development relies almost entirely on people. Employees may occasionally use Copilot or ChatGPT, but there is no systematic, measurable acceleration yet. “If we want to speed things up, we hire more people,” Maarten summarized.
According to McKinsey, most organizations are at Level 2. Teams have access to AI tools, and there are guidelines for their use, sometimes supplemented by training on work standards. Individuals use AI effectively, and some teams already share context - for example, via a repository or Confluence. These agreements often apply only within their own team or project. As a result, AI primarily accelerates individual tasks, but not yet the development pipeline as a whole.
At Level 3, AI automates entire steps in the development pipeline, such as turning a feature into code, tests, and documentation. Not every intermediate step needs to be performed or checked manually anymore. However, people retain control over quality and over decisions that impact production. According to Maarten, most companies want to move toward this level.
At Level 4, teams of AI agents carry out most of the design, development, and testing work under human supervision. Maarten has not yet seen such organizations himself. He also notes that, according to McKinsey, they have not yet been implemented in practice. “You won’t be replaced by AI, but your role will change,” he said.
Source: McKinsey, 'The AI revolution in software development', Rewired, 2nd edition (Wiley, 2026)
Three layers that enable trust
According to Maarten, the transition from Level 2 to Level 3 revolves around one question: Do you dare to entrust an entire process step to AI? That trust requires an approach in which all roles and AI tools can work with the same, up-to-date information.
Maarten cites the “substrate” as the foundation: a shared context layer for the entire organization, from business to technology. “Think of it as a large Wikipedia page where all the context for a project, a client, or an environment is recorded in a structured way,” he explained. AI tools can access that context via APIs and MCP servers. As an organization, you want to control access and integrations so that teams don’t become dependent on untested solutions. Because everyone draws from the same source, Maarten says it matters less whether a team works with Claude, Codex, or Copilot.
On top of that come skills and gates. Skills are defined work standards that an AI model can use for a task, such as structuring a pull request. This limits the model’s scope for free interpretation. A residual risk remains. “It is and always will be AI: a game of chance,” Maarten warned.
Gates are designed to limit that residual risk: automated quality checks that halt work if it doesn’t meet predefined requirements. Maarten prefers to place them in the deployment pipeline. “You don’t want the AI to check its own work,” he said. “After all, a butcher doesn’t inspect his own meat.”
Skills increase the likelihood of usable output, while gates reduce the risk of errors slipping through unnoticed. If any one of these three components is missing, it becomes more difficult to automate process steps responsibly, and you’re more likely to get stuck at Level 2. With shared context, skills, and gates in place, you can consciously determine when a human should step in.
Who keeps the shared context up to date?
The same question kept coming up from the audience: who manages that shared context? According to Maarten, there aren’t yet any widely accepted best practices for this. Among his clients, that task falls to whoever is already responsible for the agreements, such as the QA lead and the head of software. Whoever currently determines what a pull request looks like will soon document that in the shared context.
One participant offered a tip that Maarten immediately adopted: define what terms mean within your organization. What one team calls a “parking item” might be called something else elsewhere. With a shared glossary, AI can better interpret those terms. “That’s a great addition; I’ll definitely put that into practice,” Maarten responded.
Start small, he advised. Among the clients Maarten currently works with, organizations are starting with two or three frontrunner teams in which every role in the development cycle is represented. Their mission is to run a single work package through the development pipeline fully automated within three sprints. According to Maarten, 30 to 40% of the skills and gates they develop in the process can be transferred to other teams.
Existing Systems and Security
One participant noted that the model works well for new projects, but that existing applications are more challenging. At a multinational where Maarten works, four to five frontrunner teams are rolling out the model in separate workstreams for new builds (greenfield) and legacy systems (brownfield). The latter group clearly faces a tougher challenge. According to Maarten, it starts with the question of why a system has ended up in that state—for example, due to an outdated programming language. The viability of the application determines whether the investment makes sense.
Maarten sees security as the biggest pitfall. Faster delivery is only beneficial if quality remains at least the same, including security. “Can you provide the same security guarantees and maintain your quality gates?” he asked. If the answer to that is uncertain, then the math doesn’t add up yet.
Maarten advises against abandoning existing workflows too quickly. As long as you don’t hand the work over entirely to AI, you’ll need monitoring in tools like Azure DevOps. “Otherwise, who will be held accountable if a bug makes it into production?”
Five Questions to Determine Your AI Maturity
During the interactive session, participants used five questions to explore how mature their organization’s AI practices are. You can also go through these questions with your own team. Think of it as a practical reflection exercise, not a formal maturity assessment. Any doubt counts as a “no.” The first “no” indicates where you can start.
- Does your team use AI daily in the work you deliver?
- Can someone who wasn’t involved in a decision figure out why that choice was made?
- Can a new team member follow your work agreements without anyone having to explain them?
- Is a story only marked as “done” when there’s proof that the functionality works?
- Is there work done by AI that you no longer review because you trust it?
If you answer “no” to the first question, that indicates Level 1. A “no” to the second question points to a lack of shared context; to the third, to missing skills; and to the fourth, to weak gates. According to this exercise, anyone who answers only the last question with “no” is close to Level 3. The foundation is there, but the trust to let go isn’t yet.
In small groups, the participants discussed why progress is stalled in their organizations. Jaap and Anneke joined in and contributed their thoughts. Everyone wrote down one thing they would do differently the next day, without needing a manager’s approval. The path to Level 3 begins with small steps, such as a shared glossary or a definition of “done” that requires proof of working functionality.
Smartly Integrating AI into Your Development Process
For IT decision-makers, the key is to embed AI into the way teams collaborate. An extra license or a new tool does little to change the game of passing the buck. What does help is a shared context with documented work agreements and checks you can rely on. This requires developers who use AI while remaining focused on quality.
At NetRom, our developers have been using AI and automation technology for years as tools to help build software. People remain in control: we establish work agreements, review delivered code, and ensure it remains understandable to our own team. This helps good developers become even better with AI. We share this approach and philosophy with Trivium.
Are you curious about how you AI successfully integrate AI into your SDLC? Or would you like to discuss where your organization stands right now? Then schedule a no-obligation consultation with our specialists. We’d be happy to show you how our AI solutions can contribute to your digital ambitions.
Schedule a no-obligation consultation about AI in the Software Development Lifecycle.