The Task Got Faster. The Release Didn't.

Start with the smallest observable unit of the change: a single piece of work moving through a single team.

A change request arrives that would once have taken a competent engineer three or four days. Read the ticket, find the relevant service, understand how the existing behavior is implemented, write the code, write the tests, run it locally, fix what breaks. With a modern coding agent, a large portion of that finishes inside a morning. The code is not slop. It compiles, it passes the tests it was given, it follows the conventions of the surrounding files reasonably well. An engineer who has been doing this work for a decade looks at the diff and finds nothing embarrassing in it.

The release date does not move.

The change waits for a product manager to confirm what should happen when a customer has two active subscriptions. It waits behind a schema migration owned by another team. It waits for a reviewer who has eleven other pull requests open. It waits for a shared staging environment that a different squad has booked for load testing. It waits for a security exception because it touches an authorization path. It waits for the Thursday release window, which was missed, so it waits for the following Thursday. Then it waits for a customer to notice the feature exists.

The coding task compressed by roughly seventy percent. The end-to-end lead time compressed by close to nothing.

This is not a story about a bad company. It is a description of the ordinary structure of most software organizations above about fifty engineers, and it describes what happens when one stage of a multi-stage system gets dramatically faster while the others stay where they were. The engineer really was faster. The organization was not. Those are different claims about different systems, and the industry has spent three years conflating them.

The conflation is understandable, because for most of the history of commercial software the two moved together. Implementation was the expensive, variable, hard-to-parallelize stage. It was where estimates went wrong, where scope crept, where the schedule was actually decided. If you made coding meaningfully faster, delivery got meaningfully faster, because coding was the constraint. Roadmaps were planned around engineering availability. Headcount plans were essentially bets on how much implementation capacity the company would need. The organizational chart, the budget, and the quarterly planning ritual were all built on an assumption so deep that almost nobody stated it out loud: writing the software is the hard part.

That assumption is now, at minimum, unstable. At the frontier it has already broken. Google has said publicly that about three-quarters of new code at the company is AI-generated and approved by engineers, up from roughly a quarter in late 2024. Across the broader market, DORA's 2025 research found that around ninety percent of technology professionals use AI at work. Telemetry from instrumented enterprises is more conservative than the self-reports, but it points the same direction, with measured AI-authored shares of merged code moving from about a fifth to better than a quarter over the course of a year.

So the interesting question is no longer whether AI can make individual engineers faster at producing code. In many settings it demonstrably can. The interesting question is what happens to an engineering organization when the resource it was designed around stops being scarce, and every other constraint it had learned to ignore becomes visible at once.

Movement I: We Have Been Measuring the Wrong Thing

Almost every widely circulated number about AI and developer productivity answers a narrower question than the person quoting it believes.

Consider the two most cited experimental results in this field, which appear to contradict each other completely.

In 2023, researchers from Microsoft Research, GitHub, and MIT Sloan ran a randomized controlled trial with ninety-five freelance developers recruited on Upwork. Each was asked to implement an HTTP server in JavaScript, passing a fixed suite of integration tests. The group with GitHub Copilot finished about 56% faster, roughly seventy-one minutes against a hundred and sixty-one. The effect was large, statistically significant, and concentrated among less experienced developers.

In July 2025, the nonprofit METR published a randomized controlled trial with sixteen experienced open-source maintainers working on 246 real issues in their own repositories, projects averaging more than a million lines of code on which the developers had roughly five years of prior experience. Before starting, the developers predicted AI would make them about 24% faster. Afterward, they reported that it had made them about 20% faster. The measured result was that tasks assigned to the AI-allowed condition took about 19% longer.

Both studies are competently designed. Both are true. They do not contradict each other, because they are not measuring the same thing.

The first measures how fast a developer with no prior context can produce a self-contained artifact against a known specification with an automated definition of done. The second measures how fast an expert with deep context can make a correct change inside a large system whose invariants live partly in code, partly in test suites, and partly in the maintainer's head. The first is a generation problem. The second is mostly a comprehension and verification problem that happens to require some typing.

This distinction runs through the entire evidence base. Stanford's software engineering productivity program, working from commit-level data on roughly a hundred thousand engineers across six hundred-plus companies with access to private repositories, finds gains that vary by roughly an order of magnitude depending on where the work sits. Low-complexity greenfield tasks show something in the range of thirty to forty percent. High-complexity work in mature codebases falls into the single digits, and a nontrivial share of teams measure a net decrease. Crucially, the same research finds that a large fraction of the gross output gain is consumed by rework, meaning code revised or reverted shortly after it was committed. Netted against rework, the average across industries lands nearer fifteen to twenty percent than the numbers that appear in vendor decks.

Field experiments sit in between. A set of randomized trials run inside Microsoft, Accenture, and a Fortune 100 company measured roughly a 26% increase in tasks completed per week among developers given Copilot, with the effect concentrated among junior and recently hired engineers and much weaker among senior developers working in code they already knew well.

None of these findings are in tension once you accept that "AI developer productivity" is not one quantity. It is a family of quantities that respond differently to task type, codebase maturity, developer seniority, language popularity, tool generation, and study design. Anyone presenting a single headline percentage is either selling something or has not read carefully.

There is a further complication that deserves more attention than it gets. METR's second study, which began in August 2025 with a larger and more diverse pool of fifty-seven developers across a hundred and forty-three repositories, produced raw estimates suggesting a speedup rather than a slowdown. But METR published those numbers alongside an unusually candid explanation of why it does not trust them. Between thirty and fifty percent of participating developers reported declining to submit certain tasks to the experiment because they did not want to be randomized into working without AI on those tasks. Recruitment and retention became harder for the same reason. Some developers ran several agents in parallel and could not report time accurately. METR's own conclusion is that developers are probably more sped up now than they were in early 2025, that its data is only weak evidence for how much, and that the experimental design needs to be rebuilt because widespread AI adoption has made the counterfactual condition increasingly artificial.

That is the honest state of the field. It is also, in itself, a finding. When the control group becomes difficult to construct because practitioners refuse to work without the tool, you are looking at something real. It just is not something you can put a clean number on.

Self-reports fill the vacuum, and they should be read with care. METR's February to April 2026 survey of 349 technical workers found a median self-reported change in the value of work in the range of 1.4x to 2x, and a median self-reported change in speed of about 3x. The gap between those two numbers is the interesting part, and METR built the survey specifically to expose it. Respondents also retrospectively estimated their 2025 uplift at about 1.3x and forecast 2.5x for 2027. METR's own staff reported the lowest gains of any subgroup studied, which the researchers tentatively attribute to those staff having internalized their organization's prior findings about the gap between perceived and measured productivity.

The Productivity Ladder

The reason all of this evidence resists summary is that productivity in software delivery is not a scalar. It is a stack, and a gain at the bottom has to survive a journey upward before anyone outside engineering can see it.

Layer 1: Generation. How quickly can useful code, tests, queries, configuration, and documentation be produced? This is where AI has made its largest and most visible contribution. It is also the layer that every benchmark, demo, and vendor case study measures.

Layer 2: Integration. How quickly can generated work be safely incorporated into an existing system? This includes review, merge conflict resolution, dependency coordination, contract compatibility, and the accumulated weight of prior decisions the new code has to respect.

Layer 3: Verification. How quickly can the organization establish, to whatever confidence level it requires, that the change behaves correctly, including under conditions nobody thought to specify?

Layer 4: Delivery. How quickly can validated work actually reach production, across environments, approval gates, release trains, migrations, and coordination with other teams shipping simultaneously?

Layer 5: Adoption. How quickly do users discover the capability, understand it, trust it, and successfully incorporate it into their workflow?

Layer 6: Outcome. Does the capability produce a measurable change in customer behavior or business result, whether that is retention, expansion, cost reduction, risk reduction, or competitive position?

Each layer has its own capacity, its own queues, and its own failure modes. A tenfold improvement at Layer 1 propagates upward only to the extent that Layers 2 through 6 can absorb it. If Layer 3 can evaluate a fixed number of changes per week, then generating three times as many changes does not produce three times as much verified change. It produces the same amount of verified change and a longer queue.

This is not a criticism of AI coding tools. It is a statement about the arithmetic of connected systems, and it was true of every previous engineering productivity improvement as well. Continuous integration, high-level languages, package managers, and cloud infrastructure each compressed one part of the stack and left the others to catch up. What is different now is the size of the compression and the speed at which it arrived.

The most useful discipline a technology executive can adopt right now is to ask, of every productivity claim that crosses their desk, exactly one question: which layer was measured? A 40% improvement at Layer 1 is a real and valuable thing. It is not a 40% improvement at Layer 6, and treating it as one produces budgets, roadmaps, and headcount plans built on a category error.

Movement II: The Bottleneck Doesn't Disappear. It Moves.

There is a body of operations theory that predicted all of this before anyone had seen a language model, and engineering leadership would benefit from remembering it.

The core proposition, familiar from manufacturing and from Eliyahu Goldratt's theory of constraints, is that the throughput of a multi-stage system is set by its slowest stage. Improvements applied anywhere else raise local utilization without raising system output. An airport that doubles the number of check-in desks while leaving security staffing unchanged does not process more passengers. It relocates the line. A hospital that speeds up triage without expanding imaging capacity does not discharge patients faster. It creates a fuller waiting room in radiology. A port that unloads containers twice as fast without more trucks accumulates containers on the dock.

Software delivery has always been a multi-stage system of exactly this kind, but for decades one stage was so dominant that the theory rarely needed to be applied. Implementation absorbed enough of the calendar that optimizing it was almost always correct. Everything else was noise around the signal.

