Engineering blog
Ten documented failure modes in AI-assisted development, and a working model that keeps engineers in charge
Teams adopted AI coding tools faster than any developer tooling before them. The measurements are now in: more defects, heavier review queues, a new class of supply-chain risk, and a productivity gain that is mostly perception. This post collects the strongest published evidence, then shows where we think the fix actually lives.
1.7xIssues per AI pull request
19%Slower, while feeling 20% faster
19.7%Suggested packages that do not exist
September 2026
The claims are easy to find. The measurements took longer. What follows are the failure modes with the strongest published evidence behind them, drawn from controlled trials, large-scale repository analysis and industry surveys, and what they add up to for anyone running an engineering team.
1. More defects, and subtler ones
The clearest head-to-head comes from CodeRabbit, which analysed 470 open source pull requests in late 2025: 320 with AI co-authors, 150 written by humans alone. AI-authored changes carried 10.83 review issues per PR against 6.45 for human-only work, roughly 1.7 times as many. Critical and major defects ran 1.3 to 1.7 times higher.
The shape of the errors matters more than the count. Logic and correctness issues rose 75%, and security findings appeared 1.5 to 2 times as often, led by improper password handling and insecure object references. The models made fewer spelling mistakes than people, and produced more testable code. The defects did not go away. They moved up the stack, out of the territory a linter covers and into business logic a reviewer has to reason about: a greater-than where a greater-or-equal belonged, an authorisation check on the wrong branch.
2. Bloat you pay for later
GitClear has tracked 211 million changed lines across enterprise and open source repositories since 2020. In 2024, duplicated code blocks of five or more lines appeared eight times as often as before, and for the first time on record copy-pasted lines outnumbered refactored ones. Code revised within two weeks of landing grew from 3.1% of commits in 2020 to 5.7% in 2024.
Their 2026 follow-up shows the curve still climbing: block duplication up 81% over 2023, refactoring moves down 70% against 2022 levels, error-masking constructs up 47%. GitClear's reading is blunt. The default AI workflow is optimised to close the ticket, a happy path and a passing test, and it quietly taxes the reuse and consolidation that decide what a codebase costs to own in year three.
3. Review became the bottleneck
Developers told Sonar's State of Code survey that 42% of the code they commit is now AI-generated or assisted, and 38% said reviewing that code takes more effort than reviewing a colleague's. The volume shows up in the queue. Faros AI's telemetry across thousands of teams found that under heavy AI adoption pull requests are 51% larger, carry 54% more bugs, and median time in review has grown 441%.
The most worrying number is quieter: 31% more pull requests merge with no review at all. When every change arrives as a 500-line diff, finding the risky lines is needle-in-a-haystack work, and tired reviewers start waving things through.
51%Larger pull requests
+441%Median time in review
31%More PRs merged unreviewed
4. Faster is a feeling
METR ran a randomized controlled trial on this question in 2025: 16 experienced maintainers, 246 real issues, repositories averaging over a million lines. With AI tools allowed, tasks took 19% longer. The same developers had predicted a 24% speedup, and after finishing, still believed they had been 20% faster.
The result carries caveats, and METR published them: the confidence interval was wide, and a 2026 follow-up with 57 developers measured a 4% slowdown with an interval spanning zero. What survived both rounds is the perception gap. Developers misjudged their own speed by about 40 percentage points, and nearly every corporate claim about AI productivity rests on self-reports like theirs.
Downstream, Google's 2025 DORA report ties AI adoption to roughly 10% more code instability, and a 2026 Lightrun survey found developers now spend 38% of the working week on debugging and verification. In the same survey, not one engineering leader called themselves very confident that AI-generated code behaves correctly in production. And for plenty of experienced programmers the inline autocomplete itself is the problem: a suggestion that interrupts mid-thought costs more than the keystrokes it saves.
5. Dependencies that do not exist
A USENIX Security 2025 study generated 576,000 code samples across 16 models and checked every recommended package against the real registries. 19.7% did not exist. The 205,474 invented names are not random noise either; models repeat them, which is what makes "slopsquatting" viable: an attacker registers the hallucinated name on PyPI or npm and waits for the install. Commercial models did better than open ones, 5.2% against 21.7%, but none reached zero. Every AI-suggested import is untrusted input until someone checks the registry.
6. Trust, skills and morale
Stack Overflow's 2025 survey caught the mood: 46% of developers actively distrust AI accuracy against 33% who trust it, and the top frustration, named by 66%, is output that is almost right but not quite. 45% said debugging AI-generated code takes longer than writing it themselves would have. Favourable sentiment toward the tools slid to 60%, from above 70% in both 2023 and 2024, and Sonar found 96% of developers will not trust AI output without manual review. Usage keeps climbing anyway. Trust and adoption are moving in opposite directions.
Underneath the numbers sits a role change. Engineers describe their day as writing instruction files, feeding prompts and reviewing machine output rather than programming, and many report caring less about code they did not write. The learning cost is real too. A developer who hands implementation to an agent skips the struggle that builds judgment, which is exactly the capability a team needs left over when the tools go down. Mandates sharpen the resentment: the pressure to adopt usually arrives from management, not from the engineers whose output is being measured.
7. The replacement bet failed
Orgvue's survey of business leaders, reported by CNBC, found 39% had made staff redundant because of AI, and 55% of those now admit the redundancy decisions were wrong. Robert Half puts the reversal at 29% of companies rehiring the roles they cut. Careerminds measured what that costs: a third of AI-layoff companies rehired a quarter to half of the eliminated roles, another 35.6% rehired more than half, and one employer in three spent more on restaffing than the layoffs saved. Ford is rehiring hundreds of engineers for quality work its automated systems could not handle. Challenger, Gray & Christmas counted nearly 55,000 US job cuts attributed directly to AI in 2025; Forrester pegs regret at 55% of the companies that made them, and Gartner expects roughly half of AI-attributed layoffs to be reversed by 2027.
55%Regret AI-driven redundancies
29%Rehired the roles they cut
1 in 3Spent more restaffing than they saved
None of this argues for abandoning the tools. The same studies that document the damage record real gains on boilerplate, prototypes and unfamiliar codebases. It argues that generation outran verification, and that bolting an assistant onto yesterday's workflow hands the bill to whoever reviews the output. The fix is structural, and it is where we will close.
8. Why we built Krithi
Every failure above shares a shape: generation got fast, verification did not, and unverified output piled up in front of the humans accountable for it. Krithi, the SDLC agent from lowtouch.ai, restructures that pipeline rather than accelerating it. Work moves through staged gates, and a human decision sits at each one.
- Requirements come first. The extraction agent drafts the spec from legacy code and customer feedback, and a human approves it before planning starts.
- The sprint plan and its technical sequence are signed off by an engineer before any code is written.
- Every branch runs functional, API and performance tests. Failures route straight back to the coding agent until the branch passes.
- Passing branches get a self-audit: repository style standards, ISO/IEC 25010 quality checks, and security scans before handoff.
- A human engineer owns the merge. Test evidence travels with the pull request, and the audit trail records who approved what at every stage.
The effect on the review problem is direct. A failed test never pages a person; the branch routes back to the coding agent, which fixes and re-runs until it passes. Reviewers stop hunting through 500-line haystacks and get one clean branch that has already cleared functional and performance testing (Playwright across Chromium, Firefox and WebKit), a self-audit against the repository's own style standards and ISO/IEC 25010, and security scans mapped to OWASP Top 10, CWE Top 25 and NIST SSDF 800-218, with the evidence attached.
Humans hold the requirements gate, the plan gate and the merge. The agent holds the toil.
The role that emerges is conductor, not babysitter. Engineers own the requirements, the sequencing and the merge decision, so they keep structural command of a codebase they can still explain. That is the answer to deskilling and to the apathy that comes from reviewing text you never shaped. Teams that are stretched can run the same pipeline as a Velocity Pod, a managed service where our senior engineers drive Krithi, hold the approval gates and answer for every merge. And when the work is regulated, the whole loop runs inside your own perimeter, down to fully air-gapped deployments on local models. Details at lowtouch.ai/agents/krithi.
