# Goal Is NOT More AI: Building AI-Native Engineering Organizations for Sustainable Productivity

* * *

Somewhere in your organisation right now, a dashboard is showing a healthy deployment frequency, a stable change failure rate, and a throughput line that ticks gently upward. Leadership is satisfied. The AI investment looks like it is paying off.

And somewhere in the same organisation, a senior engineer is on their fourth review pass of a pull request that looks immaculate — well formatted, thoroughly commented, syntactically flawless — and that quietly reimplements a utility function which already exists in three other places in the codebase.

Both of these things are true at the same time. Your metrics can only see one of them.

That is the productivity puzzle. Not that our measurement frameworks are wrong, but that every one of them was designed for a world in which a human being wrote every line of code that reached production. That assumption no longer holds, and the frameworks have not been rebuilt around its absence.

* * *

## Part 1: AI changed how we build software. Measurement did not follow.

![](https://cdn.hashnode.com/uploads/covers/656dd45a61b85466308cb1de/c751f264-52fa-42c0-aef4-1f02717454e8.png align="center")

![AI Changes How We Build Software — a comparison of the traditional human-centric delivery pipeline against today's human-plus-AI pipeline, with the new actors, signals and risks that older metrics cannot see](PLACEHOLDER_IMAGE_1_URL align="center")

*The old pipeline had one author. The new one has five, and only one of them can be interviewed about their reasoning.*

The traditional delivery pipeline was linear and legible. A developer wrote code, opened a pull request, a peer reviewed it, tests ran, it deployed. DORA metrics fit that pipeline perfectly because every stage had exactly one kind of actor in it.

Today's pipeline has the same stages and a fundamentally different cast. A developer now orchestrates GitHub Copilot at the keystroke level, Cursor at the file level, Claude Code at the task level, and Devin at the work-item level — often within the same afternoon, sometimes within the same feature branch. Review is a human-plus-AI activity. Testing is AI-assisted. The stages look identical on a diagram, which is precisely why the change is so easy to miss.

Six things changed underneath the diagram:

**New actors.** AI agents are now active participants in delivering code, not tools that assist a participant. A Devin session that picks up a ticket and returns a merged pull request has behaved like a team member, and needs to be evaluated like one.

**New signals.** Tokens, sessions, acceptance rates, agent-compute units. These did not exist in any framework's data model three years ago, and there is no obvious place to put them.

**A new attribution problem.** Which tool or agent contributed what? Older metrics cannot tell, because they never needed to. This is the single most consequential gap, and I will come back to it.

**New quality risks.** AI-generated code introduces defects, rework and technical debt in patterns that differ from human error. Not necessarily more of them — differently shaped ones.

**Human factors under new pressure.** Cognitive load, trust and flow can improve dramatically with good AI tooling. They can also collapse. Both outcomes are compatible with rising throughput.

**New economics.** Seats, tokens and ACUs are a real line item that must be tied to real outcomes. Nobody had to justify cost-per-merged-pull-request in 2021.

### Why this is genuinely a problem

High AI adoption can conceal declining quality, because the two move in opposite directions on a lag. More code and more pull requests are not better outcomes — they are more code and more pull requests. Activity metrics, when they become targets, reward exactly the behaviour you do not want. And without attribution you cannot prove return on investment to a CFO who is, quite reasonably, going to ask.

The evidence base has caught up faster than most measurement programmes have. GitClear's 2026 maintainability research, drawn from four years of code-change data, found duplicated code blocks rising to their highest level on record — an 81% increase over 2023 — alongside a 41% rise in within-commit copy/paste and a 47% rise in error-masking constructs. In the same window, the share of changes that touch code last modified more than twelve months ago fell by 74%. AI writes new code enthusiastically and maintains old code reluctantly.

Google's DORA research established the delivery-side version of the same finding: each additional increment of AI adoption correlated with measurably more instability. And a review of 470 open-source pull requests found AI-generated code producing roughly 1.7x the issues per pull request compared with human-authored code.

None of this is an argument against AI coding tools. It is an argument that shipping faster and building something durable are now two separate measurements, and most organisations are only taking one of them.

* * *

## Part 2: No single framework tells the whole story

![](https://cdn.hashnode.com/uploads/covers/656dd45a61b85466308cb1de/d66d9eb8-a286-4dff-a3b5-5f9845d97a9e.png align="center")

*Five layers, four questions, one model. The frameworks are not competitors — they are strata.*

The instinct when facing this gap is to pick a framework. That instinct is wrong, and it is wrong in a specific way: DORA, SPACE and DX Core 4 do not compete for the same job. They answer different questions at different altitudes, and the useful model is a stack rather than a shortlist.

### Layer 1 — How we build software

Human developers plus Copilot plus Cursor plus Claude Code plus Devin. This layer answers *how are we building software?* It is where all the new telemetry lives: sessions, acceptance rates, token spend, agent invocations.

It is also the layer most likely to be mistaken for a scorecard. It is not one. Everything here is diagnostic input — useful for understanding what is happening, actively harmful if reported as achievement.

### Layer 2 — DORA

Deployment frequency, lead time, change failure rate, recovery time, and rework rate. DORA answers *are we delivering software better?*

DORA is the most rigorously validated of the three and the most stable over time. It has also evolved: reliability arrived as a quasi-metric, rework rate was added in 2024, and the 2025 report replaced the old Elite/High/Medium/Low ranking with seven team archetypes that blend delivery performance with human factors like burnout and friction.

Its limitation in an AI world is structural: **DORA is provenance-blind.** Deployment frequency does not care whether Devin or a human wrote the change. It will faithfully show you the effect of your tooling and never tell you which tool produced it.

### Layer 3 — SPACE

Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow. SPACE answers *are developers productive and effective?*

SPACE is the most intellectually complete of the three and the hardest to operationalise, because it deliberately prescribes no metrics — it gives you the dimensions and expects you to design the instruments. Most teams that attempted a SPACE rollout from scratch abandoned it within a quarter.

But SPACE has one property nothing else has: it is the only framework with a properly theorised home for **trust**. Given that industry surveys show developer trust in AI output falling from 40% to 29% even as adoption climbed past 80%, and that a majority of developers report not always checking AI-generated code before committing it, this is not a soft metric. It is a leading indicator of the risk you are accumulating.

My recommendation: do not run SPACE as a reporting framework. Run it as the **design review checklist** for whatever measurement programme you are building. It is exceptionally good at catching the moment you have accidentally built something that is 80% Activity data.

### Layer 4 — DX Core 4

Speed, Effectiveness, Quality, Impact. Core 4 answers *are engineering investments creating business value?*

Released in December 2024 by DX with the DORA, SPACE and DevEx authors collaborating, Core 4 exists because executives kept asking "so what exactly should we measure?" and getting "it depends" as an answer. It is unapologetically prescriptive: four dimensions, sixteen metrics, one key metric per dimension. The dimensions are deliberately oppositional — speed that costs you effectiveness is not a win, impact that costs you quality is not a win.

Two things to know before adopting it as-shipped:

First, **Speed's key metric is diffs per engineer, and AI mechanically inflates it.** If you roll out Core 4 across four AI tools without modification, throughput will rise, you will report a win, and the durability cost will surface two quarters later in your codebase. Always pair it with pull request size distribution — otherwise you are measuring fragmentation.

Second, **Core 4 ships no native durability metric.** Code turnover and duplication have to be added into Quality yourself.

What Core 4 uniquely provides is the Impact dimension — percentage of engineering time spent on new capabilities versus keeping the lights on. It is the only place in any of the three frameworks where a cost-per-outcome question about an autonomous agent can legitimately live, and it is the number that actually changes funding conversations.

### Layer 5 — Business outcomes

Better developer experience, better code quality, faster delivery, sustainable productivity, AI ROI, better products, faster innovation, cost optimisation.

This is what the board sees. Notice what is not on this list: acceptance rates, token consumption, and seat counts.

### The stack in one line

DORA tells us how we deliver software. SPACE tells us how developers experience delivering it. DX Core 4 tells us whether any of it creates business value. Together, and only together, they form an AI-native productivity model.

* * *

## Part 3: The flychain — why the top of the stack matters most

![](https://cdn.hashnode.com/uploads/covers/656dd45a61b85466308cb1de/8ee79b40-4447-4cdf-9809-e51d331bd66d.png align="center")

*Small improvements at the top compound into disproportionate outcomes at the bottom. This is why developer experience is a business metric.*

Here is the argument that most measurement programmes miss entirely, and it is the reason I keep the flychain in front of leadership rather than a dashboard.

Engineering productivity is not a flat set of independent metrics. It is a chain, and the links are causal.

**Reduce cognitive load** — less mental overhead, fewer context switches, clearer tasks. Evidence: lower context switching, fewer interruptions, higher task clarity.

**Which improves flow state** — developers stay in the zone longer. Evidence: more uninterrupted focus time, higher deep work time, higher flow scores.

**Which improves reviews** — better prepared pull requests, sharper reviews, faster feedback loops. Evidence: faster review cycle time, higher first-time approval rate, lower review effort per pull request.

**Which improves quality** — fewer defects, less rework, stronger maintainability. Evidence: lower defect escape rate, lower rework rate, higher code quality scores.

**Which improves productivity** — teams ship more and waste less. Evidence: higher deployment frequency, shorter lead time, higher throughput.

**Which improves ROI** — lower cost per change, stronger business impact. Evidence: higher engineering ROI, lower cost per change, higher value delivered.

**Which produces better products** — customers notice, the business grows, engineers are proud of what they built.

The consequence for measurement is significant. Most organisations instrument the bottom three links, because those are the ones with clean telemetry. But the leverage is concentrated at the top, where the data is qualitative and therefore inconvenient.

This also explains a pattern I have seen repeatedly with AI tooling rollouts: teams report large gains in coding time and near-zero improvement in end-to-end cycle time. The gain is real. It has been absorbed by the review link, which is now carrying more volume, of less familiar provenance, at higher scrutiny. If you only track end-to-end cycle time, you will conclude the tools are not working. The actual finding is that you have relocated your bottleneck.

Which is why the flychain's closing statement is the one worth putting on the slide: **the goal is not more activity, and it is not more AI. The goal is better outcomes.**

* * *

## Closing

The frameworks are not broken. They are incomplete in a way that is easy to miss precisely because each one continues to function perfectly within its original scope.

DORA still measures delivery correctly. SPACE still describes the human dimensions correctly. DX Core 4 still connects engineering to business value correctly. What none of them do — because none of them were built to — is answer the question that now sits underneath all three: *which of these outcomes did the machines produce, and at what cost to the codebase we will still be maintaining in 2029?*

Answer that with provenance, layer the frameworks in the right order, and instrument the top of the flychain as seriously as the bottom. The goal was never more AI. It was never more activity. It was always better engineering outcomes, and the measurement model should say so out loud.

* * *

*If you are running a similar rollout across multiple AI coding tools, I would genuinely like to hear what your durability metrics are showing. The industry data is directional; your codebase is the real evidence.*