Generation is cheap, verification is expensive

Over the past few months, one effect has become increasingly obvious to me when working with coding agents: the code itself is surprisingly often no longer the problem.

An implementation that I might once have planned half a day for can now, under good conditions, appear within minutes. An agent analyzes the relevant slice, changes several files, adds unit tests, runs the build and linting, and then returns a technically plausible patch.

That is still impressive. It just does not mean the work is automatically finished.

I still have to understand what changed. I have to judge whether the functional requirement was actually met. I have to check whether the solution fits the existing architecture model, whether an existing concept was continued, or whether a second one has quietly appeared. For other changes, security, contracts, migrations, runtime behavior, or performance may matter.

This creates a strange asymmetry: what happens when an implementation takes five minutes, while a serious review still requires twenty, thirty, or sixty minutes of attention?

With several agents working in parallel, the effect becomes even clearer.

This is not yet a cost calculation. I will get to that in the next article. Here, I am interested in a different question:

What does verification actually mean when code generation becomes cheap and fast?

As throughput increases, it is not only the way we produce software that changes. The location of the hard part changes too.

Generation scales faster than trust.

A patch is a claim

Article 6 in this series already covered a related problem: plausibility is not a criterion for truth. A model can be convincingly wrong. I do not want to repeat that argument here, but to take it one step further.

When a coding agent produces a patch, the patch implicitly makes a fairly broad claim:

This change satisfies the requirement, fits the existing system, violates no relevant constraints, and introduces no unacceptable side effects.

The patch itself does not yet prove that claim. It is the claim.

Verification has to provide the evidence that makes us willing to accept it.

That sounds more abstract than it is in daily engineering. We already use many evidence channels. The real problem is not to confuse what each of them can actually tell us.

Signal	What it actually answers
Build	Can the checked code be built under the given conditions?
Typecheck	Are the static assumptions captured by the type system consistent?
Lint	Does the change comply with the explicitly encoded rules?
Unit Test	Does a bounded unit behave as expected for the described cases?
Integration Test	Do several participating parts work together in the tested scenarios?
E2E / Acceptance Test	Does a concrete flow work across several system boundaries?
Architecture Rule	Is an explicitly modeled structural boundary respected?
Human Review	Is the solution plausible in the given functional and technical context?
Architecture Review	Do responsibilities, concepts, and dependencies still fit the system model?

None of these checks is worthless. Quite the opposite: good software engineering depends on making as many important properties mechanically verifiable as possible. Their evidential scope is simply limited.

A green build does not prove functional correctness. A unit test does not prove that a business rule lives in the right layer. An E2E test can protect a complete user flow and still fail to notice that a second state concept has been introduced alongside the existing one for the same flow.

A green signal proves only the question we actually asked.

That changes the central verification question. Not: Do we have tests? But:

What evidence do we need for this specific change?

The Verification Surface

For that, I use a term as an engineering model: the Verification Surface.

The Verification Surface of a change describes the set of relevant functional, technical, structural, and operational properties touched by the change and therefore worth verifying.

The crucial point is that this surface is not the same thing as diff size.

A mechanical change may touch 500 lines. Perhaps mappers are being adjusted according to an existing pattern, files are moved, or clearly defined DTO conversions are changed. The patch is large, but the number of meaningful degrees of freedom is small. Compiler checks, tests, and a few targeted validations may cover a large share of the relevant failure classes.

A ten-line change can look completely different.

The diff is tiny. The Verification Surface is large.

The same applies to central state mechanisms, authorization decisions, schema changes, or small adjustments to a public contract.

Code volume and Verification Surface are not the same thing.

As code production becomes cheaper, the number of lines written becomes even less meaningful. The more useful question is how many dimensions exist in which a change can be wrong.

This perspective also prevents another bad habit: review depth should not automatically grow with diff size. A small text fix does not need an architecture review. A small change to an authorization rule might.

Locally correct, systemically wrong

A recent experience made this distinction particularly tangible for me.

The system already had a regular Signal Store in +state. Its role was deliberately defined. The relevant business state lived there, reactive derivations were created there, and data flows and state transitions followed an established model.

