Engineering AI into the product development lifecycle

AI is already changing how software is built. Google Cloud’s DORA research, based on nearly 5,000 technology professionals, found that 90% now use AI at work, spending a median of two hours a day with it, which translates to roughly a quarter of the working day.

In many organizations, the focus is on what happens at the end of the lifecycle: how much code is generated, how many steps are automated, how quickly code is shipped. While those are visible signals of progress, they can be divorced from actual value. Google’s DORA research found that while AI adoption lifts delivery throughput, it also increases instability: more software shipped less predictably.

The more impactful change is happening earlier in the lifecycle. Requirements, design and test strategy shape everything that follows. When those stages are structured correctly, downstream execution becomes faster, more consistent and easier to control. When they are not, issues tend to carry through the entire system, regardless of how much automation is applied later.

The Standish Group’s CHAOS research has consistently put insufficient user involvement and incomplete and changing requirements at the top of the list of reasons projects fail, with only around 31% delivered on time, within the budget and matching the intended scope.

Generalist models are good at producing plausible early-stage work, but can fall flat when outcomes are measured holistically. Setting off in the wrong direction can have lasting consequences. It carries through design, into code, into test cases written against the same flawed assumption.

This is why building AI into software engineering is less about adding tools to existing workflows and more a wholescale reconsideration of the product development lifecycle.

Building narrow agents into the lifecycle

The most effective approach is to break the product development lifecycle into modular agents with narrow scope: one converts discovery material into structured requirements, another produces technical design, the other generates and runs test strategies. Narrow scope keeps each agent’s context manageable and its output consistent.

Importantly, this creates clear points of control. At each stage, AI proposes and progresses the work, while human roles review, challenge and approve before it moves forward. As a result, features can move from discovery to production-ready code far faster than before: design cycles compress, and test scripting that took four engineers can be handled by one, freeing up time for higher value work.

Those checkpoints matter because plausible output is the hardest kind to catch. Stack Overflow’s 2025 survey found 66% of developers name “AI solutions that are almost right, but not quite” as their single biggest frustration, and 45% say “debugging AI-generated code is more time-consuming.”

Without a review gate at each stage, that cost compounds rather than surfacing. GitClear’s  AI Code Quality research shows the trade-off more clearly: refactoring line moves are down 70%, and long-term legacy maintenance is down 74% versus 2022 levels, yet copy-paste, code block duplication and other indicators of technical debt continue to rise.

Governance calibrated to risk

None of this is safe without governance designed in from the first step and calibrated to risk. In practice, that means deploying agents in read-only mode before they are given authority to act. It means setting confidence thresholds before any routing decision is automated. This requires human sign-off on novel exception types even after an agent has proven reliable, and keeping a full audit trail across every decision point.

Much of the market is not there yet. The Cambridge Centre for Alternative Finance’s 2026 Global AI in Finance Services report found 78% of regulators rate explainability as critical or important to their objectives, while only around half of industry firms have adopted explainable AI methods. That gap illustrates how governance expectations continue to outpace implementation.

This discipline runs in two directions. We hold ourselves to it internally, in how we engineer, because anything we build for a regulated market has to survive that scrutiny first. It also must hold in the client’s environment: the firms we build for answer to regulators for every automated decision, so governance cannot be bolted on at the end – it needs be present at every step.

Clients in regulated markets need determinism and explainability. A system that runs end-to-end without a traceable, governed path is hard to put into production, however well it performs in a demo.

Measure the outcome, not the output

Counting volume is easy: more agents, more generated code, more automated steps feel like demonstrable progress. The metrics that matter include quality, real-world outcomes and cost to build.

One example: building connectors between Xceptor and third-party platforms through a conventional engineering process could take around two weeks. Running the same build through the AI-native product development lifecycle – agents generating requirements, design documentation, code and test strategies, with engineers reviewing and steering at each stage rather than producing from scratch – took two days. For clients, that difference means integrations stop being a bottleneck on go-live. Total cost to build also fell 83 per cent, including AI token spend.

Another example is the first agent we built for financial institutions, focused on extracting data from trade confirmations. Firms are often managing large volumes of confirmations which arrive in unstructured formats across document types, such as emails, PDFs and SWIFT messages – and extracting this data is where AI agents excel, delivering significant efficiency and accuracy gains.

From doing to directing

Building an AI-native product development lifecycle changes what engineering work looks like. As agents absorb repeatable execution, the human work concentrates on judgement: architecture, edge cases and steering output rather than generating it.

We found that after a short time, our engineers were no longer producing first drafts; they were reviewing and refining agent output. Sometimes they corrected the outputs, but more and more they were able to approve what was generated. The cognitive load moved from production to verification. This shift from making to directing and validating is the clearest sign of a maturing AI-native engineering model.

Eventually, we will think less as fixed teams and more as cells – product roles and builder roles working alongside AI, each person operating above the task they used to own. The role of a QA Engineer will shift towards creating the paved roads and guardrails that humans and agents use, enabling quality to be built in consistently across every cell.

It would be dishonest to frame this only as acceleration. When work you have done for years becomes something you direct rather than do, that is a real adjustment, and leaders who pretend otherwise may lose their best people to organizations that manage the transition better. Mandating tools is not the same as helping people use them well; in our experience it produces more licenses installed, not more work changed. Adoption comes from champions, role-specific playbooks and measuring delivery outcomes: a people-first approach rather than a procurement one.

None of this works without both sides. True AI-native product development depends on continual, close collaboration between humans and machines. Years of domain knowledge, paired with the speed and pattern-recognition of these systems, is what makes the outcomes better, not the technology on its own. That combination is what makes the process repeatable at scale.