Consider the rough shape of a change's life before the current wave of tooling. Requirements and clarification might consume a moderate slice. Implementation consumed a large one. Review, testing, and release consumed moderate to small slices each. Under those proportions, doubling coding speed produced a meaningful reduction in total lead time, and the industry built a great deal of process, tooling, and management practice around that fact.

Now compress implementation by half or more and hold everything else constant. Nothing downstream has gotten worse. But the proportions invert. Review, which was a supporting activity, becomes a leading contributor to lead time. Verification, which used to fit comfortably inside the window while engineers finished other work, becomes a scheduling constraint. Environment availability, which was an occasional annoyance, becomes a recurring blocker. The stages that were always there but never mattered enough to fix are now the whole story.

This is worth naming, because organizations respond very differently to a problem that has a name.

Bottleneck Migration is the movement of the limiting constraint from one stage of software delivery to another as technology changes the relative speed of the stages. It is not a failure of adoption. It is the expected consequence of successful adoption, and it should be planned for rather than discovered.

The empirical signature of bottleneck migration is now visible in delivery telemetry at industrial scale. Faros AI's analysis of more than ten thousand developers across 1,255 enterprise teams found that teams with high AI adoption completed roughly 21% more tasks and merged roughly 98% more pull requests. Over the same period, pull request review time rose by about 91%, average pull request size grew by about 154%, and bugs per developer rose by about 9%. Organization-level delivery metrics showed no measurable improvement. Faros gave the pattern a name that has since entered general circulation, and it is the same name this article carries.

LinearB's 2026 benchmark, drawn from more than 8.1 million pull requests across 4,800 engineering teams in forty-two countries, adds resolution to the same picture. AI-generated pull requests waited roughly 4.6 times longer for their first review than human-authored ones. Pull requests from agentic tools waited longer still, on the order of 5.3 times. Once a reviewer picked them up, they were reviewed about twice as fast, which is not the reassurance it initially sounds like. And the merge rate diverged sharply: AI-generated pull requests were accepted at about 32.7%, against 84.4% for manually written ones.

Read those three findings together and a specific mechanism emerges. Generation capacity rose. Change size rose with it. Reviewer attention did not rise. Changes therefore sat in queue longer, and when they were finally picked up they were triaged rather than studied, which is a rational response to an overloaded queue and a poor one from the standpoint of defect escape. A significant fraction never merged at all, which means the generation effort that produced them was pure waste from a delivery perspective, however satisfying it felt at the keyboard.

DORA's data tells a compatible story from a different angle. In its 2024 research, a 25% increase in AI adoption was associated with an estimated 1.5% decrease in software delivery throughput and a 7.2% decrease in delivery stability, with the researchers' leading hypothesis being that AI encourages larger batch sizes, and larger batches have been associated with slower and less stable delivery in DORA's data for a decade. By 2025 the throughput finding had reversed and turned positive, which DORA described as a key shift. The instability finding did not reverse. It persisted into a second consecutive year.

That combination, throughput up and stability down, is precisely what bottleneck migration predicts when an organization pushes more change through a system whose verification and operational capacity has not grown proportionally.

The Shrinking Middle

Picture the delivery pipeline as a horizontal band, with the width of each segment proportional to the time it consumes.

For twenty years, implementation occupied the widest segment in the middle. It was the thing you could point at. It was where the money went, where the hiring plans pointed, and where every methodology from waterfall to extreme programming aimed most of its interventions. The segments on either side, the ambiguity before coding and the evaluation after it, existed but looked narrow by comparison.

Now shrink the middle segment by half and redraw the band to the same total width. Nothing else changed, but everything else looks bigger. Requirements ambiguity, which was always there, now occupies a visibly larger share. Review and verification, which were always there, now dominate. Cross-team coordination, production risk, and the lag before customers actually adopt anything are all suddenly conspicuous.

The important interpretive move is to resist the conclusion that AI created these problems. In most organizations it did not. It removed the thing that was standing in front of them.

This is what DORA means when it describes AI as an amplifier, magnifying the existing strengths and dysfunctions of the organization it lands in. An organization with a high-quality internal platform, clean interfaces, disciplined version control, and strong automated verification finds that cheap generation compounds those advantages. An organization with fragmented tooling, siloed data, brittle environments, and manual quality gates finds that cheap generation compounds those too. The tool does not decide which. The system it enters does.

Movement III: Requirements Become Expensive When Implementation Becomes Cheap

Every organization has a filter that stops half-formed ideas from becoming production software. In most companies that filter was never a formal process. It was the cost of implementation.

When building something took a senior engineer three weeks, somebody asked what it was for. The question got asked because three weeks of senior engineering time was expensive enough to be worth a meeting. Product managers wrote clearer acceptance criteria because vagueness got expensive quickly. Stakeholders were forced to reconcile conflicting expectations because there was only enough capacity to satisfy one of them. The scarcity of implementation was doing enormous, unacknowledged work as a discipline mechanism.

Lower the cost of implementation substantially and that filter weakens. The meeting that used to happen because three weeks was expensive does not happen when the estimate is two days. The specification that used to be tightened because ambiguity was costly stays loose, because ambiguity now feels cheap. The stakeholder disagreement that used to be forced to resolution gets deferred, because both interpretations can be built.

The result is not that teams build fewer wrong things. It is that they build wrong things faster.

This is where a distinction becomes load-bearing, and it is one that many AI strategy documents miss entirely.

Implementation ambiguity is the condition where the team knows what outcome is wanted but not how to achieve it technically. Which library, which pattern, how to structure the migration, how to make the query performant. AI has become genuinely excellent here. It compresses the search over known solutions, surfaces approaches the engineer had not considered, and reduces the cost of exploring several designs before committing to one.

Product ambiguity is the condition where the organization does not know what the right outcome is. Which customer segment matters more this year. Whether the enterprise buyer's requested workflow reflects a real need or a single loud account. Whether the metric that would improve is one that actually predicts renewal. Whether the feature belongs in the product at all or belongs in the professional services contract.

AI can assist with product ambiguity. It can summarize interviews, cluster support tickets, model scenarios, and argue both sides of a positioning decision with more patience than most humans. What it cannot do is resolve a genuine conflict of interest between two executives who want different things for defensible reasons. That is not an information problem, and information tools do not solve it.

When a specification is ambiguous and implementation is expensive, the ambiguity tends to surface as friction before code is written. Someone hits a wall, asks a question, and the ambiguity gets resolved on a whiteboard. When a specification is ambiguous and implementation is cheap, the ambiguity gets resolved by the implementer, silently, in code, according to whatever interpretation the model found most plausible given the prompt. The organization now has a system that encodes an interpretation nobody approved and nobody reviewed as a decision, because it arrived disguised as an implementation detail.

Speed does not resolve ambiguity. It operationalizes it, at scale, into production systems that other systems then depend on.

There is a corollary for how requirements work should be resourced. In an organization where implementation was 60% of cycle time and specification was 10%, spending more time on specification looked like an obvious waste. In an organization where implementation is 20% of cycle time, that calculus reverses. The relative return on a clearer specification has roughly tripled, and almost no company has adjusted its staffing to reflect that.

The Cost of a Bad Decision Falls, at First

The optimistic reading of cheap implementation is that it enables experimentation, and this reading is substantially correct. If a prototype costs a day instead of a month, you can afford to be wrong more often. Reversible, isolated, low-blast-radius experiments are exactly where abundant generation capacity should be spent, and organizations that use it that way are getting real value.

The problem is that the cost of creating a feature and the cost of owning one have decoupled, and only the first one fell.

A feature that reaches core workflows acquires obligations. Customers build processes around it. Support agents learn to troubleshoot it. Documentation describes it. Other features assume its behavior. Enterprise contracts sometimes name it. Migrations must preserve it. Every subsequent architectural decision has to route around it. Deleting it becomes a project with its own change management, communication plan, and customer risk.

None of those costs are reduced by cheaper generation. Several of them scale with the number of features shipped, which cheaper generation increases.

This produces a specific trap that is worth watching for in the next eighteen months. An organization discovers it can ship features far more quickly, and rationally decides to ship more of them. Two years later, its engineering capacity has been quietly consumed not by building but by maintaining, supporting, and reasoning about a surface area three times larger than the one it had planned for. The velocity gain has been converted into permanent operational overhead, and the conversion happened one reasonable decision at a time.

Cheap creation does not mean cheap ownership. It means the ownership cost arrives later, arrives distributed across teams that did not make the decision, and never appears in the same report as the velocity metric that justified it.

Movement IV: AI Creates More Work for Reviewers

Code review is the first place downstream of generation where the arithmetic breaks, and it is breaking now, measurably, in production organizations.

The mechanism is simple. Generating a plausible implementation and establishing that an implementation belongs in a particular system are different cognitive tasks, and only one of them has been automated at scale.

Review is not proofreading. A competent reviewer is simultaneously evaluating whether the change is architecturally appropriate, whether it is correct under conditions the tests do not cover, whether it will be maintainable by someone who has never seen it, whether it handles failure the way the rest of the system handles failure, whether it introduces a security-relevant behavior change, whether it degrades performance under load, whether it duplicates something that already exists elsewhere, and whether it interacts badly with three other changes currently in flight. Some of that can be automated. Much of it depends on holding a model of the whole system in working memory, which is the scarcest resource in any mature engineering organization and the one that AI has done the least to expand.

DORA's qualitative research, drawn from more than a thousand open-ended responses from Google engineers in late 2025, identified this shift explicitly and named its cost. The time an author saves in generation is frequently re-spent by someone else in auditing. DORA calls it the verification tax, and it is not evenly distributed. The author captures the velocity gain. The reviewer absorbs the cognitive load. Engineers in that research described the dynamic directly: an author can produce a very large changelist quickly, and the reviewer is still expected to understand every line of it.

The telemetry confirms that reviewers respond the way any overloaded queue server responds. They defer, then they skim. LinearB's benchmark shows AI-generated pull requests waiting several times longer for pickup and then being processed roughly twice as fast once picked up, on changes that are substantially larger. Faster review of larger changes is not a productivity improvement. It is a reduction in review depth, which shows up later as escaped defects, and DORA's persistent instability finding is consistent with exactly that.

Reported acceptance patterns sharpen the point further. In LinearB's data, more senior reviewers spent considerably longer on AI-generated pull requests and accepted a lower proportion of them than junior reviewers did. The people best equipped to evaluate the code find more reasons to reject it, and they are also the people whose time is most contested.

The Review Capacity Problem

The structural statement is short: code supply can scale faster than reviewer attention.

Generation capacity is now essentially purchasable. A team can increase its output of candidate changes by adding agents, adding parallelism, or simply prompting more. Review capacity is a function of the number of engineers with enough system context to make consequential judgments, multiplied by the hours they can sustain that kind of concentration, minus everything else those same people are needed for. It grows slowly, it grows through mentorship and tenure, and it shrinks when senior engineers spend their days in review queues instead of doing the architectural work that produced their context in the first place.

AI can help on the review side, and this is not a minor caveat. Automated review agents catch style violations, common bug patterns, missing error handling, and policy deviations at a scale no human team could match. Static analysis has improved. Semantic diff tools can flag behavior changes rather than text changes. Organizations can encode architectural rules as executable checks rather than tribal knowledge.

But the symmetry is imperfect in a specific way. Machine-generated review comments increase the quantity of feedback. What organizations actually need at the end of the process is a defensible judgment that a consequential change is acceptable, and that judgment carries accountability. When something goes wrong in a regulated system or a customer-facing payment path, the question asked is not what the linter said. Responsibility does not distribute across tooling as cleanly as work does.

The productive response is not to insist that humans inspect every line forever. That position will not survive the volume, and it is not even good practice today. The productive response is to redesign review around risk, which means several things in combination.

It means moving automated feedback to the author rather than the reviewer, so that issues are caught during writing rather than surfaced as review comments. DORA's own recommendation is explicit on this point, and the efficiency argument is straightforward: fixing something while you still hold the context is far cheaper than fixing it after a round trip through someone else's queue.

It means classifying changes by blast radius and applying proportionate scrutiny. A change to an internal analytics dashboard and a change to authorization logic should not receive the same review process, and in most organizations today they roughly do.

It means enforcing small batches as a hard constraint rather than a cultural preference. The 154% growth in pull request size that Faros measured is the single most controllable variable in this whole picture, and it is controllable through policy. DORA has consistently found small batches associated with better delivery outcomes, and the case is stronger now than it was, because large AI-generated changes combine the review burden of a large change with the reviewer's reduced ability to reconstruct the author's reasoning.

It means being willing to ask whether asynchronous human review is still the right quality gate for every category of change, or whether investment in automated verification would buy more confidence per hour than optimizing the review queue would.

The underlying shift is this: when implementation was expensive, the scarce decision was what to build. When implementation is cheap, an additional scarce decision appears, which is what deserves scrutiny. Organizations that make that decision explicitly will spend their reviewer attention where it changes outcomes. Organizations that leave it implicit will spend it uniformly, which means spending most of it on changes that did not need it while the changes that did needed it get triaged at speed.

Movement V: Work in Progress Can Explode

There is a piece of queueing behavior that engineering leaders intuitively know from traffic and consistently forget in delivery planning.

A highway at fifty percent of capacity absorbs disturbances. A car brakes, the cars behind adjust, and flow continues. The same highway at ninety-five percent of capacity converts the same disturbance into a standing wave of stopped traffic that persists for an hour after the cause has cleared. The relationship between utilization and waiting time is not linear. As utilization approaches capacity, expected waiting time rises steeply, and variability in arrival or service time makes it worse.

Software delivery stages behave the same way. A review queue at moderate utilization absorbs a burst. A review queue at high utilization converts the same burst into a multi-day backlog. A shared test environment with slack absorbs a failed run. A shared test environment booked solid converts one failed run into a cascade of missed slots.

AI affects this system in two ways simultaneously, and only one of them is favorable.

It reduces service time at the implementation stage, which is good. It also increases the arrival rate at every subsequent stage, because more implementations finish per unit time and each of them requires review, testing, integration, approval, and deployment. If downstream capacity is unchanged, utilization rises. If utilization was already high, which it is in most organizations because most organizations optimize for busy people rather than fast flow, waiting time rises disproportionately.

This is worth stating as a named effect, because it explains an experience that a great many engineering leaders are currently having and struggling to articulate.

The AI Queue Effect: AI reduces the service time of implementation while increasing the number of work items entering later stages. Where downstream capacity is fixed, individual coding tasks finish measurably faster while end-to-end lead time barely improves or degrades.

There is a second-order version of this that is more dangerous. Because implementation is faster, engineers can now start more things. An engineer waiting on review for one change no longer waits. They begin a second change, then a third. Work in progress rises, not through any management decision, but as an emergent property of reduced friction at the starting line. Every one of those in-flight items will eventually arrive at review, testing, and release. The organization has effectively increased its arrival rate at the constraint without noticing, because the increase happened at the level of individual behavior rather than planning.

More work in progress also means more context switching, more merge conflicts between concurrent changes, more coordination overhead, and longer feedback delays on each individual item. Little's Law is unforgiving here: with a fixed throughput, the average time an item spends in the system rises in direct proportion to the number of items in the system. Doubling work in progress doubles average lead time, holding throughput constant. Faros observed exactly this pattern of increased parallelization in its telemetry and identified it as one reason individual gains failed to reach the organization.

Productivity Can Create Congestion

The counterintuitive claim, and the one worth putting in front of a board, is that a local productivity improvement can make a system slower.

The list of ways this happens in software organizations is unglamorous and completely recognizable.

More pull requests than senior engineers can review at depth. More test executions than the CI fleet can run without queueing, which extends feedback time on every change including the urgent ones. More branch environments than the platform can provision, so teams start sharing environments again and reintroduce the interference that per-branch environments were built to eliminate. More releases than the operations team can meaningfully observe, so anomalies go unnoticed until customers report them. More experiments than the product team can analyze, so results accumulate unread. More changes than the documentation and support organizations can absorb, so the help center describes a version of the product that no longer exists and ticket volume rises.

Every item on that list is a system design problem with a system design solution. None of them are arguments against AI adoption. All of them are arguments for treating downstream capacity as a first-class part of the AI investment rather than an afterthought, and for measuring flow rather than activity while the transition is underway.

The DORA research program makes a version of this argument in financial terms. Its ROI framework describes a J-curve in which organizations experience a temporary productivity dip before realizing long-term gains, attributing the dip to three causes: the learning curve as teams adapt workflows, the verification burden of reviewing AI-generated code, and the need to adapt downstream processes such as testing and change approval to handle increased volume. The report characterizes this period as the tuition cost of the transformation and warns that leaders who misread the dip as failure tend to withdraw funding precisely when the return was about to arrive.

That framing is useful, but it should not be applied as an excuse. A J-curve implies the organization is doing the work that produces the upturn. An organization that buys licenses, increases roadmap commitments, and changes nothing else is not on a J-curve. It is on a flat line with a larger queue.

Movement VI: Integration Becomes the New Coding

There is a reason the two flagship studies in this field disagree, and it is not primarily about tools or models. It is about what kind of code was being written.

AI systems are exceptionally good at producing locally plausible code. Given a description of a desired behavior and some surrounding context, they produce something that reads like what an experienced engineer would write, follows recognizable conventions, and works in isolation. This is an enormous capability and it is not diminishing.

Production systems are not local. A ten-year-old platform contains services written by people who left the company, database constraints added during an incident nobody documented, internal APIs whose contracts exist only in the heads of the two teams that use them, feature flags that were supposed to be temporary, vendor integrations with undocumented rate limits, a permissions model that accreted rather than was designed, and behaviors that three enterprise customers depend on which appear nowhere in the specification because they were never specified. They were emergent, and then they were relied upon, and now they are requirements.

The difficulty in most enterprise engineering is not writing a new component. It is making a new component coexist with everything that is already there, including the parts nobody fully understands.

The compressed version of this: greenfield generation is easier than brownfield understanding.

The Stanford data quantifies the gap. Low-complexity work on new code shows gains in the thirty to forty percent range. High-complexity work in mature codebases shows gains in the single digits, with a meaningful share of teams net negative. The DORA ROI report cites the same research and states the practical implication for enterprises directly, which is that the majority of organizations do most of their work in exactly the setting where the gains are smallest.

DORA's qualitative research adds a mechanism that leaders should internalize, because it explains a specific and repeated estimating failure. AI dramatically accelerates the first portion of the work, the prototype, the scaffold, the demo. The remaining portion, which requires precision, edge case handling, and integration with internal systems, can take more effort than it would have taken had the whole thing been built deliberately from the start. Teams see the prototype appear in an afternoon and revise their estimate for the whole project accordingly. The estimate is then wrong by the size of the last mile, which was always the expensive part and has not become cheaper.

DORA's recommendation on this is unusually blunt for a research organization: do not reduce estimates before investing to close the gap.

There is a structural reason the last mile resists automation. A model can be given the code. It cannot be given the reason. Why is there a special case for accounts created before 2019? Why does this endpoint return a 200 with an error body instead of a 4xx? Why does the retry logic look wrong? Frequently the answer is a decision made under pressure years ago that is now depended upon by something else. AI is genuinely good at helping engineers navigate legacy code, and this is one of its most underrated uses. It compresses the time required to understand what a system does. It does not compress the time required to determine what a system is allowed to stop doing, and that second question is the one that governs whether a change is safe.