Later, an agent created a second, hand-built store in the application layer.

Two stores would not automatically be an architecture defect for me. A source store and a separate ViewModel store can have perfectly legitimate responsibilities. If both serve different purposes and the separation is intentional, that may be the better architecture.

That was not what happened here.

The second store had no independent functional responsibility. It took already existing derivations, transformed them again, and started duplicating state responsibility. At the same time, the implementation mixed reactive primitives such as computed and effect with a noticeably more imperative style.

That introduced two different forms of drift.

The first was Responsibility Drift: responsibility moved or was duplicated without a new functional concept justifying it.

The second was Paradigm Drift: a second programming and state model started to emerge within the same problem space.

Locally, the code was not absurd. It could work. Tests could be green.

And that was exactly what made the change interesting. The agent had worked very cleanly across roughly ten tasks before that. My attention had fallen accordingly. I looked less deeply once — and suddenly the system had a second state concept.

A change can be locally correct and still be systemically wrong.

Architecture drift is often not one obviously bad decision. It emerges from a sequence of locally plausible decisions that slowly pull the system in another direction.

A reliable history changes attention

There is a second mechanism in that example that matters to me.

If an agent works reliably ten times in a row, I learn from that. That is sensible. Trust is built through experience. We work similarly with people: someone who has delivered good work for years is reviewed differently from someone whose changes regularly contain fundamental problems.

But trust has a side effect. A successful history can change the depth of my attention.

That does not mean people become lazy or careless. It simply means that we allocate limited attention and use probabilities while doing so. A system that has behaved reliably for a long time appears less in need of scrutiny.

With automated generation, that can become a special problem because production rate rises at the same time.

A reliable history is not proof for the next patch.

A good track record is evidence about the expected reliability of a workflow. It does not replace verification of a specific change.

This is where a form of debt begins that will matter later: Verification Debt.

Architecture review is responsibility verification

My architecture tries to keep layers deliberately boring. That is especially true for application.

Under normal circumstances, I do not want to find surprising business logic there. The layer aggregates the relevant store properties or use cases and exposes a clear contract toward Presentation. If a business rule already belongs to the state responsibility, I do not want it to emerge a second time in application.

The same principle applies in other directions. Business rules do not belong in Presentation merely because the relevant event arrives there. UI responsibility does not move into the store because a signal happens to be conveniently available there. Infrastructure mapping does not belong in State. And a new state abstraction needs a recognizable responsibility — not merely the fact that it can technically be built.

Architecture review therefore answers a different question from a behavioral test.

A test can verify behavior. Architecture review verifies whether responsibility still lives in the right place.

That is why I would not reduce architecture review to pattern matching.

Patterns help. Layering rules help. Import constraints are excellent candidates for automation. They can, for example, prevent presentation from accessing infrastructure directly.

The harder question is sometimes: why does this new abstraction exist at all? Does this concept have an independent responsibility — or are we modeling the same responsibility for the second time?

A reviewer needs a model of the system to answer questions like these.

Today, this kind of systemic understanding is one of the places where experienced developers remain particularly valuable to me. I would not turn that into a permanent boundary between humans and machines, though. Review models are improving, context retrieval is improving, and architecture knowledge can increasingly be made explicit and accessible.

The more careful statement is:

Systemic review today often requires more and more stable context than local diff review.

Rules help — they just do not know every future deviation

The store example is also interesting because the environment was anything but ungoverned.

I now work with layering rules, agent files, skills, dedicated review instructions, and mechanical checks. The previous article in this series covered exactly that development: build, lint, tests, and E2E increasingly become part of an agent infrastructure in which a coding agent can execute and validate its own change.

And yet the second store abstraction still appeared.

That does not contradict the previous article. It shows what explicit rules are especially good at: known classes of drift.

An illegal import can be blocked by an architecture rule. A wrong dependency can fail a constraint. Missing tests can be detected in CI. Naming violations belong in linting. Wrong layer access can be mechanically restricted.

