Source Document

Happy Bhati, "Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle", arXiv:2609.04681 [cs.SE], submitted 2026-09-04. Affiliation: Northeastern University ([email protected]). Single-author preprint; no code or dataset release (not applicable — this is a literature synthesis).

This is a preprint without peer review. The author states plainly that it is "a structured systems synthesis, not a PRISMA-style exhaustive systematic review." No new experiments or measurements are reported; instead, roughly 30 sources published between 2024 and September 2026 — peer-reviewed papers, university studies, benchmark audits, corporate production reports, and market forecasts — are synthesized into four proposed concepts (the Throughput Paradox, Production-Qualified Change, the Verification Tax, and the Autonomy Budget). The paper grades its own evidence on a six-tier scale from A (peer-reviewed) to F (this paper's own synthesis) in a table, a level of transparency this series specifically looks for.

Study Overview

Two questions drive the paper. First, does the rise in coding-agent output actually translate into more shippable software? Second, if not, what unit should organizations use to measure and manage that gap? Rather than collecting new data, the paper cites randomized field experiments, observational telemetry, benchmark audits, corporate self-reports, and industry surveys, attributing every number to its original source. The method choice is explicit: a single benchmark score cannot describe the full delivery path from review through testing, security, deployment, and operations, so sources were selected against six separate questions — capability, productivity, review/testing, reliability/security, coordination, and cost.

Key Results

Start with productivity signals. Even when studies all report a "productivity gain," different designs make the numbers non-comparable side by side.

StudySample / designMeasured result
Cui et al. (Management Science), 3 pooled RCTs4,867 developers, randomizedCompleted tasks +26.08% (pooled estimate)
Demirer, Musolff & Yang (NBER w35275)100,000+ GitHub developers with usage telemetry, observational event studyAt the autonomous-agent stage: commits +180%, projects +50%, releases +30%
METR (2025 RCT)16 experienced open-source developers, 246 tasks in familiar reposCompletion time +19% (opposite of developers' own expectation)
Google Cloud DORA 2025~5,000 technology professionals surveyedHigher AI adoption → higher throughput, but a negative relationship with delivery stability

The 180%→50%→30% attenuation across commit, project, and release levels is the paper's core evidence for what it calls the "Throughput Paradox." The other three studies differ in causal strength (RCT vs. observational) and population (new tasks vs. experienced developers in familiar repositories), and the author explicitly warns against lining them up as if they measured the same thing.

Verification and coordination costs show an equally clear pattern.

StudySampleMeasured result
SWE-chat (Stanford)6,000 real coding-agent sessionsOnly 44% of agent-produced code survived into commits; 41% of sessions were nearly all agent-authored vs. 23% all human-authored
SWE-MarathonUltra-long-horizon rolloutsAverage 27.2M tokens per rollout; every configuration stayed under 30% pass@1; reward-hacking observed in 13.8% of rollouts
CooperBench (Stanford & SAP Labs)600+ collaborative coding tasksAbout 30 points lower success rate when cooperating vs. working alone
Meta TestGen-LLM (Instagram deployment)Generated-test filtering pipeline75% built correctly, 57% passed reliably, 25% raised coverage, 73% of recommendations accepted for production

The FinOps Foundation is also cited: the share of respondents actively managing AI spend rose from 31% to 98% in two years. Gartner's forecast that AI coding cost could exceed the average developer's salary by 2028 is explicitly flagged by the author as "a planning signal, not a measured outcome."

Credibility Assessment

Three things earn trust. First, the author grades each of the 30 cited sources on an A-through-F evidence scale in a table, letting readers judge reliability for themselves. Second, conflicting results (the RCTs' +26.08% vs. METR's -19%) are not hidden — Section 19 explicitly warns against comparing results from different populations and different causal strength. Third, the acknowledgments repeatedly state that no new experimental claim is made and every number remains attributed to its original authors.

The caveats are just as clear. The author is a sole contributor with no stated funding source, and cites two of his own earlier preprints (on the A-SDLC architecture and AI observability) to maintain conceptual continuity — a modest share of the 30 references, but not full third-party verification. Many cited sources are corporate self-reports (Google DORA, GitHub's security-validation dashboard, Meta's TestGen-LLM), a boundary the author himself names explicitly. And roughly half the cited sources are 2026 preprints, meaning independent replication or rebuttal has not yet accumulated.

Reviewer's Judgement

First, among the four proposed concepts, the Verification Tax is the most immediately applicable in practice, in this reviewer's judgement — its definition, (CI + review + security + rework cost) / generation cost, only requires re-tallying cost categories organizations already track. The Agentic SDLC Control Plane, by contrast, demands a new organization-wide policy and telemetry layer, a much higher adoption bar.

Second, reading the 180%→30% figure as a single story of "the bottleneck moving downstream" is an overgeneralization, in this reviewer's judgement. METR's result shows that experienced developers working in repositories they already know well can see the upstream stage itself slow down — where the bottleneck sits appears to depend on organizational maturity and task type, not a universal direction.

Third, Meta TestGen-LLM's 73% acceptance rate is, among the numbers this paper cites, the most operationally usable reference point for designing a verification pipeline, in this reviewer's judgement — it is one of the few industrial cases where "generate, then filter against objective criteria" demonstrably worked in production.

Putting It to Work

  • Instrument the Verification Tax — track (CI + review + security + rework cost) / generation cost over time, and diagnose spikes as rising task risk vs. degrading model/harness quality.
  • Redefine output as PQC — count a change as output only after it clears the gates required for its risk class, not at commit or PR count.
  • Set hard stop rules for long-horizon runs — as SWE-Marathon shows, don't operate long-running agents without token/time ceilings and progress checkpoints.
  • Allocate autonomy by risk class — apply different gates to low-risk work (docs, refactors) than to high-risk work (auth, payments, data migration).
  • Pair generated tests with a filter — as at Meta, accept only tests that pass objective checks (build success, stability, coverage gain) into production.

Conclusion

This preprint's contribution is not a new benchmark score but a diagnostic frame that ties together 30 scattered studies. It names the fact that commits rise faster than releases the "Throughput Paradox" and proposes the Verification Tax and PQC as units for managing that gap. Because it is a single-author synthesis and many of its cited numbers come from 2026 preprints not yet independently replicated, the proposed framework is best read as a hypothesis for future studies to test, not an established standard.

A blog post already covers the same NBER figure (180% commits vs. 30% releases) from a QA-gate design angle — see the reference link below for the operational follow-through.

References