The 200-Line Change Inside the Ten-Million-Line System

Take a feature that requires two hundred new lines of code in a platform of ten million.

The two hundred lines are the cheap part, and they were the cheap part before AI existed. The expensive part is answering a set of questions that no amount of generation capacity answers on its own. Which services depend on the current behavior of the function being modified? Which customers rely on an undocumented edge case that the change would eliminate? Which data migration from three years ago left rows in a state the new code does not anticipate? Which internal tool, maintained by an adjacent team, still calls the old version of the API? Which assumption exists only inside a test file, so that changing the code and the test together will produce a green build and a broken product?

Lines of code is a poor productivity measure and this section is not an argument for it. The contrast is useful for a narrower purpose, which is to make visible that implementation size and integration difficulty are independent variables. A two-hundred-line change in a young service is a two-hour task. A two-hundred-line change in a load-bearing path of a mature platform is a two-week task, and roughly ninety percent of that time is spent on questions that have nothing to do with typing.

Cheap generation reduces the first kind of task to nearly zero and the second kind by a modest fraction. Since most enterprise work is the second kind, the organizational average moves far less than the individual experience suggests. This is the single most reliable explanation for the gap between what developers report feeling and what delivery metrics show.

Movement VII: Verification Cannot Be Skipped Just Because Generation Is Faster

Here is the asymmetry that defines the current moment. An AI system can produce five plausible implementations of a requirement in the time it takes to read one of them. It cannot tell you which one is correct, and increasingly it cannot tell you when it does not know.

The organization still has to determine whether the requirement was interpreted correctly. Whether the integration points still behave as expected. Whether the security posture changed. Whether performance degraded under realistic load rather than in a local benchmark. Whether the edge cases that were valid last quarter are still handled. Whether a real user can complete a real workflow end to end without hitting a state the developer never imagined.

None of that is generation. All of it is evidence gathering, and it has its own cost curve.

Verification Load is the quantity of evidence an organization requires before it will confidently release a change. It is a function of blast radius, regulatory context, reversibility, customer sensitivity, and the organization's tolerance for being wrong in public. It is not a function of how the code was produced.

The critical question for engineering economics over the next few years is whether verification load falls at the same rate as generation cost. There are strong reasons to think it does not, and one strong reason to think it partially might.

The reasons it does not: verification load scales with the number of distinct changes and with the number of interactions between them, not with the number of lines. Two changes create one interaction to consider. Ten changes create forty-five. Merging more changes per week does not linearly increase the verification burden. It increases it faster than linearly, because the state space the organization must reason about is combinatorial. Additionally, the confidence bar itself does not move. A payment system requires the same evidence today that it required in 2019, and arguably more, because the regulatory environment has tightened rather than loosened.

The reason it partially might: verification is itself automatable, and a great deal of engineering effort is currently pointed at exactly that. AI can generate test cases from specifications and from code. Agentic tools can explore application state autonomously, discovering paths a human test designer would not enumerate. Log analysis and failure triage, historically among the most tedious activities in engineering, respond well to language models. Regression selection can be made intelligent rather than exhaustive, running the subset of tests that a given change could plausibly affect rather than the whole suite. Test maintenance, which has always been the hidden cost that kills automation programs, becomes tractable when a model can update a hundred brittle selectors in an afternoon.

These are real capabilities and they are improving. The honest assessment is that verification capacity is growing, just more slowly and less uniformly than generation capacity, and that the gap between the two is where risk is currently accumulating.

The security data illustrates why the gap persists even as models improve. Veracode's research, which tested code generated by more than a hundred large language models against curated tasks with known vulnerability potential, found that roughly 45% of generated code introduced flaws corresponding to well-known vulnerability classes. Its spring 2026 update, spanning more than a hundred and fifty models, reported that syntactic correctness had climbed above 95% while the security pass rate had remained roughly flat at around 55% across two years of model releases. Functional quality and safety properties are improving at very different rates, which means the verification burden that matters most is the one shrinking most slowly.

The Verification Gap

Two capacities determine whether an organization converts generation into delivery.

Generation Capacity is how much change the organization can produce. It is now elastic, purchasable, and rising quickly.

Verification Capacity is how much change the organization can confidently evaluate. It is a combination of automated coverage, environment availability, observability quality, test data realism, review depth, and the specialized human judgment required for the categories of risk that automation does not yet cover.

When generation capacity grows faster than verification capacity, a gap opens, and the gap has to be absorbed somewhere. There are only a handful of places it can go, and every organization is currently choosing among them whether or not it realizes it.

The change can sit in a queue, which converts the generation gain into inventory and produces the flat lead times that the telemetry keeps showing. The verification standard can be quietly relaxed, which converts the gain into production risk and produces the persistent instability finding in DORA's data. Verification can be automated aggressively, which is the correct answer but requires investment and time. The number of changes permitted in flight simultaneously can be capped, which is unpopular and effective. Or prioritization can be tightened so that fewer, more valuable changes are produced in the first place, which is the answer nobody wants to hear from an engineering team that just got faster.

Most organizations are currently choosing the first two by default, because they are the only two options that require no decision.

The defining engineering management problem of AI-assisted development is likely to be the deliberate management of this gap. It is a resource allocation question, it has real financial consequences on both sides, and it cannot be delegated to the tooling team. An organization that funds generation and not verification has purchased the ability to produce risk more efficiently.

Movement VIII: Test Automation Also Has a Bottleneck

The obvious response to the verification gap is to automate more testing, and the obvious response is correct as far as it goes. It does not go as far as most people assume, because test automation has its own economics and those economics have a failure mode that AI makes easier to trigger.

An automated test is not free once written. It must be designed, generated, reviewed, executed, maintained, and interpreted. Each of those has a cost. Generation cost has collapsed. The others have not collapsed nearly as much, and one of them scales badly.

Consider what an organization can now build in a quarter with modern tooling: a suite of forty thousand automated tests. Consider what that suite may actually be.

It may run for ninety minutes, which means every developer waits ninety minutes for feedback and most of them context-switch during the wait, which costs more than the ninety minutes. It may test the same behavior in eleven places because nobody had visibility into what already existed. It may contain assertions that verify a function returns something rather than verifying it returns the right thing, which is the characteristic failure of generated tests and one that produces coverage numbers without producing confidence. It may fail intermittently for environmental reasons at a rate of two percent, which across forty thousand tests means several hundred failures per run, which means nobody investigates failures anymore, which means the suite has become a ritual rather than a control.

That last progression is the important one. A test suite that cries wolf is worse than no suite, because it consumes the resources of a control while providing the assurance of a decoration, and it teaches the organization to ignore signals.

The distinction that matters is between producing more testing artifacts and producing more confidence. They are correlated at low volumes and can become uncorrelated at high ones. The purpose of quality engineering was never to maximize test count. It is to maximize the amount of useful evidence about risk per unit of engineering investment, and evidence has properties that artifacts do not: it must be trustworthy, it must be timely, and it must be about something that could plausibly go wrong.

This reframes what a quality organization should be doing with AI, and it is not primarily writing more tests. It is deciding what to test, which requires understanding where risk actually lives in a specific system. It is designing test data that resembles production rather than resembling a fixture file. It is building environments that can be created and destroyed quickly enough that they stop being a scheduling constraint. It is selecting which regression tests a given change requires rather than running everything every time. It is maintaining the suite so that a failure means something. It is analyzing failures fast enough that the feedback arrives while the author still has context.

AI helps substantially with several of those, particularly maintenance and failure analysis, which were historically the activities that consumed quality engineering budgets without producing visible output. That is a genuine and underappreciated win. But it helps least with the first one, deciding what to test, because that requires knowing which failures would actually matter to this business and its customers. That knowledge is organizational, not technical, and it is the thing that separates a quality function that reduces risk from one that produces reports.

Movement IX: Security Doesn't Move at Generation Speed

Application security has a structural problem in the AI era that has nothing to do with security teams being obstructive and everything to do with how the work is shaped.

Security review is partly a scanning problem and partly a reasoning problem. The scanning part responds well to automation and always has. Dependency analysis, secret detection, known vulnerability patterns, misconfigurations, and insecure defaults can be caught by tooling, and AI has made that tooling considerably better at reducing false positives, which was the main reason developers ignored it.

The reasoning part does not automate as cleanly. Threat modeling requires understanding what an adversary would want from this specific system. Authorization design requires knowing which actors should be able to see which data under which circumstances, which is a business question wearing technical clothes. Data classification requires knowing what the company promised customers and regulators. Risk acceptance requires someone with the authority to accept risk on behalf of the organization. None of these are lookups.

The volume problem is straightforward arithmetic. If product teams generate substantially more change, and some proportion of change requires security judgment, then demand for security judgment rises proportionally. Security headcount does not. In most organizations the ratio of engineers to application security specialists is already somewhere between fifty and two hundred to one, which means the function was operating as a bottleneck before generation costs fell.

The evidence suggests the per-change risk has not declined either. Veracode's testing found that when models faced a choice between a secure and an insecure implementation of the same functionality, they selected the insecure option in roughly 45% of cases, with cross-site scripting among the worst categories and Java among the worst languages. Its 2026 update found this essentially unchanged across two years of model improvement, even as functional correctness rose sharply. Independent enterprise research has reported elevated rates of privilege escalation paths and secrets exposure in AI-assisted repositories. The direction of these findings is consistent enough across independent sources to take seriously, even allowing that most of the organizations publishing them sell security products.

Combine higher volume with unchanged per-change risk and the total security exposure rises even if nothing about the code got worse in any individual instance. That is the whole argument, and it does not require believing that AI writes bad code.

