Coding Speed Is Only an Advantage If You Are Heading Somewhere Worth Going
The Biggest Risk from Coding Agents Is Measuring Code Output as Delivery
Coding agents are increasing the amount of software organizations can produce. Pull requests appear faster, implementation work accelerates, and developers can move from an idea to working code in minutes.
That does not automatically mean the organization is delivering more value.
Software delivery has two distinct stages: producing code and getting the right change into production safely, reliably, and sustainably. Coding agents are becoming extremely effective at the first stage. Whether they improve the second depends on the engineering system around them: requirements, architecture, testing, code review, security, release controls, observability, and production ownership.
The central risk is therefore not engineer replacement. It is executive mismeasurement.
If leaders count more pull requests, completed tickets, and AI adoption as proof of productivity without also measuring defects, rework, review effort, change failure, maintainability, and customer outcomes, they are measuring activity rather than delivery.
More Pull Requests Are Evidence of Output, Not Proof of Value
A July 2026 Microsoft study examined the early rollout of Claude Code and GitHub Copilot CLI across tens of thousands of engineers. Researchers estimated that adopters merged approximately 24% more pull requests than they otherwise would have during the four-month study period.
That is meaningful evidence that command-line coding agents can increase engineering output. The researchers also stated the limitation clearly: a merged pull request is not the same as the value it delivers.
That distinction matters because pull requests are not interchangeable units of productivity. One may contain a valuable feature. Another may contain duplicated logic, unnecessary abstraction, a correction to earlier generated work, or a change whose operational cost will not appear until later.
The study shows that a visible production metric can improve. It does not establish that reliability, maintainability, customer value, or total delivery cost improved by the same amount.
Whenever leadership sees a rise in pull-request volume, the next questions should be: Did review time rise? Did change failure rate change? Did rework or incident volume increase? Did customers receive more value? Can the team still understand and support the resulting code?
Without those answers, the organization has measured increased output, not improved delivery.
DORA Shows Why Throughput and Stability Must Be Read Together
Google’s 2024 DORA research found an uncomfortable trade-off. A 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, even while AI was associated with gains in individual productivity, flow, documentation, and job satisfaction.
The 2025 DORA report showed a more favorable relationship with throughput and product performance, but AI adoption still had a negative relationship with software-delivery stability. Google’s broader conclusion was that AI acts as an amplifier: strong technical systems can convert faster implementation into better outcomes, while weak systems can experience more instability as change volume rises.
That is the core measurement problem.
An organization can deploy more frequently and still experience more failed changes. It can complete more development work while increasing the burden on quality, security, platform, and operations teams. It can make developers feel faster while making the overall delivery system less predictable.
Throughput and stability are not competing narratives. They are two parts of the same performance assessment.
Any executive report that shows AI-assisted output without change failure rate, escaped defects, or restore time is incomplete.
Developers Can Feel Faster Even When the Work Takes Longer
METR conducted a randomized controlled trial involving experienced open-source developers working in repositories they already knew. Before the study, participants predicted that AI would make them approximately 24% faster. After completing the work, they believed AI had made them about 20% faster.
The measured result was the opposite: developers using the early-2025 AI tools took approximately 19% longer.
That result should not be generalized into a claim that current AI tools always slow developers down. METR’s later work found signs that newer tools may be improving outcomes, although the updated estimates remained uncertain.
The durable lesson is that perceived speed and measured speed can diverge sharply.
AI removes blank-page friction. It produces immediate output. It creates momentum. Those experiences feel productive, even when time is later absorbed by prompting, correction, review, debugging, or integration.
That perception can compound through the organization. A developer reports feeling faster. A manager reports higher team productivity. Leadership cites adoption as evidence of delivery improvement. Nobody needs to be dishonest for the conclusion to be wrong.
AI programs therefore need objective measures of lead time, quality, rework, stability, and business impact. Adoption rates and developer sentiment are useful signals, but they are not delivery metrics.
Production Access Turns an AI Tool into a Governance Risk
Amazon’s experience with Kiro illustrates why adoption and operational control must be evaluated together.
Reuters reported on a Financial Times account of a 13-hour interruption involving an AWS cost-management service in one mainland China region. According to people familiar with the incident, engineers allowed Kiro to make changes, and the agent decided to delete and recreate an environment.
Amazon disputed the characterization that AI caused the outage. The company attributed the event to user error and misconfigured access controls, emphasized that the disruption was limited, and said Kiro normally requires authorization before acting. Amazon subsequently added safeguards, including mandatory peer review for production access.
The disagreement over the immediate cause does not eliminate the governance lesson. It clarifies it.
An agent’s risk cannot be separated from its permissions, approval controls, rollback mechanisms, and production environment. Whether the initiating failure is described as AI behavior, operator error, excessive access, or inadequate review, the delivery system must prevent a fast automated action from becoming an uncontrolled production event.
The relevant questions are operational: What can the agent change? Which actions require independent approval? Are destructive actions blocked by default? Is least privilege enforced? Can a change be reversed quickly? Who owns the final decision?
An AI-adoption target answers whether people are using the tool. It does not answer whether the organization is using it safely.
AI Reviewing AI Can Create the Appearance of Independent Assurance
A coding agent can now interpret a requirement, design an implementation, generate code, write tests, review the pull request, explain why the change is safe, and propose fixes for the issues it identifies.
Anthropic offers Claude Code Review, which uses multi-agent analysis to look for logic errors, security vulnerabilities, and regressions. These capabilities can be valuable. Automated review may catch defects that a rushed human reviewer misses.
The risk appears when organizations treat a second AI step as independent verification.
When Claude generates a change and Claude reviews it, the workflow contains two stages, but both may rely on closely related models, instructions, context, and assumptions. Multi-agent prompting can generate disagreement, but it does not guarantee genuinely independent judgment.
IBM Research’s 2026 AAAI paper quantified the gap: an LLM used as a sole code reviewer detects only about 45% of code errors. Combining AI review with deterministic analysis tools raised detection to 94%. The same misunderstood requirement or architectural assumption may shape both the implementation and the review. The model may generate the tests, approve the tests, and explain why those tests are sufficient. A developer can then approve the summary without reconstructing the behavior of the code.
That is not necessarily four layers of assurance. It may be one source of judgment presented four different ways.
Anthropic’s own guidance preserves human responsibility. Its documentation states that users remain responsible for reviewing proposed code and commands before approval.
A safer pattern is straightforward: AI generates the change. Deterministic tools validate what they can. A human reviewer independently assesses design and risk. An accountable owner approves the change. A second model can add another signal, but it should not replace human understanding or reproducible controls.
The Deeper Risk Is Outsourcing Attention
The more precise risk is that AI makes it easier to outsource the attention through which engineering knowledge is built and, critically, the gap that creates is invisible to any dashboard that measures output.
Writing software forces an engineer to confront requirements, dependencies, edge cases, trade-offs, and failure modes. That work creates the mental model later used to review, debug, operate, and extend the system.
When an agent produces a substantial implementation in minutes, the nominal owner may understand what was requested and what the AI claims to have done without understanding how the code actually behaves.
That gap may remain invisible until production fails.
A service does not fail according to the pull-request summary. It fails according to runtime behavior, state transitions, permissions, data conditions, hidden dependencies, and interactions across systems. A team that cannot independently explain or debug its own codebase is accumulating a silent liability that will not appear in a velocity report until it surfaces as an incident or an unplanned platform replacement.
The concern is not that AI use inherently makes developers less capable. Used actively, it can expose engineers to unfamiliar code, generate alternatives, and accelerate learning. Used passively, it can reduce the amount of reasoning performed by the person who remains accountable for the result.
The difference is whether the engineer is using AI to extend judgment or avoid exercising it. Leadership cannot see which is happening by reading throughput metrics. That is precisely what makes it a mismeasurement risk.
Fast Generation Can Create a Maintenance Bill That Arrives Later
The immediate benefit of a coding agent is easy to see. The maintenance cost may appear after the sprint, after the quarter, or after the original developer has moved on.
GitClear analyzed 211 million changed lines across open-source and private repositories from 2020 through 2024. It reported increases in duplicated code and short-term churn alongside a continued decline in moved or refactored code. GitClear is a commercial software-analytics provider, and its research is observational. The findings do not prove that AI caused every trend. They do identify the kinds of maintenance indicators leaders should monitor as AI-assisted output expands.
Duplicated code can pass tests. Churn can coexist with high sprint velocity. Reduced refactoring may not trigger an immediate incident. The cost appears when teams must modify the same logic in several places, trace divergent implementations, or repair code that was merged quickly and rewritten shortly afterward.
Research on AI-generated code is mixed, which is important. Some studies have found more code smells and structural issues, particularly on complex tasks. Others have found fewer defects or lower remediation effort on bounded problems. The defensible conclusion is not that AI-generated code is universally worse. It is that functional correctness does not settle maintainability.
Coding agents can produce large changes rapidly. Those changes may include repeated logic, unnecessary abstractions, excessive branches, over-logging, or inflated test scaffolding. Even when line count is not excessive, an implementation can be structurally difficult for humans to reason about. A system that is fast to generate can still be slow to debug. Output appears in the sprint immediately. Maintenance cost often arrives later, which is precisely why it is easy to exclude from the productivity story.
Agent Activity Is Not Always Useful Work
A May 2026 study from ETH Zurich’s SRI Lab introduced FixedBench, a benchmark of 200 human-verified issues where the reported problem had already been resolved and no code change was needed. Across five frontier models and four agent harnesses, agents still proposed undesirable changes in 35% to 65% of cases. Even the best-performing models did not achieve correct abstention rates above 67%, meaning at least one in three stale issue reports resulted in spurious edits to working code.
The researchers described this as action bias: agents tend to modify software even when doing nothing is the correct result. The bias is not a minor edge case. It reflects something structural about how agents are built and evaluated. Models are trained and rewarded for producing output. Abstaining does not register as a successful outcome in most evaluation frameworks, so agents do not learn to do it reliably.
This matters because many engineering metrics reward visible action. Commits, pull requests, completed tickets, and generated patches all register as activity. But sometimes the best engineering decision is not to change the code. A mature team may determine that the issue is already resolved, the proposed feature introduces more risk than value, or the correct intervention belongs somewhere else in the architecture. An agent that reliably produces a patch may look productive while increasing unnecessary change, unnecessary review load, and unnecessary technical debt. None of that appears as a cost in a velocity metric.
Leaders should therefore measure accepted value and operational outcomes, not generated activity.
Strong Governance Is How Organizations Capture the Speed
The answer is not to prohibit coding agents or force engineers to recreate generated work manually. That would discard real gains.
The answer is to build a delivery system capable of converting faster generation into dependable outcomes. That system requires:
Independent ownership. Every material AI-generated change should have a human owner who can explain its behavior, dependencies, failure modes, and rollback path.
Deterministic validation. Compilation, static analysis, dependency scanning, security controls, performance testing, integration testing, and policy checks should remain authoritative.
Separation of generation and assurance. AI review can augment quality, but the same model generating and approving a change should not be treated as independent validation.
Small, reversible changes. Agents should operate with bounded scope, least privilege, explicit approval for destructive operations, and practical rollback mechanisms.
Complete delivery measurement. AI adoption and output should be reported alongside lead time, change failure rate, escaped defects, restore time, rework, churn, duplication, review effort, security findings, performance regressions, and customer outcomes.
Demonstrable human understanding. Teams should be able to support the implementation without depending on the original prompt history or asking the generating agent to explain its own decisions.
These controls do not prevent organizations from capturing AI’s speed. They prevent that apparent speed from becoming downstream instability.
Measure Delivery, Not Just Code Production
Coding agents are now a permanent part of software engineering. The useful question is no longer whether organizations should adopt them. It is what those organizations will count as success.
More code can be useful. More merged pull requests can be useful. Faster implementation can be transformative. None of those outcomes alone proves that a company is delivering more customer value, operating more reliably, or building software it can maintain.
Every report showing rising pull-request volume should include change failure rate. Every claim of faster feature completion should include escaped defects and rework. Every AI-adoption target should have an operational-risk counterpart. Every estimate of development time saved should account for review, debugging, maintenance, and production support.
The real productivity metric is not how quickly code appears. It is whether the organization can understand, validate, operate, and safely change that code after the prompt window is gone.
When leaders measure code production without delivery stability, they are not measuring software productivity. They are measuring the easiest part of the system and ignoring the part for which technical leadership remains accountable.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn