{"slug": "why-agentic-coding-needs-extra-staff-to-stay-stable", "title": "Why Agentic Coding Needs Extra Staff to Stay Stable", "summary": "As of August 2026, agentic code is twice as error-prone as human code after human QA, with agentic systems contributing up to 1.2 production defects per day, according to an analysis based on public sources. To maintain stability, the article recommends adding two exclusive defect-fixing, agentic-focused human engineers, a team of three that costs ten times less than employing one non-AI native engineer given the rate of code generation. Until LLM-based agentic systems improve their error rate, the volume of agentic code generated per day remains a business risk.", "body_md": "This article quantifies the difference between human-authored and agentic-produced software.\n\nThe summary of this article is that as of August 2026, agentic code is twice as error-prone as human code after the agentic code has being subjected to human QA.\n\nBecause an agentic system can generate significant amounts of code per day, agentic systems can contribute up to 1.2 production defects per day.\n\nAt this rate, there is a significant risk that engineer focus becomes dominated by defect fixing. To prevent this, this article costs two additional exclusive defect-fixing, agentic-focused human engineers. The cost of this team of three is still ten times less expensive than employing one non-AI native engineer when the rate of code generation is taken into account.\n\nUntil LLM-based agentic systems improve their error rate, the volume of agentic code generated per day remains a business risk.\n\nAll of the supporting evidence in this article is taken from public sources that can be found in the Further Reading section at the end.\n\nWe start by considering what a human engineer does.\n\n## The human engineer\n\nOn average, a software engineer will commit between 10 to 40 lines of *production\nready* code per day.\n\nThis code has passed:\n\n- Peer review\n- Unit tests\n- Integration tests\n- Linting & static analysis\n- CI/CD checks\n- QA acceptance, in many organisations\n\nThis code has met a quality bar so that confidence is high the code can be\neffectively used in production. Producing 10 to 40 lines per 24 hours is *not*\ntyping speed. An engineer spends 20 to 30% of their time generating code. The\nremaining time is required to understand the problem sufficiently well so that\nthe 40 lines of code adequately address the problem.\n\n## Human error rate in code\n\nHuman engineers introduce defects during construction. Industry studies show\nthat newly written code contains between 15 and 50 defects per thousand lines\nof code (KLoC). This is a defect potential of between 1.5 to 5%, which is the\nhuman error rate *before* any quality checks take place.\n\nIndustry defect-removal efficiency (DRE) based on code inspection (e.g., PRs), testing and release-process quality gates typically removes between 85 to 95% of human defects. This leaves approximately between 3 to 5 defects per thousand lines of code.\n\nThe Quality Assurance (QA) step reduces this further. Across large datasets, production-ready code typically contains between 0.5 and 1 defect per thousand lines of code, a defect rate of 0.05 to 0.1%.\n\nIt is this code that is deployed into production.\n\nTherefore, taken together and expressed as range mid-points, a human-only process will generate 25 lines of code per day, and that code will contain 0.075% defects.\n\nIn 1,000 LoC there will be 0.75 defects.\n\n## Testing\n\nWhen applied to human-authored code, human-driven quality checks remove the following percentage of defects:\n\n- 50 to 70% removed by PRs (code review and manual inspection)\n- 30 to 50% of the remaining defects are removed by testing (unit, integration and system)\n- 30 to 60% of the remaining defects are removed by late‑stage functional testing, regression, exploratory testing, and release validation\n\nTaking mid-points in a three-stage pipeline, if 100 defects enter the pipeline, stage one removes 60%, stage two removes 40% of those that remain after stage one, and stage three removes 45% of those from stage two. Of the 100 that enter the pipeline, 13.2 emerge undetected.\n\nWithout stage one, given 100 defects entering a pipeline of just stages two and three, 33 emerge undetected.\n\n## The agentic engineer\n\nAgentic tooling treats the LLM as an active problem‑solver, not a passive code generator. Instead of giving the model a single prompt to generate code, a goal is given, and with iteration the tooling reaches that goal through multiple attempts.\n\nThe core agentic engineering loop is:\n\n- Plan — the agent decomposes the goal into steps, designs an approach, and decides what to do first\n- Act — it writes code, runs tools, queries APIs, or generates artefacts\n- Observe — the agent inspects test results, errors, outputs, and environment feedback\n- Revise — it updates the plan, fixes code, or changes strategy\n\nThis loop continues until the agent meets the success criteria of the human supervisor.\n\nAs the human is an essential part of the agentic workflow, an agentic system is not generating code for 8 hours per day.\n\nAn agentic workflow is typically:\n\n- Human writes a task spec\n- Agentic system generates code\n- Human reviews\n- Agentic system retries / fixes\n- Human integrates\n- QA gates run\n- Iterate\n\nIn practice, an agentic system is generating code for 2 hours per day.\n\nThis is because the human supervisor is:\n\n- reviewing\n- steering\n- correcting\n- decomposing tasks\n- validating architecture\n- running tests\n- approving PRs\n- collaborating with co-workers (and waiting) to achieve the above\n\nAn agentic code generator can produce raw code at a rate of approximately 3K LoC per hour. But this is the raw generation rate (typing speed) — no quality checks have been applied as the human does before code commit.\n\nTo ensure a like-for-like comparison, once the same quality checks are applied to agentic code so confidence is high the code will work appropriately in production, a human-guided, agentic system will generate between 150 to 600 LoC per hour.\n\nAs the agentic system is running for two hours per day, an agentic system, as a mid-point, will generate 750 production-ready LoC per day.\n\n## The agentic error rate in code\n\nThere is no published, agreed-upon agentic error rate per thousand lines of code, in the same way we have for humans.\n\nAs of August 2026, the closest we can get is to state the empirically observed ranges from current benchmarks.\n\nSWE-Bench (2024) shows an LLM defect rate of 0.5 to 1.5% defect rate based on a manual inspection of patches. AgentBench (2023 to 2024) shows a 0.5% to 2% defect rate. HumanEval-X shows a defect rate of 1 to 2%. Studies from Meta, Google and Microsoft show a 0.5 to 1% defect rate which is 5 to 10 times worse than human-authored code.\n\nThis is the defect rate *before* quality checks are applied. The mid-point is\n1.25%.\n\nAt this rate, the 750 lines of agentic code generated per day will contain 9.375 defects.\n\nPassing the 750 lines of code per day through a human PR and human QA pipeline, reduces the number of defects to 1.237 per day.\n\nIn 1,000 lines of code there will be 1.65 defects.\n\n## Comparison\n\n| Mode | Daily Throughput (LOC/day) | Post‑QA Defect Rate | Defects per Day |\n|---|---|---|---|\n| Human engineer | 25 | 0.075% | 0.019 |\n| Agentic engineer | 750 | 0.165% | 1.2375 |\n\nThe defect rate for the human engineer looks low. Humans generate between 15 to\n50 defects/KLoC in *non-quality checked* code, but PR review removes 85 to 95%\nof these and QA removes 70 to 90% of what remains, so only about 0.75 defects\nper 1K LoC find their way to production, which is 0.075%.\n\nIn short, given the smaller amount of quality-checked code humans commit per\nday, the defect rate *per day* is also small.\n\nPer thousand lines of code, agentic code is just over twice as error‑prone as human code after QA (0.165/0.075 = 2.2).\n\nBut because agentic systems produce thirty times more code per day, the total number of escaped defects per day is around sixty-six times higher (\\(30 \\times 2.2 = 66\\)).\n\nThese two ratios measure different things: defect density vs defect volume. Both are true.\n\nThis is the core trade‑off: agentic systems dramatically increase throughput, but the increased volume significantly multiplies escaped defects even when agentic defect density remains low (0.165%).\n\n## Consequence\n\nIt is clear that agentic can write more code: thirty times more per day.\n\nBut that is not significant.\n\nThe question for your company is:\n\nCan your organisation absorb 66 times more escaped defects per day without grinding the pipeline into a bug‑fix treadmill?\n\nAt a rate of 1.2375 defects per day, after 20 days of one agentic agent producing 750 lines of code every 24 hours, the total number of defects in production is 24.75.\n\nAssuming it takes one day of agentic engineer time to fix one defect, each unit of work creates 1.23 units of extra work to fix the defects (20/24.75).\n\nAt this defect rate, generating 750 lines of agentic code per day leads to a software development lifecycle dominated by bug fixing.\n\nOne solution is to employ one agentic engineer that is solely dedicated to fixing defects.\n\nAt a rate of one defect fixed per day, after one month 5 bugs would remain. Therefore, the outstanding number of defects would grow by 5 per month.\n\nNote: the second agentic engineer can only fix defects. They cannot create new\ncode as that *increases* the number of defects in production. It does not\nreduce it.\n\n## Reducing defect accumulation to zero\n\nTo reduce the number of outstanding defects to zero per month, there are two solutions:\n\nEmploy an additional agentic engineer to fix bugs for a total three. One\nagentic engineer implements new features, introducing 25 defects per month. The\nother two agentic defect fixers only address these issues at a rate of one per\nday. Two such engineers can fully address the 25 defects per month, but they\nmust only fix defects, not create any new code or else *they* will add defects\nto production.\n\nThe other solution is to reduce the average time to address a defect from 1 day per defect to 0.8 days. If this can be achieved on average, only a team of two is required as before: one to create new features, and one to remove the 25 defects per month at a rate of 0.8 days per defect.\n\n## Costing three or two engineers\n\nAssuming £525 per agentic engineer per day, for the team of three, we have a daily cost of £1,575 to release 750 lines of code into production. This is a per line cost of £2.10.\n\nFor the team of two under the assumption of 0.8 days to fix a single defect, the total engineer cost is £1,050 per day to release 750 lines of code to production. This is a per line cost of £1.40.\n\nThe human-only (no agentic) rate of 25 lines of code released to production costs £21 per line of code.\n\nTherefore, the cost of a three-person agentic team (one generation, two defect fixing) is ten times cheaper than a human working on their own.\n\n## Conclusion\n\nAgentic engineering can produce thirty-times as much code per day but additional staff are required to ensure the agentic pipeline does not become dominated by defect fixing.\n\nEven when two additional engineers are considered, the agentic team of three approach is an order of magnitude cheaper for thirty times the production code generation volume.\n\nRead next:\n\n[Why Agentic Coding Will Always Introduce Errors]\n\nA deeper look at why agentic systems inevitably introduce semantic mistakes — and why only human‑authored tests can address this.\n\n## Related Articles\n\n[Building Safe, Compliant and Sustainable LLM Systems](/articles/leadership/notes/building-safe-llm-systems.html)[Software Delivery Constraints and Pipeline Throughput](/articles/leadership/notes/software-delivery-is-a-pipeline-not-a-coding-task.html)[Hiring in an AI World](/articles/leadership/notes/hiring-in-an-ai-world.html)[Measuring Reliability in the Age of AI](/articles/leadership/notes/measuring-reliability-in-the-age-of-ai.html)[Team AI is the Next Step Beyond Cut-and-Paste AI](/articles/leadership/notes/team-ai-is-the-next-step-beyond-cut-and-paste-ai.html)\n\n**If this was useful**, you can get more pieces like it in the Phroneses newsletter.\n\n## Table of Contents\n\n## Further Reading\n\n[Applied Software Meaurement, Capers Jones, 1996, McGraw-Hill](https://archive.org/details/appliedsoftwarem0000jone/mode/2up)[IBM Orthogonal Defect Classification, 1992](https://en.wikipedia.org/wiki/Orthogonal_defect_classification)[A Methodology for Collecting Valid Software Engineering Data, Victor Basili and David Weiss, 1984.](https://ieeexplore.ieee.org/abstract/document/5010301/authors#authors)[SWE-Bench, 2023](https://arxiv.org/abs/2310.06770)[AgentBench, 2023](https://arxiv.org/abs/2308.03688)[HumanEval-X Benchmark Overview](https://deepwiki.com/zai-org/CodeGeeX/6.1-humaneval-x-benchmark)[Code Llama: Open Foundation Models for Code, 2023](https://arxiv.org/abs/2308.12950)", "url": "https://wpnews.pro/news/why-agentic-coding-needs-extra-staff-to-stay-stable", "canonical_source": "https://phroneses.com/articles/leadership/notes/agentic-extra-staff.html", "published_at": "2026-08-31 00:00:00+00:00", "updated_at": "2026-08-31 09:53:49.610203+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-safety", "ai-research"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/why-agentic-coding-needs-extra-staff-to-stay-stable", "markdown": "https://wpnews.pro/news/why-agentic-coding-needs-extra-staff-to-stay-stable.md", "text": "https://wpnews.pro/news/why-agentic-coding-needs-extra-staff-to-stay-stable.txt", "jsonld": "https://wpnews.pro/news/why-agentic-coding-needs-extra-staff-to-stay-stable.jsonld"}}