The vibecoding backlash, and the rebuttal: inside a real AI coding agent debate

In January 2026, developer Mo Bitar published “After two years of vibecoding, I’m back to writing by hand” — and it went to the top of Hacker News, pulling 865 points and 634 comments. His core complaint wasn’t that agents write broken code. It’s that they write code that looks fine in isolation but never coheres into a real system: “Agents write units of changes that look good in isolation…But respect for the whole, there is not.” His conclusion was blunt: “I’m back to writing by hand for most things. Amazingly, I’m faster, more accurate, more creative, more productive, and more efficient than AI.”

The rebuttal happened in the same thread

What makes this worth covering isn’t just the post — it’s that Simon Willison, one of the most-cited independent voices on AI-assisted development, replied directly underneath it, and disagreed on the record. Quoting Bitar’s line about agents not evolving a spec over time, Willison wrote: “That’s your job. The great thing about coding agents is that you can tell them ‘change of design: all API interactions need to go through a new single class that does authentication and retries and rate-limit throttling’ and… they’ll track down dozens or even hundreds of places that need updating and fix them all.” He closed with a pointed jab: going back to hand-writing code “because you don’t have the agent-managerial skills to tell the coding agents how to clean up the mess they made feels short-sighted to me.”

That would be a tidy story — skeptic vs. true believer — except four months later Willison published his own essay complicating his position. In “Vibe coding and agentic engineering are getting closer than I’d like” (also a top HN story, 787 points, 885 comments), he admits to a specific discomfort with tools like Claude Code: “I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it’s just going to do it right… But I’m not reviewing that code. And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production?”

That’s a meaningfully different position than his HN reply to Bitar — not “you’re managing the agent wrong,” but “I’m not sure I’m managing my own review discipline correctly, and neither is anyone else.” Other commenters on his post landed in the same place from different angles: one wrote about AI-generated comments and READMEs, “I almost never let unedited LLM comments pass,” while another worried about a growing pool of “vibeslop” repos where “hundreds of tests, hundreds of commits, dozens of stars” no longer signal that anyone actually used the thing in production.

What this means if you’re buying a coding agent

None of this is resolved, and it shouldn’t be treated as resolved when you’re evaluating tools. The real disagreement isn’t “do agents write good code” — it’s whether the workflow around the agent (review discipline, spec management, test coverage) is something the tool enforces or something you have to supply yourself. That’s a legitimate, comparable axis across vendors, not just a matter of taste. If you’re weighing options in this category, Crail’s AI coding agents directory and our Cursor vs. GitHub Copilot comparison are built around exactly that kind of workflow-level detail, not just benchmark scores.