The harder cases are divergences for which no rule exists yet: a second competing concept, a new implicit responsibility, an unnecessary abstraction, a paradigm mix, or a technically working solution that reinvents a mechanism already present three libraries away.

The architecture rule would have to know about that problem in advance in order to prohibit it precisely.

Explicit rules reduce known classes of drift. They cannot anticipate every new, locally plausible divergence.

That is why I still consider the direction of “more executable architecture rules” correct without concluding that architecture review thereby becomes trivial. Rule review is increasingly automatable. System review is still harder at the moment.

The reviewer should not be persuaded

Another point has changed the way I work with review agents: I try to avoid having the reviewer start from the implementation agent’s justification.

The reason is surprisingly human: rhetoric anchors.

An eloquent developer can explain a technically questionable decision very convincingly. I have experienced that myself. Years ago, I discussed microservices with a highly educated and rhetorically strong colleague. After a long conversation, I was almost convinced that the concept fundamentally could not work.

Later, at some point on my bike, I thought:

Wait a second. That was nonsense.

Not because the colleague knew nothing. Quite the opposite. His expertise was precisely what made the argument persuasive.

That experience stayed with me. A good explanation can shape my assessment before I have independently examined the thing itself.

The same applies to AI-generated code. After implementing something, a coding agent can provide a beautiful explanation of why the chosen solution is elegant, follows existing patterns, and satisfies all requirements.

That is useful information. It is not evidence that the statement is true.

A plausible justification is not evidence.

That is why I prefer a different task for review agents. Not: explain whether the coding agent’s solution makes sense. More like:

Requirement
+
Constraints
+
relevant system context
+
Diff
↓
independent verification

The implementation rationale can still be useful later. I simply do not want it to determine the verifier’s primary perspective.

A verifier should check the solution against requirements and constraints, not against the generator’s explanation.

Independent Evidence needs different perspectives

That brings in another concept: Independent Evidence.

It is tempting to equate independence with the number of models involved. Agent A implements, Agent B reviews — therefore we have two perspectives.

That does not automatically follow.

I have seen a real workflow in which one junior implemented with agent support and a second junior reviewed with agent support. The result looked good. The review agent found nothing substantial.

Then an experienced reviewer asked one critical question. The solution began to fall apart. A deliberately stronger review agent subsequently found several serious issues.

That does not mean juniors should not use AI, or that a second model is useless. The interesting observation lies elsewhere:

A review is not independent merely because a second model is involved.

Two models can inherit the same assumptions. They can fail to find the same repository areas, miss the same architecture rule, read the same incomplete requirement context, and accept the same plausible story.

Independence therefore arises more from the verification perspective than from the mere identity of the model.

The generator asks: how can I implement this requirement?

The verifier should be asking something closer to: which relevant requirement, constraint, or system assumption could this patch violate?

That does not guarantee independence. But at least the tasks are not identical.

Contradiction is a capability

I now explicitly expect strong models to contradict me.

I do not need a reviewer to explain why my idea is actually pretty good. If I am wrong, I want to know as early as possible.

This has happened to me repeatedly in longer technical discussions with frontier models. I start with a fairly clear opinion, the model disagrees on one point, we work through the underlying assumptions — and in the end I change my original position.

I do not consider that a failure of the workflow.

That is the workflow.

I do not need a reviewer who confirms that my solution is plausible. I need a reviewer who contradicts me when there is a solid reason to do so.

That does not mean turning every review into maximum red teaming.

I have tried that too. If an agent is instructed to find risks at all costs, it will find risks. Eventually, theoretical edge cases are pursued with the same energy as real architecture violations. The next fix introduces more guards, fallbacks, and abstractions, which in turn create new attack surfaces for the next review.

That can make software more robust. It can also make it overly defensive and difficult to read.

The better property, for me, is therefore not maximum aggression but calibration: contradict when there is a solid reason. Accept a solution when the available evidence is sufficient.

Verification Diversity

Independent Evidence leads to a related principle: different verification channels should not merely repeat the same question.

I call that Verification Diversity.

