The promise sold in 2023 was simple and seductive: "with AI in the editor, your team will ship two, three, ten times more". Reality landed. Teams that adopted AI only for writing code hit, almost without exception, a productivity plateau at around 40% in gains. Not 10%. Not 200%. It is a specific number, repeated across studies from Cursor, GitHub, McKinsey, DORA, and in internal measurements from companies that had the discipline to measure seriously.
This plateau is not a failure of the model, not a failure of the prompt, not a failure of the team. It is the mathematical consequence of something simple: we replaced one of the six phases of the development cycle and kept the other five running exactly as before, processes that were designed when code was expensive and that lost their purpose when code became a commodity. This post shows why the plateau appears, what the anatomy of the six phases is, what each one becomes in the post-AI world, and how serious engineering teams are breaking through that ceiling. Spoiler: the answer is not another autocomplete plugin.
The math of the plateau: why 40% and not 80%
Think of the delivery cycle of a feature as a chain of six links: Planning, Code, Review, Security, Ship, Retro. Each link consumes time. If you multiply the speed of one link by 50x and leave the other five unchanged, total time drops, but only up to the limit of what that link represented in the whole cycle.
In mature teams, raw code writing rarely represents more than 30 to 40% of the time on a feature. The rest goes to understanding the problem (planning), reviewing peers (review), passing through SAST/DAST and audit (security), preparing the release, monitoring and rollback (ship), and closing the cycle with learning (retro). When you reduce the "raw code" slice from, say, 35% to 1% of the cycle, you gained 34 percentage points, and stalled right there. Hence the 40%. It is arithmetic, not mystical.
Continuing to push the same lever past that point becomes ridiculous: more autocomplete will not give you more speed, because the wasted time is no longer in the typing. It is in the other five phases that remain a purely human bottleneck.
The 6 phases of the cycle, seen anew
To break the plateau, you have to look honestly at what each phase does today and what it can become with AI applied intentionally.
1. Planning, where most of the invisible debt lives
"Planning" includes figuring out what to build, translating a business need into desired behavior, listing acceptance criteria, identifying risks and dependencies, aligning with product, design, and stakeholders. In many teams, it is the phase that consumes the most senior engineering time and the one that yields the least code per hour spent.
The AI gain here is not in "writing tickets faster". It is in turning conversations, audio, emails, and documents into living specs with verifiable acceptance criteria (Spec-Driven Development). Agents that ask about the forgotten edge cases, that suggest error scenarios, that compare with similar features in the codebase and detect contradictions with what already exists. Teams that apply AI seriously here jump 20 to 30% in extra productivity before the code even starts.
2. Code, the phase already won
This is the phase everyone optimized. In studies from Cursor, modern tools reach 98% of AI-assisted generation inside the editor. It is no longer an interesting problem. What remains of human engineering here is: architecture, trade-off decisions, pattern choice, complexity management, and reading the code the AI proposes. Typing itself became effectively free.
Practical conclusion: stop debating "which model writes better code" and start debating "how the rest of the cycle absorbs the increased output of this phase without turning into a drama".
3. Review, the new bottleneck, and the worst of them
When code was expensive to produce, review was careful because there was time. Each PR had 150 lines, took 30 minutes to review, and no one opened more than 2 PRs per day. Today, with AI writing 98% of the typing, the same person opens 6 to 10 PRs per day, each with 400 to 800 lines. Review time simply does not scale along with it.
The effects are predictable and perverse: shallow reviews ("LGTM"), a growing PR backlog, multiplying merge conflicts, quality dropping silently, and the senior team becoming bottlenecked in review instead of thinking about architecture.
What works: AI as the first reviewer, with explicit criteria (security, performance, conformance to the internal style guide, tests covering acceptance criteria, behavior regression). The human steps in for what is genuinely human: alignment with product intent, non-obvious architectural decisions, and technical ethics. Without this change, every gain from phase 2 evaporates here.
4. Security, the bottleneck that shows up on audit day
Static analysis, vulnerability scanning, dependency review, LGPD/GDPR compliance, threat modeling, secrets access control. Traditionally, these steps ran in the pipeline with a human interpreting the result. With 10x more code per sprint, the volume of findings explodes and the security team becomes the new bottleneck.
What changes: AI classifying severity and context, separating false positives from real risk, suggesting a fix, and automatically opening a remediation PR. Security agents that run threat modeling on top of the spec before the code exists, instead of only auditing afterward. Teams without this will discover the problem at the wrong moment: during the SOC2 audit or on the day of the incident.
5. Ship, where "done" becomes "in production"
Build, integration tests, deploy, feature flags, observability, rollback plan, internal communication, documentation updates, stakeholder notification. Each of these steps individually seems small; added together, they consume hours per release. And in many teams they still depend on one specific person who "knows how it is done".
What works in 2026: agents that automate release preparation (a changelog generated from the semantic diff, not the commit log), that orchestrate canary releases with decisions based on real metrics, that escalate to a human only for the events that require judgment (schema change, breaking change, critical release). Whoever ignores this, after improving phases 1 to 4, still loses days on the ship.
6. Retro, the phase no one does right (and the one that compounds most)
A serious retrospective is the phase of compound learning: what went wrong, what improved, what changed as a premise, what we are going to stop doing. In teams without AI, retro becomes a 30-minute meeting at the end of the sprint that no one takes seriously. With AI well applied, retro becomes continuous analysis: automatic review of incidents, patterns in abandoned commits, cycle time metrics by feature type, concrete suggestions for process change.
This is where the plateau stops being static: each retro done well improves the next cycle. It is the most underrated phase and the one with the greatest long-term leverage.
The honest diagnosis: which phase is your bottleneck now?
Before buying more tooling, do the diagnosis. For each recently delivered feature, measure the time spent in each phase. If 60% of the time is in review, your next lever is assisted review, not another tool in the editor. If 50% is in planning, invest in SDD and living specs. If 40% is in ship, automate the release. The mistake is throwing more AI on top of the phase that is already optimized.
A clear symptom of a plateau is the recurring complaint of the type "AI writes fast but we get stuck in review" or "code flies out but QA lives in the backlog". These are obvious signs of an unbalanced chain.
Why old processes survive even when they have lost their purpose
Processes do not disappear when they stop making sense. They stay. There are three reasons. Compliance and audit: certain steps are required by regulation, even when they have become theater. Cultural inertia: "we have always done it this way". Fear of taking a shortcut: no one wants to be the engineer who cut a step and caused the incident.
The consequence is that the delivery cycle inherits checks that existed to mitigate the high cost of writing code. When code becomes a commodity, several of these checks can be rethought. Rethinking is not removing: it is redesigning for the new context. Code review stops being "finding a typo bug" and becomes "validating intent and architecture". QA stops being "running a suite that could have run in CI" and becomes "exploring emergent behavior". Whoever does not make this migration keeps the old overhead and the AI gain evaporates.
The 5 patterns that break the plateau in practice
1. AI in every phase, not just in the editor. Assisted spec in planning, automatic reviewer in review, finding classification in security, release orchestration in ship, cycle analysis in retro. Without this, the gain is mathematical: limited to a fraction of the cycle.
2. Redesign of review. AI as the first reviewer with an explicit checklist; the human as the second reviewer focused on intent. Smaller, more frequent PRs (hard limits: 400 lines, 24h open). Merge conflicts treated as a process signal, not as noise.
3. SDD to align the entire cycle. The spec becomes a contract consumed by humans, coding agents, review agents, and test agents. Without a spec, AI fills gaps with assumptions no one agreed on.
4. Evals and metrics as an immune system. Each critical feature has evaluation scenarios that run continuously. A change that regresses quality is detected early. Without this, the perception of "the code feels off" becomes folklore.
5. The right metric for the right cycle. End-to-end cycle time, not "lines of code per day". Average time per phase. Incident lead time. Rework rate. The wrong metric anesthetizes the team against the real problem.
What changes in the tech lead's role
The 40% plateau is also a role plateau. When code was expensive, the tech lead was a multiplier through mentoring juniors and reviewing. Today, mentoring juniors in typing matters less (because AI types better), but mentoring in judgment, architecture, trade-off, and communication with product matters much more. Tech leads who keep being "the best PR reviewer" are being underused; those who migrate to "delivery cycle architect" unlock the plateau.
The cost of not confronting the plateau
The team that sits at 40% for two years loses to the competitor that reached 80% and keeps accelerating. It is not dramatization: it is a compound competitive advantage. Iteration speed is perhaps the metric most sensitive to the plateau. Companies that unlock review, security, ship, and retro with AI start iterating two to three times faster with the same team. In a market that values time-to-market, that delta is the difference between leadership and relevance.
How we approach this at Steply
When we join a team, the first question is not "which tool do you use to write code". It is "in which phase do you lose the most time, and how can that be measured". From the diagnosis, we redesign the real bottleneck, not what is trendy on LinkedIn. In some teams, the leap comes from redesigning review; in others, from SDD; in others, from release automation. The path is not generic, but the method is: measure, find the bottleneck, redesign, instrument, measure again.
What unites all cases: a company that wants to leave the plateau needs to stop treating AI as an "editor tool" and start treating it as a capability that is transversal to the SDLC. It is less about buying and more about designing. Whoever makes this transition now captures two or three years of advantage before it becomes a commodity.
Executive summary
The 40% plateau exists, it is mathematical, and it has a single cause: we replaced one phase of the cycle and kept the other five as they were. Breaking the plateau is not about buying more autocomplete; it is about redesigning planning, review, security, ship, and retro with AI applied intentionally, rethought processes, and honest metrics. Teams that do this jump to 70 to 100% in real gains and keep accelerating. Teams that do not stay stuck at 40% thinking AI "did not deliver what was promised", when the real problem is that AI delivered only what was asked of it.