Myth created out of 12 programmers
The 10x engineer stems from an experiment carried out by Sackman, Erikson and Grant back in 1968, which stated that the best to worst ratio was around 20:1 for code writing and 25:1 for debugging. The figures held out, but not the experimental approach itself. Various commentators observed that the test included both low-level language coders and high-level language coders. Moreover, the reanalysis revealed that only 5:1 was explained by programmer difference. The aggregation of 61 programming studies conducted by Prechelt gave almost the same ratio for median programmers in the two quarters.
Large individual differences exist, but they were recorded when it came to small self-contained tasks performed in lab conditions — exactly those tasks which AI can perform perfectly well nowadays.
AI multiplied generation, not validation
DORA's State of AI-assisted Software Development for 2025 surveyed almost 5,000 practitioners at roughly 90% adoption and sees AI as an amplifier: it amplifies the existing organizational profile. Productivity grew along with adoption; volatility also increased, and faster generation tends to drive software towards making bigger changes. Treat these as cross-sectional correlations, not causal estimates. Teams that successfully adopted AI are not a representative sample; what the evidence reveals is co-occurrence of adoption and productivity, not the effect of licensing on productivity.
Self-reporting is the poorest method we have. METR's randomized control study has found experienced maintainers working 19% slower with early 2025 software, while believing themselves 20% faster. METR has since revised its study design; the size of this estimate may be debated, but the difference between self-report and true productivity remains the finding. In addition, GitClear's maintainability metrics for 2026 show duplicated blocks increasing by 81% since 2023, while refactoring dropped from 21% of lines changed in 2022 to 3.8%. Structural proxy variables, disputed in their interpretation — but in line with generation outpacing comprehension.
Four things we mean by productivity
The debates about productivity and AI are usually just people not talking to each other, since four different constructs all use the same label. Developer productivity is a real construct — SPACE makes it a dimension of developer satisfaction, but METR proves that this construct can turn inside out. Delivery performance is where DORA comes in: it's throughput and stability, at the team level, describing a delivery capability rather than a person. Engineering efficiency is friction: feedback loop speed, cognitive load, flow, as defined in DevEx research. Outcomes of the business or product are the point of all of it.
AI has an effect on the first of these four, the third sometimes, the second perhaps, and the last one barely any evidence of it.
Why traditional measures are even less useful now than ever before
Lines of code, commits, pull requests, story points, hours, and the recently trendy “percentage of code written by AI” all suffer from the same problem – they are all measures of activity, and all of them can be easily pumped up by an overnight agent. A metric which a language model can optimize for during the night is no longer a measure but an incentive to generate something. Incentivize PRs and you'll receive split PRs. Incentivize the percentage of AI-generated code and you'll receive generated code where a change in configuration would suffice.
Alternative measures already exist. Deployment frequency and deployment lead time; change failure rate and recovery time after failed deployments; rework rate (code that is reverted or substantially rewritten in the next two weeks); review effectiveness, measured through escaped defects rather than review latency; service level objective attainment; violation of duplication and dependency rules; outcomes such as feature adoption and incident cost are the better alternatives. One caveat that the DORA guys are themselves stressing: four measures measure delivery capability, not productivity of developers. Misuse them, and you'll bias them.
Two engineers, one quarter
Engineer A is genuinely exceptional. Working with an agent, she delivers a payments reconciliation service in nine days: 14,000 lines, a bespoke retry layer, tests generated alongside the implementation, shipped as one large release. It works. Three months later it has produced two incidents from non-idempotent retries, and it has become a bottleneck - every billing change routes through the one person who understands it. Her throughput is now a queue.
Engineer B is merely strong, but works on a paved road: a service template with idempotency keys and the outbox pattern built in, consumer-driven contract tests at boundaries, trunk-based development behind flags, observability provisioned by default. The same capability takes 15 days across 40 small, independently revertible changes. Four other engineers can modify it, because it looks like every other service. Its dashboards exist without anyone designing them.
Six months out, B's organization ships more billing change per quarter with fewer incidents. Nothing about B is exceptional. The substrate is. A's advantage is bounded by one batch; B's compounds through the system — which is roughly what Team Topologies argues when it treats the platform as a product whose users are other teams.
How seniority pays off if implementation is easy
If the cost of writing code is low, then the limiting factor turns into the constraints. The holy grail of the principal engineer is not a service, but the guardrails that are executable: architecture fitness tests in CI, constraint enforcement, security by default, policies as code, decision recording for machines to act on behalf of engineers and agents to go ahead without requiring agreement on every detail from the designer. The staff engineer who eliminates a whole class of decisions, an idempotency mechanism, a migration strategy – gets leverage that scales with headcount and agents involved.
The quantifiable value of such leverage is obvious: how many agents or people can make modifications to the system without consulting the creator? The horizon – rather than sheer commit rate – is what makes leverage.
10x output, 10x complexity
Generation got cheaper. Review, integration, security analysis, operations, and cognitive load did not. Reviewer defect detection degrades sharply with diff size, so larger batches are not a neutral side effect — they are a tax collected later, in production. Duplicated code imposes a propagation cost on every future fix. Each generated abstraction nobody chose is a maintenance liability with no owner. An organization optimizing for code volume is buying the input that got cheap and paying for the one that did not.
An Engineering Leverage Framework
Five dimensions, none of them individual scorecards:
- Individual effectiveness — judgment on irreversible decisions, review quality, knowledge transferred. Assessed qualitatively by peers and managers; never an automated count.
- Team delivery performance — the four keys, plus batch size and 14-day rework rate.
- System health — SLO attainment, duplication and dependency violations, mutation score on critical paths, and the share of production-critical code with a named human who can explain its invariants.
- Organizational leverage — paved-road adoption, time-to-first-safe-deploy for a new engineer or agent, and DevEx measures of feedback loops, cognitive load and flow.
- Product impact — outcome per unit of delivery: feature adoption, incident cost, time to validated learning.
Three rules make this usable. Aggregate at team level or above. Pair system telemetry with self-report, since neither is trustworthy alone. And keep it out of performance review and stack ranking — the moment these become the basis for individual ranking, they become targets and stop being measurements. Read them as a portfolio: a dimension improving while another degrades is a trade, not a win.
The provocation
The exceptional engineer has not disappeared; the multiplier has moved. It now lives less in the individual's hands than in the substrate they build and work within — architecture, guardrails, platforms, tests, topology, documented judgment. The future likely belongs not to the engineer who writes ten times more code, but to the organization where every engineer, and increasingly every agent, produces more valuable, reliable, maintainable software with less friction and less risk. That is a design problem, not a hiring problem, and it is measurable, provided we stop measuring the wrong thing faster.