An implementation-near unit test has a different error sensitivity from an E2E test. An architecture rule sees different problems from a domain reviewer. A static typecheck finds different defects from a security review. A review LLM may detect a smell that no test describes. A domain owner may notice that a technically perfect implementation simply implements the wrong requirement.

The goal is not to throw as many verification instances as possible at every patch.

More verification is not automatically better verification. What matters is whether different channels expose different relevant failure classes.

This also means that the Verification Surface should determine review depth. A change to static text has a small surface. A feature touching Presentation, Application, State, Infrastructure, and API has a larger one. Then I care about layering boundaries, slicing, autonomy, established patterns, unnecessary new dependencies, and whether existing tools were reused or self-made solutions were introduced.

Diff size is, at most, one signal among several.

The Verification Surface is determined more by the boundaries a change touches than by the number of lines changed.

Different test levels need different independence

The desire for Independent Evidence should not turn into a new dogma.

For example, I do not see much value in the blanket rule that an implementation agent must not write its own unit tests. Unit tests often exist precisely to secure a concrete implementation. In that context, proximity is not necessarily a problem.

An agent implementing a domain function can very well add the directly related unit tests, cover edge cases, and secure local invariants. Those tests become part of the patch and increase the evidence for that implementation.

For acceptance and E2E tests, however, I tend to want more independence.

There, I care less about whether a single method works and more about whether the expected flow works across the relevant layers. I would rather use a specialized agent with requirements and system access that verifies the complete flow from another perspective.

Even here, we should not overstate what such tests prove. An E2E test only verifies the expected behavior we described to it. And real requirements are rarely complete.

Tests can only verify against expectations that are explicit enough. Missing requirements do not become complete simply because we add more testing.

That is an important limit of verification in general. Evidence can only test a claim against expectations that are known or can be derived. If nobody knows how a special case should behave from a domain perspective, a test cannot invent that decision from nothing.

A good verifier knows the limits of its authority

That is why verification, for me, also includes the question of who is actually authorized to make a decision.

If a functional requirement is unclear, the domain side decides. An architect or developer can explain options, expose technical consequences, and point out inconsistencies. That does not automatically grant the authority to invent a new business rule.

Conversely, an architecture decision does not automatically belong to the domain side merely because the change originated in a functional ticket.

In my own work, the boundary is relatively clear: the domain side holds functional authority; engineering and architecture hold technical authority.

With stronger models, I increasingly see a behavior that I explicitly want: the model notices an ambiguity and says, in effect, that the question needs to be clarified with the domain owners.

That is a good answer.

Article 10 already described this stance under the idea of stop instead of guessing. For verification, it means:

A good verifier does not need an answer to every question. It needs to recognize when it lacks the authority to answer.

Intentional exception or unnoticed drift?

Architecture rules themselves are not laws of nature either.

There can be situations in which a deviation makes sense. Perhaps a legacy contract prevents the clean target architecture. Perhaps a technical limitation makes an established pattern impractical. Perhaps a complete solution is possible, but economically unjustifiable for the specific product context.

What I do not accept as a sufficient justification is: there is simply no other way.

If a rule is going to be broken, the rule itself becomes the subject of analysis again. Why does it not work here? Which alternatives exist? Is there already an established solution? Can the deviation be contained locally? What does it mean in the long term?

Sometimes the answer after that is indeed: we make the exception.

Then I want it to be a conscious decision. And if economic reality forces a worse technical solution, that is Tech Debt. The important part is knowing that we have taken it on.

An intentional exception is a decision. An unnoticed exception is architecture drift.

This is not an argument for bureaucratic ADRs for every small change. It is an argument for preventing meaningful deviations from disappearing unnoticed as ordinary implementation details.

Verification Debt

That lets me define the earlier idea more precisely.

By Verification Debt, I do not simply mean missing tests.

Verification Debt emerges when changes are generated faster than reliable evidence for their functional and systemic correctness can be built.

That can happen with several agents working in parallel. It can happen because implementation time drops dramatically while review time does not fall proportionally. It can happen because a team has excellent automation for build, lint, and unit tests, but only superficial scrutiny of systemic changes. Or because a review agent checks the local diff while the relevant competing abstraction sits outside its context.