The traditional response is a centralized gate: every change touching a sensitive area requires review by the security team before release. This worked when change volume was human-limited. At current volumes it produces a queue, and queues under pressure produce exceptions, and exceptions become the norm. A gate that is routinely bypassed provides less protection than no gate, because it also provides false assurance to everyone upstream of it.

The direction of travel is toward moving security decisions earlier and encoding them structurally. Secure defaults in frameworks and platform libraries, so that the easy path is the safe one and a developer has to work to be insecure. Policy as code, so that constraints are enforced by the pipeline rather than remembered by a person. Architecture guardrails that make certain classes of mistake impossible rather than detectable. Automated dependency and supply chain analysis running continuously rather than at release. Security context surfaced in the developer's own environment at the moment of authorship rather than in a report three days later. And human specialist review concentrated on the small subset of changes where the risk is genuinely novel, which is the only place that expensive attention produces a return.

The framing that helps here is throughput rather than compliance. Security is not a department that slows delivery down. It is a capacity in the delivery system, and like every other capacity in the system it becomes the constraint when the stages around it accelerate. An organization that increases generation capacity without increasing security capacity has made a decision about its risk posture, whether or not anyone framed it that way in the budget meeting.

Movement X: Deployment Is Not Delivery

There are four distinct states a piece of work can occupy, and organizations routinely collapse them into one when reporting progress.

Produced. The code exists. Someone or something wrote it and it is in a branch.

Integrated. The code is part of the product. It has been reviewed, merged, and reconciled with everything else in the codebase.

Deployed. The code is running in production, serving real traffic, in front of real users.

Adopted. Customers have discovered the capability, understood it, chosen to use it, and successfully accomplished something with it.

AI has dramatically accelerated the first state. Modern deployment automation has dramatically accelerated the third. Neither has done much for the fourth, and the fourth is the only one that generates revenue.

The gap between deployed and adopted is where most of the value in software actually leaks away, and it is almost entirely invisible from an engineering dashboard. A feature can be running flawlessly in production, with perfect uptime and zero errors, and be used by four percent of the accounts it was built for. From the perspective of deployment frequency, that feature shipped. From the perspective of the business case that funded it, nothing happened.

Adoption depends on things that no amount of generation capacity influences. Whether the capability is discoverable in the interface. Whether the customer's existing workflow has a place for it. Whether the customer trusts it enough to route real work through it. Whether the pricing model makes using it rational. Whether the onboarding path is short enough that a busy person completes it. Whether anyone told the customer it exists. Whether the customer's own internal approval process permits the change in behavior it requires.

This is the point at which software productivity becomes product productivity, and the two are governed by entirely different mechanisms. Engineering productivity is largely a flow problem. Product productivity is largely a judgment and communication problem. An organization can be excellent at the first and mediocre at the second, and if it is, then improving the first produces a larger volume of unused software.

Shipping More Is Not the Same as Learning Faster

The strongest argument for abundant generation capacity is not that it lets companies build more. It is that it lets them learn more, by running more experiments and killing bad ideas earlier.

The argument is sound and the mechanism is real, but it has a dependency that is easy to overlook.

An experiment produces value only when the organization defines a hypothesis before running it, instruments the right behavior, waits for enough signal, interprets the result honestly, acts on it, and remembers the conclusion the next time a similar question arises. That is a chain of six organizational capabilities, and cheap implementation improves exactly one of them.

A company that can launch fifty experiments per quarter and can properly analyze eight of them has not built a learning engine. It has built an experiment backlog, and it will make its decisions on the same instincts it used before, now with the added confidence of believing itself data-driven. A company that runs ten carefully designed experiments and acts on all ten will out-learn it substantially.

Two capacities are worth separating explicitly.

Experiment bandwidth is how many distinct things the organization can put in front of users to test. AI expands this considerably, particularly for variations, prototypes, and reversible changes.

Learning bandwidth is how many results the organization can properly interpret and convert into changed behavior. This is a function of analytical capacity, decision-making structure, and organizational willingness to accept unwelcome answers. AI barely touches the third.

When experiment bandwidth exceeds learning bandwidth, the excess does not disappear. It becomes product surface area that was never validated, shipped under the banner of experimentation and never removed, because removing things requires a decision and nobody is accountable for the decision to remove something that nobody is measuring.

Expanding learning bandwidth is a management responsibility, and it is mostly unglamorous: fewer simultaneous experiments, clearer hypotheses, pre-registered success criteria, an explicit owner for each result, and a standing commitment to remove what did not work. None of that requires new technology. All of it requires the kind of discipline that abundant capacity makes easy to skip.

Movement XI: Product Management Becomes More Important, Not Less

A common prediction holds that as software becomes easier to build, the role of product judgment diminishes, because the cost of being wrong falls. The opposite is closer to the truth, and the reasoning is worth walking through carefully because it has direct implications for how companies should staff.

When engineering capacity is scarce, the backlog is self-limiting. The team can build four things this quarter, so the organization argues about which four. The argument is often political and frequently unpleasant, but it happens, and it produces a decision. Scarcity was doing the prioritization work.

When engineering capacity expands substantially, the team can build twelve things. The argument that used to happen does not happen, because there is no forcing function. Twelve things get built. Some fraction of them should not exist, and there is now no mechanism that catches them before they enter the product, acquire users, and become permanent.

The critical question shifts from what can we build to what deserves to consume the organization's attention, and the second question is considerably harder than the first because it has no technical answer.

This is why product management, customer research, and strategic sequencing become more valuable rather than less. The activities that matter are the ones that were always underinvested because they competed with implementation for budget: understanding what customers are actually trying to accomplish rather than what they asked for, understanding the business model well enough to know which improvements convert into revenue, sequencing work so that each release compounds the last rather than fragmenting it, and deleting features that no longer earn their maintenance cost.

AI assists with each of these. It can cluster support tickets, summarize research interviews, generate competitive analyses, and model pricing scenarios. What it cannot do is decide that the enterprise segment matters more than the self-serve segment this year, because that is a strategy decision with winners and losers inside the company, and strategy decisions are resolved by authority rather than by analysis.

The Prioritization Paradox

The principle compresses into a single line: the easier things become to build, the harder it becomes to justify what should be built.

Historically, expensive implementation functioned as an involuntary prioritization mechanism. It was crude, it frequently blocked good ideas along with bad ones, and it made engineering the default villain in every planning conversation. It also worked, in the narrow sense that it prevented an unlimited number of weak ideas from reaching production.

AI weakens that mechanism without replacing it. Organizations that relied on engineering scarcity as their filter, which is most of them, now need an explicit filter, and building one is a governance exercise rather than a technical one. It requires stating what the company is optimizing for this year, defining what evidence an idea needs before it consumes capacity, naming who can say no, and accepting that the answer will sometimes be no to a well-liked executive's favorite idea.

The organizations that build that filter will convert abundant capacity into focus. The organizations that do not will convert it into surface area, and surface area is the most expensive thing a software company can accumulate, because it compounds silently across support, documentation, testing, security review, and every future architectural decision.

Movement XII: Management Can Turn AI Gains Into More Work

Suppose the gains are real and an engineering organization genuinely completes its implementation work meaningfully faster. What happens next is a management decision, and the default answer is usually the worst available one.

The recovered capacity could be spent reducing lead time, so ideas reach customers sooner. It could be spent improving verification, so that more of what ships works. It could be spent removing technical debt or simplifying architecture, so that future changes are cheaper. It could be spent reducing engineer workload, which improves retention and preserves the deep system knowledge that reviews depend on. It could be spent on more careful experimentation.

Or it could be spent on more work, and in most organizations it will be, because increased expectation is the path of least resistance. If teams are meaningfully faster, then commitments should rise correspondingly. The logic is superficially sound and it is applied constantly.

The problem is that it converts a flow improvement into a utilization target, and utilization targets recreate congestion immediately. More coding capacity becomes more tickets, which become more simultaneous initiatives, which become more cross-team dependencies, which become more coordination overhead, which become more waiting. The organization's activity level rises visibly. Its flow does not improve, and may degrade, because the additional work in progress lengthens every queue in the system.

This is the mechanism behind one of the more sobering findings in the consulting literature. Bain's technology research put typical realized gains from AI in software development in the range of ten to fifteen percent, and observed that the saved time was frequently not redirected to anything in particular. BCG characterized engineering organizations' position as widespread adoption with shallow impact. Both are describing the same thing: capacity was released and then absorbed, without a decision ever being made about where it should go.

The Productivity Tax of Too Many Priorities

There is a limit to what a coding assistant can do for an engineer who is spread across four initiatives.

Context switching costs are not reduced by faster implementation. An engineer working on four things pays the reacquisition cost four times a day regardless of how quickly the code appears once they are oriented. Meeting load is not reduced. Cross-team dependency negotiation is not reduced. Support escalations are not reduced. Interruptions are not reduced.

Microsoft's time allocation research and similar studies have consistently found that writing code occupies a minority of a developer's working day, with widely cited estimates placing it somewhere well under a quarter. If AI halves the time spent on that minority slice, the effect on the total is bounded by arithmetic no matter how impressive the local improvement feels. DX's telemetry across hundreds of instrumented organizations measures something on the order of four hours saved per developer per week, which is real, meaningful, and considerably smaller than the multipliers in the marketing.

An engineer with an extraordinary coding assistant still cannot attend three architecture reviews simultaneously, still cannot make a decision that requires a director's approval, and still cannot resolve a disagreement between two teams about who owns a service. AI reduces implementation friction. It does not reduce organizational fragmentation, and in a fragmented organization implementation friction was never the binding constraint.

Movement XIII: Communication Becomes a Hard Limit

