A reflection on how AI is repricing engineering work, why the impact is uneven, and where human judgment is concentrating.
1. Introduction
A common framing of AI's effect on software development is that it makes engineers faster. This framing is true at the surface level and misleading at every level beneath. AI does compress the time required to translate a design into code. It does not, on its own, compress the time required to do software engineering, of which writing code is one activity among several. The difference between those two claims is small in language and large in consequence.
The argument here is that the economic shift now reshaping software services is not really about productivity. It is about which parts of engineering work get repriced and which parts do not — and about how organizations that have implicitly priced their value around the wrong parts are now exposed. The companies that will adapt successfully are those that recognize the asymmetry and reposition themselves around the parts of engineering work that AI commoditizes least.
To take that seriously we need a way of reasoning about why some engineering work is more sensitive to AI than other engineering work, and why the same AI tool can produce strongly positive results on one system and net-negative results on another. Speed is the visible part; learning and ownership are moving too, and we have not measured them well. The first half develops that way of reasoning. The second half draws out what follows from it.
A note on how to read this. The arguments come from work on real client systems, reasoned through, and put next to published research where it helps. That client work is evidence. It is not plotted here. The main references are DORA 2025 (nearly 5,000 practitioners), the 2024 DORA findings it revisits, and METR's 2025 trial of AI tools on mature open-source work. The charts are directional, not fitted to our repositories. Where we are guessing at a shape rather than reporting a measurement, that will be said plainly.
2. The economics of software engineering
2.1 Productivity declines with system maturity
A common observation across engineering organizations is that the same team produces less per unit time as the system it works on matures. This is not a controversial claim among practitioners. New projects feel fast; old projects feel slow. The team is the same, the engineers are the same, the working hours are the same — but throughput, measured almost any way one chooses, falls.
A simple proxy for the shape of this effect is lines of code (LOC) produced per active engineer per unit time. That is not productivity. It is a stand-in for how much visible code a given engineer produces as the system accumulates history — steep early, flattening toward a low asymptote. Figure 1 is that shape, not a dataset. Why we use the number at all, and why it is the wrong measure of value, is section 3.1.
Illustrative shape, not measured data
The shape is old. Lehman's laws of software evolution, formulated from the 1970s onward on systems that had to keep matching a changing world, already stated that real-world software must be continually adapted, and that unless work is done to contain it, complexity grows. The 60/60 rule, stated by David Wood in 97 Things Every Project Manager Should Know (O'Reilly, 2009), puts numbers on the same fact of life: about 60% of lifecycle cost is maintenance, and of that maintenance about 60% is user-driven enhancement, 23% migration, and 17% bug fixes. Wood also notes that roughly 30% of maintenance time is spent understanding the existing product — the cost of reconstructing context. Lientz and Swanson's 1980 survey of hundreds of organizations is the original source for maintenance dominating the lifecycle; later industry commentary, including figures commonly attributed to IBM (roughly 50–75%) and to Gartner IT-budget surveys (often cited in the 55–80% range), clusters in the same band. The methods vary, and some of the later figures are poorly sourced in secondary retellings, but the direction is stable: most engineering capacity is spent on systems that already exist, and the cost of producing change in those systems is higher than in greenfield ones.
The question worth asking is not whether the curve is real — it is — but what drives it.
2.2 Cognitive load as the driver
The claim here is that the productivity curve declines because of cognitive load (Sweller): the amount of context an engineer must hold in mind to make a correct change to the system.
This is more precise than it may sound. When an engineer modifies a young system with one integration and a small domain model, they hold the entire relevant context in working memory. The system fits in their head. When the same engineer modifies a mature system with thirty integrations, eight years of historical decisions, undocumented edge cases, and a domain model that no single person fully understands, they do not hold the entire relevant context. They hold a subset, augmented by guesses, assumptions, and recourse to documentation, code reading, conversations with colleagues, and trial-and-error. Each modification takes longer because each modification requires reconstructing context that was once free.
The model can be expressed compactly:
Cognitive load CL = f(C, K(t))
where C is the system's intrinsic complexity (domain depth, integration surface, edge case density), K(t) is the accumulated context the system carries (history, undocumented decisions, conventions, architectural intent), and t is time.
This is a sketch, not an equation. There is no measured formula for f, and C and K are not cleanly countable. The structure is still useful. It says three things:
First, cognitive load is bounded below by complexity. A system with high intrinsic complexity will require significant cognitive load to modify even on day one. There is a floor.
Second, accumulated context grows over time. Every architectural decision, every workaround, every domain refinement, every integration adds to K. The growth is bursty rather than smooth — context accumulates in jumps, when major changes or integrations land — and the default trend is upward.
It is possible to slow that growth, and in a narrower set of cases to reduce K. That possibility is not a free lever. Most of the work teams reach for when they say they are "reducing complexity" — tests, documentation, process, additional layers of indirection — is itself an artifact that must be maintained, supported, and updated. The scaffolding you add so an agent can work is the same kind of thing. Those artifacts join K; they do not subtract from it. Complexity is also not the same as modifiability. Making a system more legible or more safely changeable can leave its intrinsic complexity intact, or raise it, while changing how costly a given modification is. The interventions that actually reduce complexity are a subset of architectural changes, and they compete with feature work: capacity spent flattening or reducing K is capacity not spent on new features. The mix shift in section 2.4 is that tension at organizational scale.
The practical result of ordinary development is that the curve flattens. K grows more slowly than it would with no attention to structure, and rarely reverses. Reversal requires steering a large share of development effort at reduction itself — which is not how organizations spend their engineering time, and which is itself the higher-cognitive-load work described in the next section. Absent that, K(t) grows.
Third, time alone has no direct effect on cognitive load. A system that exists for five years but accumulates no new context (no integrations, no decisions, no edge cases) has the same cognitive load it had on day one. What matters is what happens during time, not time itself. You cannot make time pass slower. You can affect the rate at which context accumulates, and you can spend effort on the uncommon architectural work that actually reduces complexity, at the cost of feature throughput.
The cognitive load model explains the productivity curve straightforwardly. As K(t) grows, the cognitive cost of each unit of engineering work rises. The throughput of any individual engineer falls as a function of how much context the system requires them to hold. The curve declines not because engineers get worse — they don't — but because the system gets harder to think about.
2.3 Three kinds of work
The cognitive load required for an engineering task is not constant across kinds of work. The relevant question is: how much of the system must the engineer hold in mind to perform the operation while keeping the existing pieces in place? Three categories cover most engineering activity. Ordered by how much of that guarantee they typically demand, they are:
New features sit at the lowest cognitive load. They extend the system in a forward-looking direction. Additions are not usually breaking changes — unless the feature work includes a refactor as part of delivering it — so the engineer can often localize attention to the new surface plus whatever it must call. The work is not trivial, but the context it requires is bounded by the scope of the feature rather than by a requirement to re-prove the rest of the system.
Refactoring and tech debt remediation sit in the middle. The deliverable is a change of shape with a guarantee that behavior is preserved. To give that guarantee the engineer must understand what the piece currently does, why it was structured that way, what depends on it, and what the consequences of moving it will be. That is substantial cognitive load, and it cannot be localized away from the dependency surface. Documentation work belongs here as well — it reconstructs the same kind of context, with a different artifact.
Fixes and debugging sit at the highest cognitive load. To fix a bug, the engineer must understand not just what the system does but what it failed to do, when, and why. The guarantee is restoration of intended behavior, which is a claim about a causal chain the engineer was typically not present for. Debugging is reverse-engineering with a goal of intervention. It is, in cognitive terms, the most demanding work software engineers routinely do.
This is a generalization, not a measurement. A one-line refactor is not higher-load than a feature that cuts across twelve services. The ordering is about typical work, and about what you have to know to give the guarantee the work requires. It is also about how cognitive load sits against visible output. New features tend to be lower CL and higher LOC: a lot of code, a bounded surface. Refactoring sits in the middle on both. Debugging tends to be high CL and low LOC: little code, a large reconstruction. That is what makes the mix shift expensive. The organization spends more time on work that produces less of the thing the market can see. It is the same generalization as the greenfield claim later: the scarcer the existing surface you must keep intact, the less context the work demands.
What follows is an expected shape per category, not a measured one. Each category should have its own curve over project maturity, with steeper declines where the guarantee is heavier. New features should decline relatively slowly: cognitive load matters, but additive work limits how much of K(t) must be reconstructed. Refactoring should decline faster, because the work is the entanglement with K(t). Fixes and debugging should decline fastest, because they are bottlenecked by reconstructing context that was never written down.
Illustrative shape, not measured data
2.4 The organizational consequence
The same thinking has a consequence at the organization, not only at the individual engineer. As systems mature, the mix of work changes.
Early in a project, almost all engineering effort goes to new features. The system has no significant tech debt because it has no significant history. It has no bug backlog because it has no significant production exposure. The category mix is dominated by greenfield work.
As the system matures, this mix changes. Tech debt accumulates and demands attention. Production exposure produces a steady stream of bug reports and edge cases. Migrations become necessary as dependencies, infrastructure, and platform standards evolve. The share of effort going to refactoring grows. The share going to fixes grows. The share going to new features shrinks — not because the organization stops valuing new features, but because the same engineering capacity now has to be split across more categories of work.
This is the tension in section 2.2 at organizational scale. Work that might flatten K — refactoring, tests, documentation, migrations — is exactly the work that takes share from features. Tests and docs, once written, join the system that has to be maintained. Wood's 60/60 decomposition is the mature-system end state of that shift: most lifecycle cost is maintenance, and most of that maintenance is enhancement, then migration, then fixes. Lehman's law of continuing change is the same observation over a longer horizon: a system that remains useful is a system whose mix never returns to greenfield.
Illustrative shape, not measured data
The compound effect on organizational throughput is steeper than the per-engineer curves alone would suggest. Each engineer's per-category output declines (the per-engineer curves), and the organization spends a growing share of its capacity on the categories where the decline is fastest (the mix shift). The two effects combine to explain why mature software organizations need disproportionately more headcount to maintain the same outcome velocity. It is not that engineers get less productive in absolute terms. It is that the work the organization needs done is increasingly the work that the cost of change rises fastest on, and the work that produces visible value (new features) is increasingly squeezed by the work that doesn't (maintenance).
This is the economic reality that any service company building software for clients has been operating in for decades.
3. AI's actual impact, not its marketed one
3.1 Why we still talk in LOC
Before discussing AI's effect on the economics described above, it is worth being explicit about the choice of metric. LOC per engineer is a commoditization proxy. It is not an outcome metric — not productivity, not value, not quality, not "engineering getting done." DORA has long argued against treating output counts as measures of performance. Nothing here treats a movement in LOC as a success or a failure.
The reason we use LOC anyway is that it is the proxy for what AI commoditizes. AI agents — harness plus large language model plus tooling — are very good at producing code from a sufficiently specified intent. They are less good, sometimes much less good, at producing the higher-order outputs of engineering: deciding what to build, deciding how to structure it, deciding what to leave out, debugging across system boundaries, navigating organizational constraints, making judgments under partial information.
LOC, as a measure, is biased toward exactly the part of engineering AI is best at once the higher-order inputs are locked in. That is the whole reason it is the wrong measure of value, and also the right measure of what AI affects. The two facts are the same fact viewed from different angles. The activities that LOC captures cleanly — the visible, mechanical, output side of engineering — are the activities AI commoditizes hardest. The activities that LOC underrates — the design, architectural, judgment, and contextual work — are the activities AI struggles with.
This is not coincidence. Both facts have the same root cause: coding output is the visible, measurable, externalizable part of engineering, and the deeper work is invisible because it produces decisions rather than artifacts. LOC measures the visible part because that is what is measurable. AI commoditizes the visible part because that is what is more automatable. Higher-order work can be automated too; not out of the box, once CL is high. The same property — visibility — drives both.
It follows that an analysis of how AI affects the cost of producing engineering output (which is what an LOC-based analysis tracks) tells us something specific and interesting: it tells us where, along the cognitive load curve, AI's effect is concentrated.
3.2 The cost collapse and the bundle break
Until recently, the perceived value of engineering services was anchored to engineering output — the artifact of code being written. This was not an arbitrary anchoring. Coding is where most engineering hours went, and most engineering invoices itemized. Our clients paid for code to be written because that was what they could see being produced.
This anchoring was always slightly wrong. Design, architectural intent, judgment about scope, domain modeling, debugging instinct, organizational navigation — these were always part of engineering, always part of the value, but bundled invisibly into the price. Our clients were buying engineering; they thought they were buying coding; the discrepancy went unnoticed because the dominant line item happened to be coding hours.
AI agents collapse the cost of coding. Not the cost of all engineering — only the cost of the specific activity of translating a sufficiently-specified intent into source code. But that activity was the dominant line item, and our clients' mental model was anchored to it. When the dominant cost component falls dramatically, two things happen at once. First, the actual cost of producing engineering output falls — though by less than the LOC-anchored view would suggest, because the non-coding components are not affected. Second, the bundle starts to break: coding is no longer a reliable stand-in for engineering, and our clients have to work out what they were actually paying for. That seeing is underway, not finished.
The market is, in real time, repricing engineering. Companies whose value was actually concentrated in the coding component lose ground because the coding component just got cheap. Companies whose value was concentrated in the components AI does not commoditize are the ones the market is beginning to distinguish — because those components are what remain when coding gets cheap. The repricing is not a change in what engineering is worth. It is a correction in how engineering is perceived to be worth what it is worth.
3.3 The asymmetric distribution
The more interesting question is where along the curve AI's effect actually lands. AI is sometimes discussed as if it produces a uniform productivity boost across all engineering work — as if it raises the entire curve. Section 2 predicts otherwise. This is not a 2026 coefficient. It is a claim about shape: benefit is largest where little existing surface must be kept intact, and shrinks as the work becomes a guarantee over accumulated, often implicit, context.
If cognitive load is what drives the cost-of-change curve, then the activities most insulated from cognitive load should benefit most from AI. New features, with their bounded context, should see the largest gains: the AI is asked to translate well-specified intents into code in a context the engineer can easily verify, and the activity is largely the activity AI is best at. The boost should be substantial — possibly transformational — for greenfield work.
Refactoring sits differently. The engineer's task is not just to produce code but to produce code that fits with what already exists, preserves invariants the engineer themselves may not fully understand, and respects constraints that are not specified anywhere. AI can help with the mechanical parts of refactoring, but the work itself is bottlenecked by the engineer's understanding of K(t). The boost is real but smaller, and it is bounded by the same cognitive load that bounds the human engineer.
Fixes and debugging sit hardest of all. Debugging is reverse-engineering toward a goal that is itself partially understood. Much of the work is hypothesis formation, evidence gathering, and judgment under uncertainty. AI can assist with parts of the workflow — a hypothesis, a repro, a proposed patch, looking up and digging through the data — but the bottleneck is unchanged: the engineer still has to understand what is broken and why, and still has to give the guarantee that the rest of the system holds. The model predicts the smallest boost here. It does not predict that the boost is identically zero, and we do not have a measurement that says it is.
Illustrative shape, not measured data
The result is a benefit curve that is roughly inverse to the cognitive load curve. Where cognitive load is low — little existing surface to keep intact — AI should help most. Where cognitive load is high — the work is the guarantee — AI should help least. Figure 4 is that expected shape. It is not fitted to a dataset.
Published research does not measure this curve. It does have results that sit at the two ends of it. They should not be averaged, and they should not be read as current effect sizes.
In 2023, Peng, Kalliamvakou, Cihon, and Demirer gave professional developers a greenfield task: implement an HTTP server in JavaScript. With GitHub Copilot, the treatment group finished 55.8% faster. Bounded context, a spec you can check, almost no existing surface to preserve. That is a snapshot of the left side of Figure 4, for that task and that tool.
In 2025, METR ran a randomized trial on the other side: 16 experienced open-source developers, 246 real tasks, on mature repositories they already knew — on the order of a million lines of code, about five years of personal history on the project. With early-2025 tools, typically Cursor Pro and Claude 3.5/3.7 Sonnet, they took 19% longer. Before the study they forecast a 24% speedup; after it they still believed they had been about 20% faster. The stopwatch disagreed. METR's factor analysis is more useful to this model than the 19% is. Developers were slowed more on work they already knew how to do from memory. Models lacked tacit repository knowledge — in one developer's words, the model "doesn't know we need to take care of this weird case of backwards compatibility and [thus] keep this specific line. And this is very hard to give as context." They accepted well under half of Cursor's generations, and spent a material share of the AI-allowed time reviewing and cleaning output. That is implicit K, a high human bar, and a verification tax, observed under those models and that harness.
Those effect sizes are dated. Peng is a 2023 Copilot experiment. METR is an early-2025 snapshot; a year of models and harnesses is a long time, and METR later said they no longer take the slowdown as a description of current tools, while also saying their 2026 follow-up is too selected to quote as a speedup. We are not claiming that experts on mature systems are 19% slower in 2026, or that greenfield work is 56% faster. We are claiming that the shape showed up clearly: large measured gains where the map is small, and, in at least one careful trial on high-K systems, a result that could go to zero or negative while the people doing the work felt the opposite.
DORA's 2025 survey, fielded June–July 2025, sits in the felt column and is nearer in time. More than 80% of nearly 5,000 respondents said AI increased their productivity; 30% reported little or no trust in the code it generates. People also use AI across categories, not only on greenfield: among those whose jobs include the task, 71% use it for writing new code, 66% for modifying existing code, 59% for debugging, 55% for maintaining legacy. Usage is not the same as returns. The argument is about the latter.
AI does not lift the whole curve. Headline numbers are taken from the low-cognitive-load end of the work — bounded greenfield tasks, and self-report — and therefore overstate the effect on the work most organizations spend their time on. The confusion in the market is in part this gap: people can feel faster, and report faster, on systems where the existing surface that must be kept intact is large, and where feeling faster is not the same as being faster.
4. The architectural fork
4.1 Two AI trajectories on the same system
The most important observation here is that AI's productivity effect on a given mature system is not a single number. It is two numbers, depending on what the engineering team has done — not to the model or the harness, but to the substrate the agent stands on. That substrate is three things: the architecture (boundaries, coupling, whether a change can be made in isolation); the explicit inventory of K (tests, types, docs, records the agent can actually see); and feedback that runs (isolation and checks that show a broken change without paying in production or in a human's head).
Consider two organizations operating systems of similar age and complexity. Both add AI-augmented engineering to their workflow. In one case, the substrate is what we will loosely call agent-grade: comprehensive acceptance tests that capture system behavior at the boundary of useful units; a unified context layer that makes accumulated knowledge legible and queryable; isolated execution environments that let agents try changes without consequence; feedback that runs against those tests before a change lands. In this case, AI helps. As cognitive load grows over the system's lifetime, the AI productivity boost shrinks — the model predicts this — but it remains positive. The "with AI" curve sits above the "without AI" curve at every point along the maturity axis.
In the other case, the system has none of those properties. Tests are partial. Context is implicit, lives in engineers' heads, and is not legible to anything outside their heads. Agents have no isolated environment in which to experiment. There is no automated feedback loop on agent output beyond the same limited testing the human engineers also rely on. In this case, AI does not help, in any sustained way. On greenfield work it still helps — the system isn't yet accumulating much context, and the agent's mistakes are easy to catch — but as the system matures, the same agent that produced positive output on greenfield work begins to produce churn. It generates plausible code that breaks invariants the agent doesn't know exist. It introduces regressions that the limited test surface fails to catch. It costs review time that exceeds the time saved on production. The "with AI" curve in this case eventually crosses below the "without AI" curve. The agent is, at this point, net-negative.
Illustrative shape, not measured data
This is the architectural fork. The same AI tool, applied to systems of similar age and complexity, produces opposite outcomes depending on the substrate: whether K is legible outside a head, and whether a wrong change is cheap to see and cheap to undo.
DORA's 2025 report is the industry-scale version of this claim, stated more broadly than architecture. Their headline: AI is an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. Without a foundation — platform quality, workflow clarity, data the tools can actually reach — AI creates "localized pockets of productivity that are often lost to downstream chaos." They did not draw Figure 5. They measured whether more AI adoption helps or hurts depending on the system the tool is nested in.
A field illustration, not a survey number: in the Adidas generative-AI pilot reported in that report's foreword, teams in loosely coupled architectures with fast feedback loops saw on the order of 20–30% gains in commits, pull requests, and feature-delivery velocity; teams tightly coupled to ERP systems, with slow feedback, saw little or none. Same generation of tools, opposite outcomes, substrate different.
The 2024 DORA results read like the lower fork. More AI adoption went with lower software-delivery throughput and higher instability — they estimated, that year, about 1.5% less throughput and 7.2% more instability for each 25% increase in AI adoption. In 2025 the throughput relationship flipped positive; instability still rose. That is the pattern the poor-architecture curve is for: speed can come back while the system still cannot absorb the extra change.
4.2 Why the fork is architectural, not technological
The temptation is to read the fork as a difference in tooling — that some teams have better agents than others, or better integrations, or more advanced platforms. This is wrong, or at least insufficient. The same agent run by the same operator on two different systems produces different results. The variable in the fork is not the agent. It is the substrate the agent is standing on.
The operator still matters. It is a different slider. Seniority changes how much of K is already in the head, so it changes the size of the boost — more room to help, and more room to be wrong, when less of the map is already held. It does not draw a different fork. The fork is what you get when you hold the person fixed and change the substrate.
What distinguishes a system on which agents work from a system on which agents don't is not a smaller C. It is whether the agent can see K, and whether something runs when the agent is wrong. Recall from section 2 that K(t) — the accumulated context — is what drives cognitive load. A system can carry a high K(t) in two ways. It can carry it implicitly, in the heads of long-tenured engineers and in the lore of how things work, where the context is real but invisible. Or it can carry it explicitly, in tests that codify expected behavior, in documentation that captures intent, in architectural boundaries that constrain what kinds of changes are valid, in tooling that surfaces what depends on what.
Making K explicit does not shrink it. A test that encodes an invariant relocates that invariant from a head into an artifact: the engineer, and the agent, can run it instead of remembering it. The artifact still has to be maintained. That is the offload we can actually buy — verification load, not a smaller system — and it is why agent-grade work is expensive in the sense of section 2.2. It competes with features, and it joins K.
A human engineer operating on a system with implicit K(t) can make progress by gradually internalizing the system over months and years. The cognitive load is still there; the engineer pays it through experience. An agent has no such ramp. The agent operates only on what is legible to it. If K(t) is implicit, the agent does not have access to it. The agent will produce changes consistent with what it can see, which is the codebase, the comments, and whatever documentation is fed to it — and inconsistent with the implicit context it cannot see. The result is plausible-looking changes that violate invariants nobody wrote down. If feedback does not run, those changes are not cheap to see either. The review tax lands on the human, which is the lower fork.
The architectural work that makes agents productive is, at root, building that substrate. Architecture that lets a change be isolated. Explicit inventory so K is queryable. Feedback that runs so a wrong change is an executable fact rather than a conversation. Tests, types, and records are the inventory. Isolation and CI are how you find out the agent was wrong without paying in production or in someone's head.
None of this is software the agent does for itself. All of it is engineering work done by humans, often before the agent shows up. And the work is not free. Building agent-grade architecture is itself substantial engineering investment. It pays off — but only if the team does it.
DORA's 2025 AI capabilities model names several of the same conditions, in their vocabulary: AI-accessible internal data, strong version control including rollback, working in small batches, a quality internal platform. Those are not a different theory. They are the operational names for "K is queryable" and "a wrong change is cheap to see and cheap to undo." Two of their seven capabilities — a clear AI stance, a user-centric focus — are organizational, not architectural. We are not claiming the fork is the whole DORA model. We are claiming the architectural slice is the part that determines whether an agent is operating on the map or guessing at it.
4.3 What this does to the productivity claim
The reframe enabled by the fork is significant. The claim "AI makes engineers more productive" is not false, but it is incomplete. A more accurate claim is: AI amplifies the consequences of the substrate. DORA's 2025 wording is the same claim at organizational scope: AI amplifies what is already there. Our version is narrower. The thing being amplified, for an agent, is whether K is legible and whether feedback runs. On systems where that work has been done, AI is a meaningful productivity boost. On systems where it hasn't, AI is at best neutral and at worst a productivity drag. The same tool, the same agent, the same model — different result, depending on architecture, explicit inventory, and feedback that runs.
This is, in retrospect, what the cognitive-load sketch already implied. AI does not reduce cognitive load. It adds to it: skills, docs, harnesses, the extra artifacts you need so the agent works at all. Those join K. What AI reduces is the cost of activities that are not bottlenecked by cognitive load — coding output, mostly. The activities that are bottlenecked by cognitive load are bottlenecked just as hard for an agent as they are for a human. The agent is faster at translating intent to code; it is not faster at understanding what the system already does, why it does it, and what changing it would break.
The bottleneck moved. It was never typing speed. It was, and remains, context. AI does not reduce the importance of cognitive load. It raises it — because an agent operating without good context is not just a slower individual. It can be a regressive outcome: more change, less certainty that the change is right.
DORA's 2025 results look like that relocation at industry scale. Friction, in their data, does not fall with AI adoption. Burnout does not either. Friction does not vanish; it moves. Time that used to be spent writing is re-spent prompting, waiting, and reviewing output that looks remarkably like correct code — a verification tax. Thirty percent of respondents reported little or no trust in AI-generated code. You cannot skip the check. Software delivery instability still rises with AI adoption, and they found no evidence that higher throughput blunts the damage of that instability for product performance or burnout. Speed without feedback that runs is not a free lunch. It is more change arriving at a system that still cannot tell, cheaply, whether the change is right.
This is not DORA measuring cognitive load. It is DORA observing the bill when coding gets cheaper and the guarantee does not: the bottleneck remains context, and if the substrate does not hold the guarantee, the human does.
5. Implications for software engineering as a service
The economic shift described above has direct implications for any company whose business is providing software engineering services to clients. The implications operate on three timescales.
In the short term, the pressure is not one thing. Work is being subsidized: the same price tag is asked to cover more output. That demand is calibrated to the wrong productivity story — marketed and self-reported gains, and a new sense of how long something should take — which, as we said, overstates the work most systems actually need. And the substrate still has to be built. Agent-grade architecture, explicit K, feedback that runs: that is extra inventory, done with the skill set the team already has, not a free upgrade sitting next to the old practice. This pressure is real and immediate. It does not require AI to be good enough to replace engineers. It only requires our clients to believe the easy-speed story enough to ask for more, or for less money, or both. Service companies whose value proposition is anchored to coding throughput will feel it first.
In the medium term, the actual value proposition of engineering services is migrating. The activities most insulated from AI commoditization — design, architectural intent, domain modeling, judgment about what to automate, the work of making K(t) legible — were always part of the service but were bundled invisibly into the price. As the bundle breaks, these activities have to be priced and sold explicitly. The companies that adapt fastest are those that recognize the migration early and reposition their offering around it: not "we will write your code" but "we will produce the architectural work that makes your AI-augmented engineering organization productive." The phrasing is different; the underlying activity is largely what the best service companies were doing all along.
In the long term, a structural shift occurs in what software engineering services even means. If AI agents perform an increasing share of mechanical engineering work, the service component of software engineering becomes increasingly the human-amplified parts: architectural design, cross-cutting decisions, domain expertise, judgment under uncertainty, the work that requires understanding the client's business as deeply as the client does. That is the automation paradox: the more of the mechanical work you hand off, the more the remaining human work matters. The human stays in the loop. The loop just fires less often, and is harder when it does — monitoring, exceptions, the guarantee. The engineering capacity a service company provides becomes less a quantity of throughput and more a quality of judgment. The pricing model for this is unsettled — time and materials no longer maps cleanly to autonomous-agent output, and outcome-based pricing has its own well-known difficulties — but the directional shift is unambiguous.
The short-term pressure does not wait on the substrate. DORA's felt column is already there: most people report a productivity increase, while trust is incomplete and delivery instability still rises. Our clients, pricing services as coding throughput, have that self-report on their side even when the guarantee has not moved. A platform is not enough by itself. DORA finds platform engineering nearly universal, and still finds that quality is what turns local coding speed into organizational return.
How service companies compound advantage is the same distinction. Hiring quality, process, domain knowledge, and reputation still matter. They are no longer sufficient on their own. The compounding layer is the substrate in section 4: architecture that isolates change, explicit inventory the tools can see, and feedback that runs. A company that does not invest there scales only as fast as it can hire.
6. A position
We have built our engineering practice around the work AI most depends on — architectural design, domain modeling, process discipline, and the judgment that determines whether agents produce value or churn. That was true before AI agents existed. It is more valuable now that they do.
The durable layer of value, as we read the evidence, is not code-generation speed. That layer is already commoditized at the model, and increasingly at the harness. The durable work is the substrate: making K(t) legible, structuring systems so they can be changed safely, producing the conditions on which AI delivers anything like its theoretical gains. We would rather compete on that work, done on real systems with real consequences, than on throughput of generated code.
This is not a hype bet. AI is how software will be built. Our position is to drive it: do the real engineering, improve our clients' systems, making them agent-grade, and build a platform that does not assume only humans in the loop — it accounts for agents as well. We do not claim the directional sketch is a measured equation; it is not, and the places where shapes are asserted rather than measured have been flagged. We do claim that a practice organized around architectural depth, explicit context, and feedback that runs is the one we intend to keep.
The economics of software engineering are shifting. The organizations that build for the shift, rather than against it, are the ones that will define what comes next.
Appendix: On evidence and limits
This piece draws on three kinds of evidence: published research (listed below), implication from the cognitive-load sketch, and observation from real client work. The last of those is what the argument is built on. It is not what the charts are. The charts — especially the per-category curves, the mix shift in section 2.4, and the architectural fork in Figure 5 — are illustrations of a shape, not measurements of our repositories, and not fits to DORA, METR, or Peng.
The sketch CL = f(C, K(t)) is there to reason with, not to forecast with. Try it against your own experience of mature versus greenfield work, of systems with high versus low architectural discipline, of agent-augmented work that has succeeded versus work that has not. If it reproduces the broad shape of those observations, it is doing its job. If it does not, it should be revised.
We are currently measuring the productivity-decline curve against Crunchloop client repositories: per-category LOC/dev curves and resource-allocation mix from real history, with the categorization quality called out and confidence reported. When those numbers exist, they will replace the illustrative shapes — and may force the argument to change. That is the point. We are committed to the direction and prepared to revise it.
Sources
Cognitive load
- John Sweller, Jeroen van Merriënboer, and Fred Paas, "Cognitive Architecture and Instructional Design," Educational Psychology Review 10 (1998). Intrinsic, extraneous, and germane load — the reference for CL.
- Lisanne Bainbridge, "Ironies of Automation," Automatica 19, no. 6 (1983). The automation paradox: the human stays in the loop.
Software evolution and maintenance
- M. M. Lehman, "Programs, Life Cycles, and Laws of Software Evolution," Proceedings of the IEEE 68, no. 9 (1980). Continuing change; complexity grows unless work is done to reduce it.
- M. M. Lehman and L. A. Belady, Program Evolution: Processes of Software Change (Academic Press, 1985).
- B. P. Lientz and E. B. Swanson, Software Maintenance Management (Addison-Wesley, 1980). Original survey source for maintenance dominating the lifecycle.
- David Wood, "The 60/60 Rule," in 97 Things Every Project Manager Should Know (O'Reilly, 2009). ~60% of lifecycle cost is maintenance; of that, ~60% enhancement, 23% migration, 17% bug fixes; ~30% of maintenance time spent understanding the existing product.
Figures commonly attributed to IBM (maintenance at 50–75% of lifecycle cost) and to Gartner IT-budget surveys (often 55–80%) are cited in the text as secondary, poorly sourced in retellings. They are directional corroboration only.
AI, productivity, and delivery
- Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer, "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," Microsoft Research (2023). Greenfield HTTP-server task; treatment group 55.8% faster. Dated snapshot of the low-cognitive-load end.
- Joel Becker, Nate Rush, Beth Barnes, and David Rein, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR / arXiv:2507.09089 (July 2025). RCT on mature repositories; early-2025 tools; 19% slower while developers believed they were faster. Used for mechanism (implicit context, familiarity, review tax, perception gap), not as a 2026 coefficient.
- Joel Becker, Nate Rush, Tom Cunningham, David Rein, and Khalid Mahamud, "We are Changing our Developer Productivity Experiment Design," METR (24 February 2026). Follow-up: authors no longer take the 2025 slowdown as a description of current tools; they also judge the new estimate too selected to quote as a speedup.
- DORA / Google Cloud, Accelerate State of DevOps Report (2024). Cited via the 2025 report's revisit: more AI adoption associated with lower software-delivery throughput and higher instability (~1.5% and ~7.2% per 25% adoption increase, that year).
- DORA / Google Cloud, State of AI-assisted Software Development (2025), v.2025.2. Survey fielded 13 June–21 July 2025, nearly 5,000 respondents. Headline: AI is an amplifier. AI capabilities model; throughput relationship flipped positive, instability still up; self-reported productivity, trust, task-level usage; friction and burnout not falling; Adidas loosely-coupled vs ERP case in the Gene Kim foreword.
We did not use DORA's later ROI of AI-assisted Software Development finance model (illustrative 39% ROI / eight-month payback). That is a scenario, not a measurement, and it does not speak to the shape claimed in section 3.3.
Crunchloop, 2026.