One limitation matters here: agentic work does not automatically create Verification Debt.

If verification grows proportionally, no debt has to emerge. That is exactly the engineering task.

We should not scale generation alone. We have to scale our ability to inspect, interpret, and reliably accept its results.

Generation is easier to parallelize

At the moment, I keep running into a very practical limit.

I can start several coding agents at once. One implements a feature, another performs a refactoring, a third adds tests, a fourth works on documentation.

Mathematically, that throughput can be extended almost indefinitely. My own attention cannot be parallelized in the same way.

If two changes involve different functional and architectural contexts, I cannot seriously reason about both at the same time. I can switch between them. I can delegate reviews. I can automate mechanical checks.

But systemic judgment is currently a limited resource.

That is why my personal bottleneck is surprisingly often no longer writing the code.

Serious review is currently the bottleneck.

The word currently matters.

Review models are improving. Repository retrieval is improving. Architecture rules are becoming more explicit. Models are getting larger and more stable workspaces. Perhaps a substantial share of what I review myself today will be reliably automatable within a few years.

The broader thesis therefore does not depend on a permanent human-versus-AI boundary:

The bottleneck moves to wherever trust cannot yet be automated sufficiently.

And that creates a limit for parallelization:

Generation must not scale faster than the system’s ability to verify its outputs reliably.

Is software development actually shifting toward verification work?

This personal observation now aligns strikingly well with part of the current research. At the same time, the evidence is not yet strong enough to turn it into a universal claim about every software team.

A particularly interesting 2026 longitudinal study by Annie Vella and Kelly Blincoe surveyed professional software engineers twice, six months apart. 158 people participated in the first wave, 101 in the second, with paired longitudinal data available for 95. Eighty-two percent reported spending less time actually writing code. The authors describe a broader shift from creation to verification and propose the category supervisory engineering work for steering, evaluating, and correcting AI output. At the same time, perceived productivity improvement remained high, while among paired participants the share reporting a worse developer experience in at least one dimension rose from 14 to 27 percent. As of September 2026, the work is available as a preprint or submitted manuscript and should therefore be treated cautiously.

Broader in scope is the systematic literature review by Agnia Sergeyuk, Ilya Zakharov, Ekaterina Koshchenko, and Maliheh Izadi. It synthesizes 90 empirical studies on human-AI experience in development environments. The authors report both productivity gains and verification overhead and over-reliance; on the quality side, recurring risks concern correctness, maintainability, and security. The work has appeared in Empirical Software Engineering and at the same time shows how heterogeneous the field remains and how much longer, more realistic evaluations are still needed.

Another systematic review and mapping study by Mohamed, Assi, and Guizani reaches a similarly cautious conclusion across 39 peer-reviewed studies: most report productivity benefits, especially for routine tasks and code search. For code quality, however, there is no uniform effect; findings depend heavily on task, measurement method, and context.

So the research does support a shift in activities. It does not support the simple equation that more verification work automatically means less productivity.

More output can shift work elsewhere

A 2025 study by Feiyang Xu and colleagues examines open-source projects after the introduction of GitHub Copilot. The authors report higher productivity especially among less experienced or peripheral contributors, but also more rework. In the analysis, experienced core developers reviewed 6.5 percent more code, while their own code productivity fell by 19 percent. The work should be treated as a conference contribution or preprint. It is an interesting signal that local productivity gains can shift work within a system, but it is not a universal effect size for AI-assisted software development.

Qualitative data shows the same possible friction from another angle. For a 2026 preprint, Sebastian Baltes, Marc Cheong, and Christoph Treude analyzed 1,154 Reddit and Hacker News posts discussing so-called AI Slop. One major thematic cluster in their coding is review friction: developers discuss additional reviewer burden, loss of trust, and countermeasures. This source captures perceptions and discourse in selected online communities, not measured productivity effects in representative development teams.

Another 2026 preprint by Fawzy, Tahir, and Blincoe compares verification practices among non-developers, novices, and professional developers in a survey of 162 participants. The authors describe a perception-action gap: awareness of potential problems in AI-generated code is relatively widespread, while the ability to actually assess, debug, and verify that code varies more strongly with experience and hands-on programming practice. This is not evidence that only experienced developers can verify AI-generated code. It does support the more careful claim that risk awareness and verification capability are different skills.

