AI amplifies. Five fundamentals decide which way.
In short
- AI doesn’t fix your engineering: it amplifies it, the good and the bad alike.
- The real question isn’t “are we mature in AI?” but “is our engineering ready to extract real value from it?”.
- Five engineering fundamentals, predating AI, decide what you get out of it.
- What matters isn’t your level on each one, but the imbalances between them.
A team that was doing fine
I remember a team that had just rolled out a coding assistant across the board. Everyone was happy.
Developers talked about saving time. The dashboard showed more commits, more pull requests, more closed tickets.
Then we looked closer:
- the review queue was getting longer;
- pull requests were getting bigger, and sometimes went through without a real review, “to keep moving”;
- a senior couldn’t have rewritten a module they’d just shipped;
- a junior was producing code that nobody, including them, really understood.
Velocity was climbing. Understanding was dropping. And nobody was watching the second curve, because the first one was so reassuring.
This wasn’t a team failing. It was a team becoming fragile, at high speed, without noticing.
I’ve seen this scene replay often enough to think it isn’t an accident. It follows from a question that’s badly framed.
The wrong question
Most organizations ask: “Are we mature in AI?”
That’s an adoption-rate question: enough tools, used often enough, by enough people? Easy to measure, and dangerous for that very reason. It reassures without revealing anything.
Because AI doesn’t get adopted like a neutral tool. It applies to a system that already has its strengths and fragilities, well before the first prompt.
The right question is: is our engineering ready to extract lasting value from AI?
That shifts the focus from the tool itself to the ground it’s acting on.
AI reveals, it doesn’t fix
The idea fits in one sentence: AI doesn’t fix engineering, it multiplies what it finds there: strengths and weaknesses alike.
Long a field intuition, this is now documented. The DORA 2025 report (nearly 5,000 professionals) confirms it: AI is an amplifier, not a fix.
It draws the same conclusion as this article: the question is no longer whether to adopt AI, but how to prepare to extract value from it.
The clearest signal is an asymmetry. Here’s what DORA observes as AI adoption increases:
| Effect of AI adoption (DORA 2025) | Trend |
|---|---|
| Delivery throughput | up |
| Product and organizational performance | up |
| Time spent on valuable work | up |
| Perceived code quality | up |
| Burnout and friction | unchanged |
| Delivery stability | down |
Almost everything improves… on average. But that average hides large gaps: solid teams progress, fragile ones fall further behind (DORA 2025). A rising throughput, on its own, says nothing about the health of the system.
And exactly one indicator drops for everyone: stability (DORA 2025). By accelerating, AI exposes whatever wasn’t solid beforehand: tests, architecture, feedback loops.
And 2024? DORA observed the opposite back then: declining throughput (DORA 2024). The trend reversed in a year. On a topic moving this fast, numbers go stale almost immediately; what endures is the mechanism, not the percentage.
More code, not more value
Here’s the number that sums it all up.
Developers who use AI daily produce roughly four times more code, but the value actually delivered grows by only about 12% (GitClear data, picked up by Addy Osmani, who honestly notes that part of that 12% comes from the over-representation of top developers among AI users).
Four times more code to review, for a tenth more value. The whole gap lives in the one step that didn’t speed up: review.
Osmani puts it well: review used to hold up by a lucky accident of speeds: a senior could read faster than a junior could write. That accident is gone. An agent produces a thousand clean lines in seconds, while human reading speed hasn’t moved at all.
The numbers follow. A 2026 telemetry study of 22,000 developers (Faros AI, picked up by A. Osmani) shows pull requests bloating (+51%), review times multiplying fivefold, and 31% more changes merged with no review at all, a pattern dubbed the “acceleration whiplash” (Faros AI, 2026).
That’s the story of my team: AI didn’t create its problems, it made them faster, and therefore more invisible.
Five things to look at
To know whether your engineering is ready, five fundamentals are enough to get a sense of it. None of them is AI-specific: that’s the whole point: what decides what you’ll get out of AI are practices that predate it. I group them drawing on established references (DORA, Accelerate, SPACE, DevEx, Team Topologies).
| Capability | The question | Fragility signal | Inspired by |
|---|---|---|---|
| Sustainable delivery | Can you accelerate without degrading? | Large batches, bloating PRs | DORA / Accelerate |
| Shared understanding | Do people still understand the system? | Accepted code nobody could rewrite | Team Topologies / DORA 2025 |
| Quality guardrails | Do practices hold under load? | Lightened review, rising debt | Accelerate / GitClear |
| Productive experience | Real gain, or hidden load? | Time saved = time spent supervising | SPACE / DevEx |
| Intentional adoption | Deliberate, or imposed? | ”Shadow AI”, no measurement | DORA AI Capabilities Model |
Two of these do the most damage when missing.
Quality guardrails separate AI that accelerates from AI that propagates debt. Generated code is often well-presented, written with confidence… and subtly wrong. Without a safety net (tests, review), this misleading plausibility goes straight into the codebase.
Shared understanding degrades silently, and it’s the most overlooked angle. Everyone watches technical debt; almost nobody watches cognitive debt.
Lionel Chaine, CIO of Bpifrance, made it the title of an article: writing is solved, understanding isn’t, from his own ground: 600 developers, dozens of agents in production. His observation: even in a mature, regulated organization, producing code has become an almost-solved problem, while understanding it still costs just as much (Chaine, 2026).
The mechanism is insidious: the agent reasons, then discards its reasoning when it produces the code. The reviewer no longer judges an intention: they have to reconstruct it.
And by lowering the barrier to entry, AI removes the “productive struggle” that learning requires. The risk is acute for juniors, whose mentorship erodes when AI does the work in their place (DORA 2025).
The real signal: tension, not level
The trap of “maturity models” is the single score. But the level of each point, taken in isolation, says almost nothing.
A team strong on delivery but weak on understanding is in more danger than an average but balanced team. What’s revealing isn’t the heights: it’s the tensions: the gaps between a strength and a weakness.
The clearest one pits delivery speed against system understanding:
The dangerous corner is top left: shipping fast without understanding is cognitive debt, the one my team from the start fell into. But it’s only one tension among others. Four keep recurring, each pointing to a profile:
| The tension | Strong capability | Weak capability | Profile |
|---|---|---|---|
| Moving fast without understanding | Delivery | Understanding | ● Cognitive debt |
| Accelerating without a net | Delivery | Guardrails | ● Amplified technical debt |
| Loving the tool without a direction | Experience | Intention | ● Opportunistic adoption |
| Pushing without benefit | Intention | Experience | ● Imposed adoption |
Two profiles aren’t tensions but overall states:
- ● Fragile system: understanding and guardrails both at their lowest. A system nobody understands anymore, with no net protecting it: the riskiest of all.
- ● Sustainable accelerator: all five points high and balanced. The only case where AI truly delivers on its promise.
Reading your own situation, then, isn’t about adding up points. It’s about looking at a shape: which strengths, which weaknesses, and above all which ones are in tension.
What this means for leadership
The implication is direct, and a little uncomfortable:
- Stop steering AI by usage rate. Licenses, acceptance rate, volume of generated code can all keep rising while the system degrades.
- Invest in the foundations. Internal platform quality, small batches, guardrails, shared understanding. The DORA 2025 report is clear: the biggest returns come from foundational systems (platform, data, workflows), not from tools.
- Protect junior learning. Pairing, architecture review, sometimes code written by hand. An organization that delegates learning to AI too early is depriving itself of its future seniors.
One caveat, in fairness: foundations aren’t a comprehensive insurance policy. DORA concludes they amplify AI’s benefits; but the Faros telemetry shows that even very mature teams see their review capacity saturate under the generated volume. Foundations turn speed into value: but you still need to build up, downstream, the capacity to review and test.
The limits, because there have to be some
- These five points are a reading grid, not a measurement. They help you look in the right place; they don’t replace actually tracking your metrics (DORA and others).
- The profiles are landmarks, not definitive labels: a real team usually accumulates several tensions at once.
- A profile isn’t a verdict. Its real value is in the conversation it opens, especially when, within the same team, the answers diverge.
To close
AI is neither good nor bad for your engineering: it’s an amplifier.
The more robust your system, the more value it creates. The more fragile it is, the faster it accelerates its decline, often behind a perfectly reassuring velocity curve.
The real question was never AI. It was always your engineering. AI has simply made it urgent.
In a future piece, I’ll propose a short self-diagnostic, I call it ERA, for Engineering Readiness for AI, to help locate these five points and their tensions in a few minutes. In the meantime, the grid above is already enough to ask the right questions, as a team.
Sources
- DORA, State of AI-assisted Software Development (2025): primary source for this article (≈5,000 professionals surveyed). The 2024 edition is cited only for comparison: see the caveat on how quickly the numbers go stale.
- DORA, AI Capabilities Model (2025): seven organizational capabilities that amplify AI’s benefits.
- Forsgren N., Humble J., Kim G., Accelerate (2018): the foundations of the DORA program.
- Forsgren N., Storey M.-A., et al., The SPACE of Developer Productivity (2021).
- Noda A., Storey M.-A., Forsgren N., Greiler M., DevEx: What Actually Drives Productivity (2023).
- Skelton M., Pais M., Team Topologies (2019).
- GitClear, AI Copilot Code Quality (code churn and duplication, 2024-2025). Faros AI, The Acceleration Whiplash (telemetry across 22,000 developers, 2026).
- Addy Osmani, Agentic Code Review (2026): reference synthesis on code review in the age of agents (draws on GitClear and Faros data); source of the “4× code / +12% value” gap.
- Lionel Chaine (CIO, Bpifrance), Writing is solved, understanding isn’t (LinkedIn, 2026): an executive-side echo, from a regulated environment.
The figures in these reports change with every new edition. Verify them at the source before any public reuse.