A study of the agentic SDLC shifts attention from generating code to proving that it deserves production

A paper published on arXiv by Happy Bhati proposes changing the question used to evaluate coding agents. Instead of asking how much code they can produce, it suggests measuring how much production-qualified value the system delivers per dollar, reviewer-hour, and unit of operational risk. The study does not present a new experiment; it synthesizes software-engineering research, university studies, benchmark audits, company reports, and cost evidence published mainly between 2024 and September 2026.

The argument starts with a simple observation. Current agents can inspect repositories, edit multiple files, run tools, write tests, and open pull requests with limited supervision. That capability makes the production of plausible changes cheaper, but it does not remove the stages that turn a change into reliable software. Review, integration, testing, security, deployment, and operations remain constraints, and they can become the new bottleneck when the number of generated changes increases.

The author calls this tension the “Agentic SDLC Throughput Paradox”: more programming activity does not necessarily mean more reliable software delivered. The idea of a “Production-Qualified Change” aims to establish a more useful criterion. A change does not fully count merely because it was written or passed an isolated test; it must pass the checks an organization requires before production, including integration, security, observability, and recovery capability where appropriate.

The paper also introduces the “Verification Tax”, the additional cost of reviewing, testing, and correcting agent output. This cost is not limited to a per-user license. It includes tokens, tool calls, isolated environments, CI execution, retries, and human revalidation. A metric that measures only lines of code, completed tasks, or generation speed can therefore produce an optimistic and economically incomplete picture.

The most operational proposal is an agentic SDLC “control plane”. This is not necessarily a particular platform, but a policy layer that assigns autonomy according to cost, expected reliability, and available human attention. A small, well-bounded change might proceed with automated controls. A data migration, permission change, or modification to a critical component should require more tests, reviewers, and execution limits.

For teams, the lesson is to design the workflow before expanding autonomy. They should define what “ready” means, what evidence an agent must attach, which commands it can run, which paths require approval, and how later rework is measured. Tests remain necessary, but they are insufficient if they do not cover integration and operations. Teams also need to observe cost per change and review time, because a local speedup may simply move work to QA, security, or support.

The paper should be read as a synthesis and research agenda, not as a definitive demonstration. Its value is placing the debate where automation promises commonly fail: at the boundary between generating code and proving that a system can maintain it safely.