The counterevidence matters just as much

If we selected only those studies, we could easily tell a predetermined story: AI generates more code, experienced developers have to repair everything, and everyone loses in the end.

The research is not that simple.

Randomized field experiments at Microsoft, Accenture, and another Fortune 100 company included a total of 4,867 developers. In the pooled analysis, Cui and colleagues reported around 26 percent more completed tasks among developers with access to a generative coding assistant; less experienced developers also showed higher adoption and stronger productivity gains. The work was published in Management Science in 2026 and clearly demonstrates that AI assistance in real enterprise environments can also produce a positive overall effect on measured throughput.

The well-known METR experiment from 2025 pointed in the other direction. Sixteen experienced open-source developers worked on 246 real tasks in repositories they had known for years. With the AI tools available at the time, they took 19 percent longer on average. Particularly interesting was the perception gap: the developers themselves believed they had been faster. Part of the extra time went into prompting and reviewing generated output.

But that number should not be frozen in time either.

In February 2026, METR published new data on later model generations. Those results pointed more toward possible speedups, but selection effects and difficulties measuring time when agents work in parallel made them too fragile for a precise new effect size. The researchers changed their study design accordingly.

That, to me, is the more interesting scientific finding. Task type, experience, codebase, model generation, tooling, quality bar, available verification infrastructure, and workflow all change the outcome.

The most plausible summary at the moment is more restrained:

There is growing evidence that some developer work is shifting from creation toward steering, review, and verification. Whether that produces a net productivity gain or additional burden is highly context-dependent.

Why system understanding still matters today

That brings me back to the second store.

An experienced developer would probably not have spotted that implementation more quickly because they can read ten lines of code faster. The advantage lies elsewhere.

They often carry a model of the system.

They know that a store already exists. They know its responsibility. They recognize that the new abstraction does not model anything functionally independent. They may also see that three other local changes look plausible on their own but, together, establish a new architecture paradigm.

That kind of knowledge changes the value of experience.

Today, the value of a developer who understands the system increasingly lies less in writing the patch faster and more in recognizing what the sum of many patches is doing to the system.

Again, the word today matters.

There is no technical principle that says an AI system could never maintain a sufficiently good system model. Review agents are already surprisingly strong when given good context. They find wrong layer access, broken contracts, missing tests, suspicious error-handling paths, and inconsistent implementations.

The difficulty rises when the relevant question becomes: this abstraction works — but does this concept already exist in another slice, and are we thereby creating two competing state models over time?

To answer that, the agent first has to find the relevant comparison mechanism, understand the semantic relationship, and then judge whether the similarity represents intentional separation or unnecessary duplication.

That is a much larger Verification Surface than a local diff review.

Review automation scales only with reachable evidence

I still would not conclude from this that AI review is merely superficial.

Quite the opposite. I now enjoy working with specialized review agents and deliberately run them against requirements, architecture rules, and diffs. Especially for explicit constraints, they can take over enormous amounts of mechanical review work.

The important point is different:

Review automation scales only as far as the relevant evidence and context are reachable by the reviewer.

This connects this article back to the previous one about AI-friendly software.

There, one question was: can the agent execute build, lint, tests, and E2E itself?

Here, the question is: what do those green results actually prove — and which quality dimensions remain open afterward?

An executable workspace is therefore an important foundation for strong verification. It does not yet define what level of verification is sufficient for a specific change. That depends on the Verification Surface.

“Expensive” initially means attention

The title of this article is:

Generation is cheap, verification is expensive.

By expensive, I do not yet primarily mean euros, dollars, or tokens.

Verification requires attention. It requires judgment. It requires the relevant context. Sometimes it requires independent model runs, sometimes real runtime environments, sometimes security expertise, and sometimes a domain decision that no agent should make alone.

Generation can produce four plausible solutions within minutes. The question of which one is acceptable does not disappear.

