A working developer — TDD for 10+ years, maintainer of a small FOSS project — describes what AI coding agents did to him at work and why he stopped using them. He had already banned AI contributions from his own project months earlier, mostly to preempt “future drama.” At his day job he kept using them, because everyone did. The essay is written as a confession, and its subject is not broken code but the complacency that made him stop noticing it.

The escalation is described as gradual and rational at every step:

  • Enhanced autocomplete in VS Code, then code-generation models, then handing over whole functions and tests.
  • Asking the model to write the tests first broke TDD — the not-biasing-the-tests half of the practice disappears when the same model writes both sides.
  • Then whole Jira tickets pasted into the agent, then several agents running at once in separate git worktrees, wired into Jira with a command-line tool.
  • He caught the agent co-signing his commits and rushed to opt out — “like, I wanted to pretend the code was my own.”
  • Review stopped being real: PR descriptions grew to seven paragraphs of AI prose, he stopped reading them, and he started accepting changes he could not tell were bad. His line: “you cannot tell why it’s bad. You have lost control.”

The part that lands is the throughput math. A task he could have done in 20 minutes took an agent 5 minutes and then two days of his attention, because review arrived fragmented across many other in-flight agents. Switching contexts is cheap for a machine and expensive for him. In his experience the multiplied output is an illusion and the multiplied exhaustion is not. He estimates that neither he nor his peers know even 20% of what they push to production.

The turning point was a human code review of one of his own PRs: a coworker pointed out that the test he had written did not test the scenario his change affected. That is a beginner failure for someone with a decade of TDD behind him, and it convinced him the fix was not “prompt harder” but stopping altogether — “even if that costs me my job.” A month later he is back on TDD, back to 5-file PRs and two-line descriptions, back to code reviews he can answer in detail, and argues he is no less productive than before. He also floats a theory of his own: that model quality is being quietly degraded over time the way Google search results were, and that AI companies under financial pressure have the same incentive. That is his suspicion, not a demonstrated finding.

The 181-comment thread on Hacker News is unusually substantive: a team-level version of the same story with a fix attached, a straight disagreement, and the tooling workaround that practitioners actually use.

What the thread adds

  • bunderbunder — the team-scale replication, with a countermeasure. Six engineers each juggling at least two projects: tickets moved fine and PR generation was “through the roof,” but projects stopped reaching a state customers were happy with. “Soon we rediscovered Little’s Law.” Strict work-in-progress limits and two people minimum on every non-trivial project brought code churn and the token bill back down and cleared the logjam — and stakeholders, who never cared about velocity metrics, stopped complaining.
  • user43928 — direct disagreement with the essay’s core claim. “I have not lost control.” Their setup: no code review on one project but extensive QA testing, code review on others, prompts that push back on edge-case padding to keep PRs small, and two-line PR descriptions written by hand — dumping paragraphs of AI output into a review request, they say, is “disrespectful.” They report being more productive than ever.
  • st3fan, thevinter and user43928 — three separate framings of the same failure as a workflow problem rather than a property of the tools. st3fan: “This is a personal time management problem. Not a tool problem.” thevinter: the conclusion is “somewhat exaggerated,” and his own bottleneck is now review capacity, with giant PRs getting hand-waved — while throwaway scripts and log analysis stay clearly worth it.
  • XCSme and black_knight — two experiences that diverge from the essay. XCSme answers the “writing the code was never the challenge” line by saying the thinking about implementation was the time sink, and that cheap iteration (“add 2FA” in five minutes, throw it away and restart) is the gain. black_knight had the same reaction to generated code until this year: discussing design first, then two or three iterations plus a review pass, now makes Claude Code’s output acceptable most of the time.
  • dkn — the concrete tooling countermeasure for large legacy codebases: expose AST-based tools to the agent, parse the codebase with tree-sitter into a SQLite graph of definitions and usages, and add fitness statistics. Without that, agents get simple things wrong and “tend to return different results.”
  • whatever1, replying in thevinter’s subthread — a process-level answer: “Implementation reviews are not useful anymore.” Move review upstream to designs and specs, and validate test coverage instead.
  • adrithmetiqa — the same decay outside software engineering: sysadmins and generalist IT engineers now troubleshoot by pasting logs and accepting the answer, “zero added value while they ctrl-c ctrl-v themselves out of a job.”
  • elwebmaster — a theory, contested in the thread: that providers swap in quantized models under peak load or on cheaper plans, so you cannot tell whether a given output got worse or the context simply grew; they suggest running the same prompt across providers as a test. simianwords calls it flatly a conspiracy theory, and throwuxiytayq says they have never seen that kind of degradation in Codex — so treat it as a hypothesis, which is all it is.

The question the thread kept asking

The essay asserts that “there was not a single task I gave to the AI that I could merge as is,” and the thread wanted the receipts. wuhhh asks for it plainly: “I’d love to see what their specific issues with generated code were and how they fixed them. I mean, even one or two short examples would be amazing.” The post never supplies one. Other commenters ended up supplying their own instead — stack_framer with three failures from a single session (a file read from the wrong directory because it had the same name, a function call count of 20 against the IDE’s 17, a variable that does not exist anywhere in the repo), asimpleaspossi with decades of programming and generated code that “has NEVER worked or was so convoluted that I threw it away,” and gizajob, who wrote a whole book with Claude as an experiment and concludes every line needs rewriting: “the style is so bad it should actually just be binned rather than rewritten.” pigpop offers the explanation for why prose is the harder case: validating a codebase can be automated, validating 300 pages of prose cannot, and “many LLMs have gotten much worse at writing prose as they have gotten better at writing code.”

The question left open about the next generation

Jare writes from 1983-era Z80 programming and several 1-2 year gaps in their career: the skills came back every time when they returned to the trenches. Their question is what “AI-native” engineers will have to come back to, and where a new engineer gains expertise when they never truly controlled the layer they were working at. Nobody in the thread answers it.

A note on reading comments as evidence: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering here is HN’s own ranking, not a vote. This is a slice of the thread, and the model-degradation theory above is quoted as a theory — not as a finding.