01 The Stall

Every engineering organisation has now seen the demo. An agent writes a feature in minutes; a room of senior engineers goes quiet. And then, a year later, remarkably little about how software actually ships has changed.

The bottleneck is not capability. The models are good enough, and getting better on their own schedule. The bottleneck is adoption: turning a personal trick performed in a sandbox into the way a team builds: safely, repeatably, in production. That turn is organisational, not technical, and it is where almost everyone stalls.

There is now evidence for the trap. In the 2024 DORA State of DevOps research, every 25% rise in AI adoption came with a small lift in individual productivity (about +2.1%), and on the very same people a 2.6% drop in the time spent on genuinely valuable work. At the team level it was starker: a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Developers feel faster while the valuable work, and the shipping, quietly slips. Individual speed, spread across the software development lifecycle (the SDLC) without the right guardrails, makes the system as a whole less reliable, not more.

This paper offers two things. A model to see where your organisation actually is: six honest stages, not a hype curve. And a way to move that treats adoption as the real work: small, guardrailed experiments that deliver value and build belief at the same time.

02 Where you are: the six stages

Adoption here is not "how many AI tools do you own." It is a change in two things at once: who builds the software, and what the software is. The model tracks both.

On the left, the team. Engineering is the core; product and UX sit around it; and the place the AI actually lives moves stage by stage, from a chat window in another tab to an agent that owns the control flow. On the right, the architecture inverts: code that calls a model at the edge becomes an agent that calls deterministic code as tools, for the moments the answer must be exact.

The six stages. Left: who builds it, and where the AI sits. Right: what gets built, as the control flow inverts. Most organisations today sit between stage 1 and stage 2.

Almost everything in this model moves: who builds the software, where the AI sits, how the architecture is wired. To read that movement you need fixed points to measure it against. Four things stay put, and they anchor the model at every stage:

• ‍SCOPE : DELIBERATELY NARROW
  Product development: the product organisation and the software it ships. Out of scope: finance, procurement, marketing, HR, support. The narrowness is the point.
• ‍ANCHOR
  The Product Manager: the hinge between the business and engineering. It is where the work enters, not where it lives.
• ‍CORE
  The engineering teams: where the transition actually happens. Engineers stay a mix of senior and junior; architecture is part of the craft, not a separate seat.
• ‍GOVERNANCE BACKBONE
  Technical, not corporate: the delivery pipeline, tests, and delivery metrics. With agents in the loop it matters more, not less.

From deterministic handwork to an agent that calls code.

Two of those anchors are worth a closer look, because together they are what keeps the climb honest at every stage. The delivery metrics tell you whether you are genuinely improving or only feeling faster, which is exactly the trap the DORA data exposes. The engineering discipline is what lets a machine move fast without breaking things. Without both, individual speed quietly turns into system risk.

• DELIVERY METRICS
  ‍Deployment frequency · lead time for changes · change-failure rate · time to restore. With agents, extend to: agent-rework rate · human-intervention rate.
• ENGINEERING DISCIPLINE
  ‍Test-driven development · continuous integration · adversarial review · small, continuous releases · refactoring · collective code ownership.

The stages are honest about the middle: most organisations sit between 1 and 2, and stage 3, where the Product Manager starts owning the specification, is the real climb across the SDLC. It is the hardest step for a reason: it is not an IT upgrade but a business transformation. It asks the Product Manager, and the business behind the role, to change how they decide and specify. A model like this tells you where you stand; the rest of this paper is about how you move.

03 The paradox of our craft

It reads as a contradiction: a discipline built on people and craft, making the case for the machines that now write the code. It isn't one.

AI drives the cost of typing code toward zero. What it cannot do is decide what is worth building, judge whether an answer is actually correct, shape an architecture that will survive contact with reality, or define what "good" means for this product and this business. Those are acts of craft, and their value goes up, not down, as generation gets cheap.

So craft doesn't disappear; it moves up the stack. The scarce, decisive skills become intent and specification, the discipline of how you build, the guardrails that make speed safe, and the coupling between engineering and the business it serves. A team that only got faster at typing has gained the least valuable thing.

One risk hides inside this shift. If juniors never write the ten thousand hours of code that used to forge a senior, where do the next seniors come from? Craft moving up the stack only works if the craft is still taught. That is a deliberate choice: keep training the fundamentals, debugging, how memory and networks actually behave, so the people steering the agents can still tell when the output is wrong. Skip it, and you end up depending on AI output no one inside can still truly understand when it matters most.

04 Ship to learn

You do not roll out AI-native adoption. You move up one experiment at a time, each one small enough to be safe, real enough to deliver value, and visible enough to build belief.