Perhaps that decision too will become increasingly automated in the future. That would be a logical continuation of the trend. But as long as generation scales faster than the ability to verify reliably, the bottleneck simply moves.

The practical consequence is fairly clear to me: coding agents should only be parallelized as far as the verification system can handle the resulting throughput. At the same time, it is worth investing at least as deliberately in review agents, acceptance tests, architecture rules, and other verification infrastructure as in the coding agents themselves. And for changes with a large systemic Verification Surface, I still deliberately involve people today who genuinely understand the affected system.

Whether the last point remains permanently human is open. The principle behind it is broader.

The cheaper generation becomes, the more important the question of what evidence we require before accepting a change.

So we should not only measure how much code an agent can produce. We should understand how a generated patch becomes a verified acceptable change.

Because that immediately leads to the next question.

If verification requires attention, model runs, tests, E2E, real infrastructure, and human judgment — what does a change that we can trust sufficiently actually cost?

That is the economic perspective.

And it belongs in the next article.

Code gets cheaper. Trust does not automatically. The bottleneck moves to wherever trust cannot yet be automated sufficiently.

Sources and classification

Annie Vella, Kelly Blincoe — “The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study”, 2026.
Longitudinal mixed-methods study of professional software developers with two measurement points six months apart. Relevant to the described shift from creation to verification and the term supervisory engineering work. As of September 2026, it should be classified as a preprint or submitted manuscript.

Agnia Sergeyuk, Ilya Zakharov, Ekaterina Koshchenko, Maliheh Izadi — “Human-AI experience in integrated development environments: a systematic literature review”.
Systematic literature review of 90 studies, published in Empirical Software Engineering. Relevant to productivity gains, verification overhead, over-reliance, and risks to correctness, maintainability, and security. The review also shows a heterogeneous research landscape and calls for longer and broader evaluations.

Amr Mohamed, Maram Assi, Mariam Guizani — “The Impact of LLM-Assistants on Software Developer Productivity: A Systematic Review and Mapping Study”.
Synthesis of 39 peer-reviewed studies. Most report productivity gains, while findings on code quality remain inconsistent and strongly context-dependent.

Feiyang Xu, Poonacha K. Medappa, Murat M. Tunç, Martijn Vroegindeweij, Jan C. Fransoo — “AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden” / “GenAI as a coding partner”.
Analysis of open-source development after Copilot adoption; reports, among other things, more review and rework among core developers. Best classified as a conference contribution or preprint. The results are evidence of possible work redistribution, not a universal effect size.

Sebastian Baltes, Marc Cheong, Christoph Treude — “An Endless Stream of AI Slop: How Developers Discuss the Burden of AI-Assisted Software Development”, 2026.
Qualitative analysis of 1,154 Reddit and Hacker News posts. Relevant to perceived review friction, loss of trust, and maintenance burden. The data reflects developer discourse and should not be interpreted as a representative productivity measurement.

Ahmed Fawzy, Amjed Tahir, Kelly Blincoe — “From Prompting to Verification: How Experience Shapes Vibe Coding Practices”, 2026.
Survey preprint with 162 participants across different experience levels. Relevant to the described perception-action gap: risk awareness and the actual ability to verify AI-generated software are not the same thing.

Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz — “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”. Management Science, published online February 27, 2026. Publication and DOI.
Randomized field experiments at Microsoft, Accenture, and a Fortune 100 company with a total of 4,867 developers. The pooled analysis reports a substantial productivity gain and serves here as important counterevidence against a blanket burden thesis.

Joel Becker, Nate Rush, Elizabeth Barnes, David Rein / METR — “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”.
Randomized experiment with 16 experienced open-source developers and 246 real tasks in familiar repositories. The early-2025 tools slowed the studied developers by 19 percent on average. METR itself warns against generalization; later 2026 data points toward changing effects but is not robust enough for a new precise effect size.

The terms Verification Surface, Verification Debt, and Verification Diversity are used in this article as engineering models. The cited studies do not establish this specific terminology. They provide empirical points of connection for verification overhead, changing task distributions, review burden, and context-dependent productivity.