Software development is coordinated knowledge work, and coordination has a cost that scales with the number of people who need to share an understanding.

Engineering, product, design, quality, security, support, sales, and leadership all need a compatible model of what is being built, why, for whom, and with what constraints. Building that shared model consumes an enormous share of an organization's actual working hours, and it is the activity that most reliably degrades as headcount grows.

AI helps here, substantially and in ways that are easy to underrate. It summarizes meetings that would otherwise require attendance. It writes and maintains documentation that would otherwise rot. It answers questions about systems from the code itself rather than from the one engineer who remembers. It translates between the vocabularies of different functions. DORA's research found information seeking and synthesis among the highest-value applications of AI reported by engineers, sometimes collapsing multi-hour research tasks into minutes.

But this help is confined to one of the two kinds of communication cost, and the distinction determines how much benefit an organization will actually see.

Information friction is the condition where people cannot find, access, or understand information that already exists. Which service owns this endpoint. What this configuration flag does. Why the migration was structured this way. What the customer said in the call last month. AI reduces information friction dramatically, and this is probably its most reliable organizational benefit outside of code generation.

Decision friction is the condition where people have all the relevant information, understand it correctly, and disagree about what should happen. The product manager wants the feature this quarter. The security lead wants a different authorization model. The platform team wants the dependency removed. The account executive has promised a date. Everyone is behaving rationally within their own accountability, and the disagreement is real.

AI does not reduce decision friction. It can clarify options, quantify trade-offs, and prevent the argument from being conducted on false premises, all of which are worth having. But the disagreement remains, because it is a disagreement about objectives rather than about facts, and objectives are reconciled by authority, negotiation, and organizational design.

The practical consequence is that organizations should expect uneven returns from AI on coordination cost. Companies whose coordination overhead is mostly information friction, meaning young companies, well-documented systems, and clear ownership, will see large gains. Companies whose coordination overhead is mostly decision friction, meaning matrixed structures, unclear ownership, and competing mandates, will see the information problem improve and the calendar stay exactly as full.

Movement XIV: Decision Latency May Become the New Engineering Latency

A developer can now produce three viable implementations of a contested design in an afternoon. The organization then takes four days to decide which one is acceptable, which team owns the shared dependency, whether the security posture is tolerable, whether product wants that behavior for enterprise accounts, and whether the API contract is allowed to change.

The bottleneck in that sequence is not implementation latency. It is decision latency, and it is invisible in every engineering metric currently in use.

Decision Latency is the elapsed time between the point at which enough information exists to make a decision and the point at which the decision is actually made. It is distinct from analysis time, and it is usually much larger.

Its causes are organizational rather than technical. Ownership is unclear, so the decision has no natural home and circulates. Approval layers accumulated during a previous growth phase are still in place. Nobody is punished for delaying a decision and several people can be punished for making the wrong one, which produces rational avoidance. Executives who must sign off have calendars booked three weeks out. Cross-functional disagreement has no escalation path short of a leadership offsite. The person who understands the business context is not the person with the authority.

Decision latency was tolerable when implementation took three weeks, because the decision and the build could overlap and the decision was rarely the longest pole. When implementation takes two days, a four-day decision becomes the dominant term in lead time, and no additional investment in coding tools will move it.

This is arguably the most uncomfortable implication of cheap generation for executive teams, because it relocates the performance problem from engineering to governance. An organization that has spent five years optimizing its development pipeline and none optimizing its decision-making structure is about to discover which one is now the constraint.

The remedies are known and unpopular: push decision authority down to the level with the context, name a single accountable owner for each class of decision, set explicit time limits after which a default applies, and distinguish the small number of decisions that are genuinely irreversible from the large number that are being treated as if they were.

Movement XV: Legacy Systems Are a Speed Limit

Enterprise software cannot move at prototype speed, and the reasons are structural rather than cultural.

A twelve-year-old platform carries a database schema that predates three product pivots, integrations built for partners under contracts that specify behavior, regulatory workflows that must produce auditable records, APIs with published deprecation timelines that customers have planned around, components whose vendors no longer exist, infrastructure with manual steps that were documented once by someone who has left, and per-customer configurations that make every deployment slightly different from every other.

AI helps engineers navigate all of this, and the help is genuine. Understanding an unfamiliar codebase is among the tasks where language models perform best relative to the alternative, and DORA's research found engineers describing exactly this benefit: staying productive in unfamiliar languages and unfamiliar legacy systems without prior domain context.

The compressed statement of what AI does and does not do here is worth keeping: AI can compress the cost of understanding legacy systems. It cannot retroactively simplify their architecture.

That distinction matters for modernization planning. Cheaper implementation genuinely does make modernization more feasible than it was, and organizations that have been deferring migrations for a decade should reassess. But a migration is not primarily an implementation project. It is a sequencing, data validation, compatibility, and customer communication project with an implementation component. Writing the new service faster does not shorten the parallel-run period, the reconciliation of data between old and new systems, the staged rollout across customer cohorts, or the eighteen months during which both systems must be maintained.

The realistic opportunity is that modernization projects which were previously uneconomic now clear the bar, and that the balance of a modernization budget shifts away from writing code and toward the verification and migration work that always determined whether these projects succeeded.

Movement XVI: Quality Problems Can Arrive Faster Too

It would be convenient to assert that AI-generated code is inherently lower quality. The evidence does not support a claim that strong, and the defensible argument is a systems argument rather than a code-quality argument.

The systems argument is this: if an organization increases change volume without proportionally improving verification and observability, then failures move through the system faster too. More deployment capacity means more opportunities for good changes to reach customers, and equally more opportunities for bad ones.

The available quality signals are consistent with that. GitClear's longitudinal analysis of hundreds of millions of changed lines documents a pattern of rising duplication, falling refactoring activity, and rising short-term churn as AI authorship spread, with its 2026 report finding refactoring line moves down roughly seventy percent against 2022 levels while duplicated code blocks rose by around eighty percent. Vendor research from several independent quality and security tool providers points the same direction on defect density in AI-assisted changes. DORA's finding of persistent delivery instability alongside improving throughput fits the same shape.

None of that proves AI writes worse code in a controlled comparison. All of it is consistent with an organization producing more change than its quality controls were sized for, which is a different and more tractable problem.

The useful target, therefore, is not maximum velocity.

Safe Throughput is the amount of valuable change an organization can move into production while maintaining an acceptable reliability level. It is bounded jointly by generation, verification, and operational capacity, and increasing only one of the three does not increase it.

Safe throughput is a better executive metric than deployment frequency because it cannot be gamed by shipping more of the same risk. It also makes the trade-off explicit: an organization that wants higher safe throughput must invest in the constraint, and the constraint is currently downstream of code.

Movement XVII: Observability Becomes Part of Productivity

Monitoring is usually budgeted as reliability infrastructure. It should be budgeted as productivity infrastructure, and the reasoning becomes clearer as change volume rises.

A team that deploys frequently but cannot determine whether a given release improved or degraded the experience is not iterating. It is guessing at a higher frequency. Every argument about what happened becomes a matter of opinion, every incident diagnosis takes longer, every rollback decision is made on incomplete information, and the feedback loop that is supposed to make fast delivery safe never closes.

Observability reduces diagnosis time, reduces uncertainty about whether a change worked, reduces recovery time when it did not, and reduces the amount of senior engineering attention consumed by disagreement about causation. Each of those is a direct contributor to delivery capacity.

The relevant signals span more than infrastructure telemetry. Logs, metrics, and traces answer whether the system is healthy. Product analytics answer whether anyone used the thing. Customer feedback answers whether it helped. Business metrics answer whether it mattered. Organizations tend to instrument the first category thoroughly and the last three sporadically, which is why they can tell you the p99 latency of a feature that nobody adopted.

AI improves several of these activities meaningfully. Log analysis, anomaly investigation, incident summarization, and root-cause hypothesis generation all respond well to models with access to the right context. What AI cannot supply is the instrumentation itself. If the signal was never emitted, no amount of analytical capability will recover it. The architecture has to exist first, and it is one of the highest-leverage places to spend the capacity that cheaper implementation releases.

Movement XVIII: Incident Response Consumes the Productivity You Thought You Gained

Failures are not free, and their cost is charged to the same account that the velocity gain was credited to.

If higher velocity produces more regressions, more rollbacks, more customer tickets, and more incident response, then a portion of the recovered engineering capacity is immediately reconsumed by recovery work. It is reconsumed by the most experienced engineers, because they are the ones who handle serious incidents, and those are the same engineers whose attention was already the constraint in review.

DORA's ROI framework accounts for this explicitly and unsentimentally. Its illustrative model includes a negative line item for downtime, driven by an assumed increase in change failure rate following AI adoption. The specific figures in that model are, by the authors' own description, high-uncertainty estimates intended to start a conversation rather than to be relied upon. The structural point stands regardless of the numbers: a rise in failure rate has a cost, that cost is denominated in the same currency as the productivity gain, and any honest return calculation nets them.

A conceptual model helps here, and it should be treated as a way of thinking rather than an accounting identity:

Gross delivery output, minus recovery and rework, equals net delivery productivity.

Two teams can complete an identical number of features per quarter and have radically different net productivity, because one of them spends thirty percent of its capacity on defects, rollbacks, support escalations, and unplanned maintenance while the other spends eight percent. The first team's roadmap looks the same on a slide and its actual contribution is much smaller.

This is why DORA's addition of deployment rework rate to its metric set was a significant move rather than a technicality. Rework is the visible portion of the productivity that never existed. Measuring it converts an invisible tax into a managed number.

Movement XIX: AI May Make Technical Debt Easier to Create and Easier to Remove

Both directions are genuinely available, and which one an organization travels is determined by incentives rather than by tooling.