This is less a project than a state of mind. A professional athlete is never done turning pro; the training is the job, permanently. Adoption works the same way: not a programme with an end date and a ribbon, but a standing rhythm the organisation keeps running long after the first win.

The rhythm is simple, and it is the engine of the whole model: pick an outcome that matters, state a hypothesis about how AI could move it, run the smallest experiment that could tell you, measure, and then decide: scale it, adjust it, or kill it. Ship to learn. Repeat.

Not every "let's try AI" is an experiment worth the name. The ones that move the organisation share a set of conditions. Missing any one of them turns the experiment into either theatre or a hazard.

• A real outcome
  Tied to something the business or the team actually feels: cycle time, escaped defects, the roadmap item that never ships. Not "AI usage" for its own sake.
• A falsifiable hypothesis
  Stated so the result can prove you wrong. "If we do X, then Y will move by roughly Z", not "AI will help."
• Guardrails in place
  The delivery pipeline can catch a bad change before it reaches production, so the experiment is safe to run at all. (Section 05.)
• Small and reversible
  Scoped so a failure is a Tuesday, not an incident. If you can't undo it cheaply, it's not an experiment; it's a bet.
• Measurable, soon
  A signal within days, from data you already trust. A result you can only judge in a year teaches you nothing now.
• Time-boxed & safe-to-fail
  A deadline and explicit permission to kill it. The point is to learn, and killing a losing idea fast is a win.

05 Guardrails are a prerequisite now

The DORA finding is the warning label: individual AI speed degrades delivery unless something in the system catches what humans no longer can. That something is the pipeline. So the rule is blunt.

Your delivery pipeline is your AI governance.

Every change earns its way to production through the same gates, and it does not matter whether a human or an agent wrote it: automated tests, static and security checks, an adversarial review, and a controlled, reversible release. Adversarial review is what "peer review" becomes when the reviewer no longer has to be a peer. It can be a person, or a second agent configured differently on purpose, whose job is to try to break the change rather than wave it through.

This stops being optional the moment an agent can open a hundred pull requests a day. Review-by-eyeball doesn't scale to that, and the DORA data shows what happens when you try: a "verification tax" that erases the individual speed-up at the team level. Encoded gates are the only way to say yes to AI-written code without slowing down or breaking production. This is the pace-setter for the whole climb: you do not reach the later stages by adopting more AI, but by making verification automatic, because nothing else keeps up when an agent writes ten times the code.

If that sounds austere, look at who is adopting it. The Linux kernel, arguably the most demanding code-review culture on earth, has agreed a policy for AI-assisted contributions: machine help is welcome, purely machine-generated patches are not, and a human stays accountable for every line. Torvalds' own framing is the tell: developers have complained for years about too little code review, and AI may finally be what fixes it. The strictest pipeline in open source is absorbing AI by leaning on its guardrails, not lowering them. Yours can too.

There is a dividend, and it is the honest reason to be excited. The discipline that makes AI safe (real tests, fast pipelines, small releases) is the good engineering most teams never had the time for. AI finally buys back the hours that used to go to unplanned work and firefighting, and spends them on the craft. The guardrails aren't a tax on going fast; they're what going fast is made of.

_{SOURCE · DORA 2024 STATE OF DEVOPS}

_{Per 25% rise in AI adoption: +2.1% individual productivity, and at the team level −1.5% delivery throughput and −7.2% delivery stability. Individual output up, system reliability down. The teams that kept quality did it with strong delivery practices, not by slowing AI down.}

_{SOURCE · LINUX KERNEL AI-TOOLING POLICY (2025)}

