Developers hooked on AI coding: fast wins, hidden maintenance costs
“It’s 2:47 a.m… I’m not debugging an outage. There’s no deadline. I’m just watching Claude Code refactor a module… and I can’t stop.” That line from Quentin Rousseau, CTO and co‑founder of Rootly, captures a new rhythm: prompt → generate → inspect → prompt again. Hours can vanish in that loop.
How common is this loop?
The Stack Overflow Developer Survey 2025 found about 84% of respondents are using or planning to use AI tools in their workflows, and roughly half of professional developers use them daily. Sentiment is cooling. The biggest frustration, “AI solutions that are almost right, but not quite”, was cited by 66% of developers. More developers actively distrust AI accuracy (46%) than trust it (33%). Overall favorability toward developer-facing AI dropped from about 72% to around 60% year over year.
Smaller polls add a behavioral angle. A Coddy Tech survey of 305 developers (reported by ZDNet) found 80% said their AI use felt more like dependence than an advantage. Forty-three percent reported coding with AI after hours when they meant to stop, 32% had skipped sleep to keep going, and 51% said heavy AI use made burnout more likely. Treat that as a suggestive snapshot: the sample is small and the ZDNet report didn’t publish methodology, but the signals match broader concerns in the field.
What’s the real cost: “verification debt” explained
“Verification debt” is the human time that piles up after you accept or ship AI-generated code: testing, debugging, security reviews, license checks, and ongoing maintenance. An AI can produce a patch or refactor in seconds, but correctness, performance, and long-term maintainability still need human scrutiny.
Large empirical work supports this. The arXiv study “Debt Behind the AI Boom” analyzed thousands of repositories (about 6, 699 after filtering) and used static analyzers like ESLint, Pylint, and Semgrep to track issues introduced by commits identified as AI-authored. The paper also explains how researchers detected AI commits by looking for signals such as bot or agent author names, Co‑authored‑by trailers, and agent-related noreply emails, so this isn’t pure guesswork. Their finding: AI-authored changes can and do introduce persistent, measurable maintenance burdens.
Why these tools feel so hard to stop
The behavioral mechanics are simple. Rousseau puts it bluntly: “Agentic coding is addictive. When the agent gets things right, you get a dopamine hit. When it fails, you get an adrenaline rush.” Watching an agent iterate is passive enough to feel like rest and active enough to keep you hooked, an intermittent reward schedule that nudges people to keep prompting and refining.
Combine that loop with outputs that look plausible but hide subtle errors, and you have a recipe for long evenings of tinkering that often turn into more verification work the next day.
How organizations amplify the problem
Tools don’t create incentives, people do. Treating AI as a pure capacity multiplier without changing performance metrics pushes teams to ship more, which raises the volume of post-merge verification and rework. Coddy Tech’s survey also reported that 74% of respondents felt heavy AI use made raises or promotions more likely, an incentive to lean on AI even when output is uncertain. That’s a classic misalignment: short-term throughput looks great on a dashboard while verification debt grows in the backlog.
Practical guardrails, prioritized and concrete
AI coding assistants aren’t going away; they’re productive for many routine tasks. The question for leaders is how to capture the upside without trading speed for long-term cost. Below are prioritized steps you can implement quickly.
Must‑do (start here)
- Make provenance visible. Require developers to tag PRs or commits that used AI (commit message template or an “AI‑used: yes/no” CI checkbox). Treat AI‑authored changes as higher risk by default.
- Shift verification left. Enforce static analysis and scanning in CI: ESLint/Pylint for language linting, Semgrep for common security and smell patterns, and a license/compliance scanner for third-party code. Block merges on critical failures.
- Require explicit human sign‑off. No auto‑merges on AI‑produced code. Add a review checklist item where an engineer confirms they understand and can explain the change before merge.
Highly recommended
- Measure net throughput, not raw output. Track features delivered minus post‑merge fixes attributable to AI commits, for example the number of post‑merge bug fixes linked to AI‑tagged PRs per sprint.
- Educate teams on auditing AI output. Run short workshops on prompt design, common failure modes, and how to validate generated code with unit tests, edge cases, and performance checks.
- Allocate audit time. Make verification hours a line item in sprint planning rather than assuming AI cuts that time to zero.
Nice‑to‑have
- Automated provenance tooling. Adopt IDE plugins or CI hooks that automatically log when agents (Copilot, Cursor, Claude Code, etc.) supplied suggestions.
- Policy on after‑hours use. Clarify whether late-night tinkering with agents counts as work and set norms to discourage compulsive, unpaid verification stretching into personal time.
Concrete example: add an entry to your PR template, “AI_USED: true/false”, and configure a dashboard that shows AI_USED PRs versus reopened bugs within 30 days. That visibility turns an invisible cost into a metric you can act on.
A 45‑second checklist for leaders
- Tag AI‑assisted commits or require an “AI used” field in PRs.
- Enforce ESLint/Pylint and Semgrep in CI with blocking rules for critical failures.
- Require reviewer confirmation that they understand AI-generated changes.
- Measure post‑merge fixes tied to AI‑tagged PRs and include verification hours in sprint estimates.
- Run a short training on auditing AI output and prompt failures.
Key questions leaders should be asking
-
Are AI coding tools actually increasing developer productivity?
They can speed routine work, but net productivity depends on verification and maintenance overhead. Use Stack Overflow’s 2025 survey for adoption context and the arXiv study (“Debt Behind the AI Boom”) for evidence that AI‑authored commits can introduce persistent issues, measure both feature throughput and post‑merge fixes to see the real impact.
-
Is developer “addiction” to agentic coding a clinical diagnosis?
Reports of compulsive after‑hours use are real and worrying, but current evidence is anecdotal or from small surveys (e.g., a Coddy Tech survey of 305 developers reported by ZDNet). Treat personal accounts, like Quentin Rousseau’s LinkedIn post, as first‑person experiences, not clinical proof. Use policy and culture to limit compulsive behaviors.
-
How big is the trust problem with AI outputs?
Trust is slipping: Stack Overflow 2025 found “almost right” outputs are the top frustration (66%), and more developers actively distrust accuracy (46%) than trust it (33%). That’s a clear signal to verify AI results and avoid blind acceptance.
-
What should engineering leaders do first?
Make AI provenance visible, enforce automated checks early in CI, require human sign‑off, and start tracking verification hours as part of velocity. Those steps prevent optimistic short‑term wins from becoming long‑term debt.
Fast iteration is seductive, but speed without inspection is a liability. Treat agentic coding as a new development mode with its own risks: visibility, verification, and incentives matter. Measure the full cost, change how you reward output, and bake auditing into the process. That’s how “faster” becomes genuinely better, not just earlier.
Sources referenced: Stack Overflow Developer Survey 2025; ZDNet reporting (including Quentin Rousseau’s LinkedIn anecdote); Coddy Tech survey of 305 developers (reported by ZDNet); arXiv paper “Debt Behind the AI Boom” (large‑scale empirical study of AI‑generated code).