On the reduction side, the opportunity is unprecedented. The work that historically made debt reduction uneconomic was mechanical and voluminous: updating hundreds of call sites, migrating a deprecated dependency across a large codebase, writing characterization tests for untested legacy code so that it can be safely changed, documenting systems that were never documented, and translating a service from a language nobody remaining knows. All of that responds extremely well to AI assistance. Projects that were correctly declined for a decade on cost grounds may now be viable.

On the creation side, the risk is equally real. Cheap generation makes it easy to add another abstraction layer rather than simplify an existing one, to write a new internal tool rather than find the one that already exists, to add a special case rather than revisit the model that keeps requiring special cases, and to patch rather than fix. The GitClear data showing refactoring activity falling as duplication rises is the aggregate signature of an industry choosing addition over consolidation, one reasonable local decision at a time.

AI does not determine the direction. It lowers the cost of movement in both directions and leaves the choice to whatever the organization actually rewards.

The question a leadership team should be able to answer, with evidence rather than intention, is whether the capacity released by AI is being spent on simplification or on production. In most organizations no one is currently measuring this, which means the answer is production, because that is the default and defaults win.

Movement XX: Meeting the New Bottleneck With More AI

The obvious counterargument deserves a serious hearing rather than a dismissal.

If AI can accelerate coding, why not use it to accelerate everything else? Specification drafting, requirements analysis, code review, test generation and maintenance, security scanning, documentation, deployment orchestration, log analysis, incident triage. There is no principled reason the technology should be confined to one stage, and considerable evidence that it is already spreading.

This is very likely what happens, and it may produce system-level gains far larger than anything the current data captures. A plausible near-term pipeline runs from AI-assisted customer research and specification, through AI-assisted implementation, through automated review that enforces architectural policy, through autonomous test exploration, through continuous security analysis, into automated deployment, into AI-assisted observability and incident triage. Each stage compressing independently would compound rather than add.

Articles that stop at the current bottleneck and declare the paradox permanent are making a forecasting error. The correct question is not whether AI will spread through the lifecycle. It is which constraints remain after it does.

The Bottleneck Cascade

Constraints do not vanish when they are relieved. They relocate, and the sequence is reasonably predictable.

Stage A. Coding is the dominant constraint. AI compresses it. This stage is substantially complete at the frontier and well underway in the broad market.

Stage B. Review and verification become dominant, which is where the current telemetry says most organizations are. AI and automation begin to assist both, unevenly, with review automation ahead of verification automation.

Stage C. Integration, environments, and deployment become dominant. Platform engineering and delivery automation address them, and the organizations that invested in internal platforms earlier find they have already paid for this stage.

Stage D. Product decisions and organizational coordination become dominant. AI assists analysis. It does not resolve competing mandates, allocate accountability, or decide strategy, so progress here depends on organizational design rather than tooling.

Stage E. Customer attention and market demand become the ultimate constraint. No productivity technology can make customers need unlimited features, absorb unlimited change, or expand their working hours to accommodate a vendor's release cadence.

Stage E is where the argument terminates, and it is worth stating plainly because it bounds the entire discussion. Engineering productivity eventually meets economic reality. A company that can build ten times as much software than its market can absorb has not multiplied its value by ten. It has multiplied its maintenance obligations by ten and its revenue by considerably less.

The strategic implication is that the returns from engineering productivity are largest for companies with genuine unmet demand and a clear understanding of what customers want, and smallest for companies that were already shipping more than their market required. AI does not change which of those a company is.

Movement XXI: The Difference Between Building Faster and Shipping Better

Three goals hide inside the phrase "engineering productivity," and conflating them is how organizations end up celebrating a metric that describes nothing anyone cares about.

Building faster means reducing the cost and elapsed time required to create software changes. This is where AI has delivered most visibly and where most measurement is currently pointed.

Shipping faster means reducing end-to-end lead time from idea to production. This requires the whole pipeline to move, not one stage of it.

Shipping better means increasing the rate at which reliable changes produce meaningful customer outcomes. This requires the pipeline to move and to carry the right things.

An organization can improve the first while failing entirely at the second, which is the pattern the delivery telemetry keeps documenting. It can improve the second while damaging the third, by releasing a high volume of irrelevant changes quickly and calling the resulting churn progress.

The highest form of engineering productivity is therefore not velocity in any of its measurable forms. It is the reliable conversion of engineering effort into customer value, and every metric in common use is a proxy for some fragment of that.

Movement XXII: What CTOs Should Stop Optimizing

Several widely reported measures have become actively misleading in an environment where generation is cheap, and continuing to manage against them will drive the wrong behavior.

Lines of code was always weak and is now nearly meaningless, since the marginal cost of a line has collapsed. Commit counts and pull request counts measure activity that AI inflates directly, and LinearB's finding that AI-generated pull requests merge at roughly a third the rate of human-written ones means that pull request volume and delivered value have partially decoupled. The volume of AI-generated code accepted, which several vendors promote as an adoption metric, tells you about tool usage rather than about outcomes. DORA has publicly warned against the emerging practice of tracking and rewarding raw AI token consumption on internal leaderboards, which converts a cost into a performance indicator. Story point velocity was always a planning instrument rather than a productivity measure and does not survive contact with a changing definition of a point. Feature counts measure surface area, which is a liability as often as an asset.

The measures worth more attention describe flow and consequence rather than effort. Change lead time, from commit to running in production, exposes queue time that activity metrics hide. Deployment frequency indicates batch size discipline. Change failure rate and deployment rework rate expose the portion of output that was never really output. Failed deployment recovery time indicates how expensive being wrong is. Beyond DORA's five, escaped defect rates, adoption of shipped capabilities, operational load per team, and the proportion of engineering capacity consumed by unplanned work all describe things a business actually experiences.

No single metric represents engineering productivity, and any vendor claiming otherwise is selling a dashboard. The practical discipline is to hold a small set of measures that cannot all be improved by the same shortcut, and to watch them together.

Movement XXIII: The Engineering Productivity Map

The frameworks in this article converge on a single diagnostic instrument, which is more useful to a leadership team than any individual metric.

Organize the delivery system into five capacities and assess each honestly.

Creation Capacity. How much useful change can teams produce? Implementation, prototyping, refactoring, documentation. AI is increasing this rapidly and it is the only one of the five that money reliably buys.

Decision Capacity. How quickly can the organization decide what to build, which design to accept, what risk is tolerable, and who owns a contested call? This is a function of authority structure, ownership clarity, and executive availability.

Integration Capacity. How much change can the existing system absorb without becoming unstable? This is set by architecture quality, interface discipline, environment availability, platform maturity, and the degree of coupling accumulated over the system's life.

Verification Capacity. How much change can be evaluated confidently before release? Automated coverage, review depth, test data realism, security analysis, and the specialized judgment that automation does not yet replace.

Learning Capacity. How quickly can the company determine whether shipped changes produced the intended outcome? Instrumentation, analysis, and the organizational willingness to act on unwelcome results.

Effective throughput is constrained by whichever of the five is currently weakest. This is a conceptual model rather than a formula, and the point of it is diagnostic rather than computational.

Its value to an executive is that it makes the reinvestment question answerable. If Creation Capacity has risen sharply and Verification Capacity has not moved, then the correct destination for the AI dividend is verification, and spending it on more roadmap commitments will produce queues and instability. If Decision Capacity is the weakest, then no engineering investment of any kind will improve delivery until the governance problem is addressed. Most organizations have never assessed the five separately, which is why their AI investment defaults to the one that vendors sell.

Movement XXIV: What to Do With the Time AI Saves

If AI genuinely releases engineering capacity, the organization faces an allocation decision, and this decision matters more than which tools it bought.

The Productivity Dividend is the capacity that cheaper generation releases. Management decides where it goes, and the decision is usually made by default rather than deliberately.

There are six plausible destinations, and none of them is universally correct.

The Output Dividend. Build more. Appropriate when the company has validated demand it cannot currently serve and a delivery system with slack downstream. Dangerous when either condition is absent, which is most of the time.

The Speed Dividend. Deliver the same roadmap sooner. Appropriate in genuinely competitive races where timing determines market position. Requires the whole pipeline to move, not just the coding stage, which means it usually cannot be taken without first paying for one of the dividends below.

The Quality Dividend. Reinvest in verification, test automation, environments, and reliability. Appropriate when the verification gap is the binding constraint, which the current telemetry suggests is common. Least visible to executives and most likely to be cut in a budget review, which is precisely why it needs explicit sponsorship.

The Simplification Dividend. Reduce technical and operational complexity. Retire duplicated systems, consolidate services, remove features that no longer earn their keep, pay down architectural debt that has been deferred for years. This compounds, because a simpler system makes every subsequent dividend cheaper to realize.

The Learning Dividend. Invest in instrumentation, experimentation, and customer discovery, so that the organization gets better at choosing what to build rather than faster at building. Appropriate when Learning Capacity is the weakest link, which is more common than engineering leaders like to admit.

The Capacity Dividend. Reduce overload. Lower work in progress, protect focus time, restore the slack that lets senior engineers do architectural thinking and mentorship. This looks like doing less and is frequently the highest-return option, because the constraint in most organizations is senior attention and every other dividend depends on it.

Strong organizations allocate deliberately and differently depending on strategic position. A company in a land-grab market may reasonably take the output dividend. A company carrying reliability damage from a bad year should take the quality dividend. A company whose architecture is strangling it should take simplification. The failure mode is not choosing the wrong dividend. It is not choosing at all, which reliably results in the output dividend being taken by default and the downstream cost being discovered eighteen months later.

Movement XXV: Why Some Companies Will Get 10x Value and Others Will Get 10x More Tickets