_{The kernel now accepts AI-assisted patches but bars purely machine-generated ones — "human accountability for patches is critical." Torvalds' angle: teams have long lacked review, and LLMs may finally solve that, maintainers report automated review is already useful around 60% of the time. The strictest review process in software is leaning on its guardrails, not lowering them.}

06 Try this: taming legacy with AI

A dozen scattered AI trials feel like progress and deliver none: activity without a target, and the organisation stalls anyway. The way out is to stop experimenting at random and aim the discipline at one concrete business goal, then measure the result. Regaining control of a piece of legacy is the archetype.

Greenfield with AI is fast, fun, and mostly a distraction. The value, and the fear, lives in legacy: the code no one wants to touch, with no tests to catch a mistake, quietly holding the roadmap hostage.

The classic way to modernise it safely is the strangler pattern: wrap the old system, carve out one capability at a time, route it to a new implementation, and repeat until the old core has withered away. It works. What made it painfully expensive was the prerequisite: writing characterization tests that pin down what the legacy actually does, so you can prove the new path behaves identically. That work was so tedious it rarely got done.

That is exactly the work to hand to the machine. An experiment, in the shape from section 04: outcome: cut the risk and cost of replacing a legacy module the roadmap keeps tripping over. Hypothesis: if AI bots generate a characterization test suite that locks current behaviour, we can strangle and replace the module with no regressions. The run: bots write the tests, the pipeline turns them green (your guardrails), then AI helps re-implement behind that safety net while traffic is shifted a capability at a time.

You did this by hand a decade ago, for the systems that could justify it. Now the bots do the tedious part, so it becomes affordable everywhere, and the coverage you were never going to write yourself finally exists.

This already works in the wild. Booking.com, in an account Laura Tacho shared at Sonar Summit 2026, concentrated AI on a concrete, measured delivery goal rather than spreading it thinly, and reported a 16% lift in throughput while holding delivery quality. Speed that showed up in the business, not just in a developer survey.

07 The anchor: where the value connects

This is the pivot between business and IT, and the step most vibe coders quietly skip. Get it right and the value becomes visible to the business; skip it and the gains stay trapped in engineering: real, but unprovable to the people who fund the work.

One claim should shape every decision: AI is a business accelerator, not an IT accelerator. Treated as a developer-tooling upgrade, it stalls at "everyone types faster", stage two, forever. Its real leverage is in the product itself, in what the software does for a customer, which is why in this model AI eventually moves intothe product and not just the toolchain. Value that big cannot be owned by engineering alone.

The Product Manager is the hinge: outcomes and business value on one side, engineering craft on the other. Anchor the work here, with the guardrails already in place, on a problem the business genuinely cares about like the legacy throttling the roadmap, and the result lands in language the business already speaks. Leave it unanchored and the same work still happens, but no one outside engineering can see what it was worth. That is the bridge to the last question: making the value real.

‍

08 Making your AI adoption yield business value

Where you begin is one question. Whether it pays is the one your board will ask, and it is easy to run a year of busy AI activity that never reaches the P&L.

Measure the value, not the tooling. "AI usage" and "lines generated" are vanity metrics; they go up whether or not anything improves. The number that matters is the business outcome the experiment named: time to market, a roadmap item finally shipped, defects that never reached a customer. If an experiment can't be tied to one of those, it isn't ready to run.

Keep it off the IT island. AI's leverage is in the product, in what the software does for a customer, and it belongs across the whole SDLC, not just the coding step. So the people who own product value have to be in the room from day one. Adoption that lives only in engineering plateaus at "everyone types faster," and that speed quietly evaporates before it becomes value anyone outside the team can see.

Craft is the multiplier. The teams that convert AI speed into business value are the ones whose craft moved up the stack fastest: the judgment about what to build, the taste for what "good" is, and the discipline that lets a machine move fast without breaking things. That is not a threat to a people-and-craft organisation. It is the moment craft matters most.

Start with one outcome that matters, one guardrailed experiment, on the seam between business and engineering. Measure the value it creates. Then do it again, and keep going, because the work is never done.

A closing thought: foundations first. We begin in the development track for a reason. First comes discipline, and discipline produces good engineering practices. Good practices produce good data; good data enables good systems. Only on that foundation can you make the right calls, which is what good Product Management and good process are. And only then does business improvement actually stick. The order is not decoration: reverse it and you get a process that barely matters, optimised at speed, on a system built badly, over data you cannot trust. AI does not fix that; it industrialises it.

Most companies are racing straight for that business layer, and most will stall there on generated output nobody can trust. The edge was never speed; it is the foundation that makes speed safe.

_{SOURCES & REFERENCES}

1. _{DORA: Accelerate State of DevOps Report 2024 (Google Cloud / DORA), Figures 7 and 10. Per +25% AI adoption: +2.1% productivity, −1.5% delivery throughput, −7.2% delivery stability — verified against the report PDF.}
2. _{DX: Highlights from the 2024 DORA Report: the "verification tax" and team-level outcomes.}
3. _{Baseflow: AI-native Product Development Adoption Model (internal): the six stages, the anchor, and the guardrails backbone.}
4. _{Model landscape context: Gartner, Maturity Model for AI-Native Software Engineering (2026); SEI / Accenture, AI Adoption Maturity Model (2026).}
5. _{Technique: Martin Fowler, StranglerFigApplication; Michael Feathers, Working Effectively with Legacy Code (characterization tests).}
6. _{Linux kernel:" Toward a policy for machine-learning tools in kernel development (LWN, 2025): AI-assisted patches welcome, purely machine-generated ones barred, humans accountable; review named as AI's best use.}
7. _{Booking.com throughput figure: Laura Tacho, session on the transformation toward an AI-native SDLC, Sonar Summit 2026 (YouTube); consistent with the DX summary above.}