The term is used here rhetorically rather than as a forecast, and the contrast is the point.

Two companies adopt the same coding tools in the same quarter with comparable engineering populations.

Company A observes that developers are faster and raises roadmap commitments accordingly. Nothing else changes. Review process, environment provisioning, security gating, release cadence, and prioritization discipline all stay as they were. Within two quarters it has more pull requests waiting longer, larger changes reviewed less carefully, a rising change failure rate, more support load, and an engineering organization that feels busier while shipping approximately the same amount of validated value. Its dashboards look excellent.

Company B observes that developers are faster and treats that as a signal to redesign what happens next. It enforces smaller changes as policy. It moves automated feedback to the author. It funds test automation and environment provisioning ahead of demand. It replaces centralized security gating with secure defaults and targeted review. It shortens the feedback loop from release to customer signal. It kills weak features faster because it can now see which ones are weak. It caps work in progress deliberately.

Both companies bought the same licenses. Their outcomes diverge because one optimized local output and the other optimized the delivery system.

Every major research program that segments its respondents finds this shape: a minority converting AI into organizational results and a majority stuck at individual gains. The consistent differentiator across those studies is not model choice or tool selection. It is the quality of the surrounding system, and specifically the quality of the internal platform and delivery automation.

Movement XXVI: The AI-Native Delivery Organization

It is worth being concrete about what the destination looks like, without drifting into science fiction or predicting engineering teams of zero people.

An AI-native delivery organization plausibly has fewer engineers doing repetitive implementation and more doing architecture, risk assessment, and customer-facing problem definition. Change sets are smaller and more frequent, enforced by policy rather than culture. Verification is heavily automated, with human attention concentrated on categories of risk that automation handles poorly. Security checks run continuously rather than at gates. Review is assisted by agents that enforce organizational standards before a human sees the change. Environments are created and destroyed on demand rather than booked. Regression selection is automatic and risk-based. Observability is comprehensive enough that the effect of a release is knowable within hours. Product feedback loops are short enough that weak ideas are removed rather than maintained.

The defining characteristic is not that everyone uses AI. Nearly everyone already does. The defining characteristic is that the organization has redesigned its delivery system around the assumption that generation is cheap and verification, integration, and decision-making are expensive.

Buying coding licenses does not make an organization AI-native. It makes it an organization with faster typing and the same queues.

Movement XXVII: Why Organizational Redesign Matters More Than Tool Adoption

There is a well-documented historical pattern here, and it is specific enough to be useful rather than merely rhetorical.

The economist Paul David's 1990 analysis of electrification examined why productivity statistics failed to reflect a transformative technology for decades. Electric motors were commercially available from the 1880s, yet by around 1900 they accounted for a small fraction of factory mechanical drive, and the manufacturing productivity acceleration did not arrive until the 1920s. The delay was not caused by any deficiency in electricity. It was caused by how factories first used it.

Nineteenth-century factories were built around a central steam engine driving overhead line shafts, with belts and pulleys distributing power to machines. The building's layout was dictated by the mechanics of power transmission. When electricity arrived, the first generation of adopters replaced the steam engine with a large electric motor and connected it to the same shafts. This worked. It saved some fuel. It changed almost nothing about output, because the factory was still shaped by a constraint that no longer existed.

The gains arrived when manufacturers abandoned the line shaft entirely and gave each machine its own motor. That change permitted the factory floor to be arranged according to the logic of the work rather than the logic of power distribution, which enabled continuous flow production, which is where the productivity actually came from. The technology was the enabler. The reorganization was the cause.

David wrote the paper to explain the computing productivity paradox of his own era, in which computers were visible everywhere except in the productivity statistics, and the same pattern has recurred with enterprise software, cloud infrastructure, and DevOps. Each produced modest gains when inserted into existing processes and substantial gains when organizations restructured around what the technology made possible. Cloud migration that preserved quarterly release trains produced expensive hosting. Cloud migration accompanied by continuous delivery produced something else entirely.

Apply this to AI. An organization that inserts coding assistants into slow approval chains, siloed teams, brittle architecture, manual verification, and quarterly release trains will improve coding and will not transform delivery. The line shaft is still there. It is now called the change advisory board, the shared staging environment, and the release calendar.

DORA's own framing lands in the same place from a different direction: the greatest returns come not from the tools but from the underlying organizational system, and without that foundation AI produces isolated pockets of productivity that dissipate downstream.

Movement XXVIII: The Paradox May Be Temporary

The strongest counterargument to everything above is that the current mismatch is transitional, and it deserves to be taken seriously rather than acknowledged and dismissed.

Coding was transformed first because it was the easiest part of the lifecycle to transform. The interface was text, the feedback was fast, the training data was abundant and public, and the evaluation was partially automatable. Nothing about that ordering implies that the rest of the lifecycle is resistant. It implies that the rest of the lifecycle was harder to start on.

The frontier is already moving outward. Agentic systems are being applied to issue decomposition, multi-file changes, review, test generation and maintenance, documentation, release orchestration, and incident triage. METR's own tracking of autonomous task horizons suggests the length of task that models can complete unaided has been extending steadily. If verification, integration, and operational stages compress over the next several years the way generation compressed over the last two, then system productivity may catch up with task productivity and the gap documented in today's telemetry may look like a snapshot of an awkward transition rather than a structural law.

There are reasons for caution about how complete that catch-up will be. Verification of correctness requires a specification of correct, and in most enterprise contexts that specification does not exist in written form. Accountability does not distribute across autonomous systems the way work does, and regulated industries will not accept that it should. The last stage of the cascade, customer attention and market demand, is not a technology problem at all.

The most defensible position is therefore neither that the paradox is permanent nor that it will dissolve on its own. The paradox identifies the work an organization must do before local AI gains become system-level gains. Companies that do that work will realize the compounding returns early. Companies that wait for tooling to solve it will realize them later, having spent the intervening period accumulating queues, surface area, and instability.

The Release Moves When the System Does

Return to the change that finished in a morning.

The engineer was genuinely faster, and that mattered. The code was real, the time saved was real, and the experience of working that way is not an illusion, whatever the measurement difficulties. Nothing in this analysis argues that AI fails to make developers more productive. Most of it argues that the industry has been measuring one layer of a six-layer system and reporting the result as though it described the whole.

The release date moved only when the organization changed what happened after the code existed. When the specification was clear enough that the implementation encoded a decision someone had actually made. When the change was small enough to review properly. When verification was automated enough to run in an hour rather than scheduled for Tuesday. When the security question had been answered structurally rather than individually. When the environment was available because it was created on demand. When the decision about the API contract had an owner who could make it in an afternoon.

Software companies spent forty years trying to make the act of producing code cheaper, through better languages, better libraries, better tooling, better methodologies, and better hiring. AI has done more on that front in three years than any of them did in a decade. The consequence is not that the problem is solved. The consequence is that the problem has been replaced by a harder and more interesting one, because every other weakness in the delivery system is now the thing standing between an idea and a customer, and those weaknesses were always organizational rather than technical.

The companies that win the next decade will not be distinguished by having the fastest coding tools. Those are purchasable, and within eighteen months everyone will have comparable ones. They will be distinguished by having built an organization capable of converting cheap, abundant implementation capacity into better decisions, shorter queues, stronger verification, simpler systems, faster feedback, more reliable releases, and products that customers actually adopt. That conversion is a design problem, it belongs to leadership rather than to a tooling team, and nobody is going to ship it as a feature.

---

A Note on the Evidence

The research base for AI developer productivity is genuinely mixed, and the disagreements between studies are informative rather than embarrassing. Findings vary systematically by task type, codebase maturity, developer seniority, tool generation, and study design, and the same tool can produce a large measured speedup in one setting and a measured slowdown in another. Readers evaluating any productivity claim, including those in this article, should ask what exactly was measured: task completion time, code acceptance, developer perception, delivery lead time, deployment frequency, or business outcome. Those answer different questions and are not interchangeable.

Principal sources drawn on here:

• METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025, arXiv:2507.09089); We are Changing our Developer Productivity Experiment Design (February 2026), which reports the later study's raw estimates and the selection effects that make them unreliable; Task Substitution and Uplift (May 2026); and Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity (May 2026).
• DORA / Google Cloud. Accelerate State of DevOps Report 2024; State of AI-assisted Software Development 2025 and the accompanying AI Capabilities Model; The ROI of AI-assisted Software Development (2026); the Balancing AI tensions insight (March 2026), drawn from 1,110 open-ended responses from Google engineers; and A history of DORA's software delivery metrics (January 2026) for the current five-metric definitions.
• Peng, Kalliamvakou, Cihon and Demirer (Microsoft Research, GitHub, MIT Sloan), The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (2023, arXiv:2302.06590).
• Cui et al., field experiments at Microsoft, Accenture and a Fortune 100 firm on the productivity effects of GitHub Copilot.
• Stanford Software Engineering Productivity research (Denisov-Blanch and colleagues) on greenfield versus brownfield gains and the share of gross output consumed by rework.
• Faros AI, The AI Productivity Paradox telemetry report, covering more than 10,000 developers across 1,255 teams, which named the pattern this article's title refers to.
• LinearB, 2026 Software Engineering Benchmarks Report, covering more than 8.1 million pull requests across 4,800 organizations.
• GitClear, AI Copilot Code Quality (2025) and The Maintainability Gap (2026).
• Veracode, 2025 GenAI Code Security Report and its Spring 2026 update.
• Paul A. David, The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox, American Economic Review (1990).

Where vendor research is cited, it is identified as such. Several of the organizations publishing delivery and quality telemetry sell products that address the problems their research identifies, which does not make the data wrong but does warrant reading the framing separately from the measurements.