Alex Ewerlöf has used LLM coding tools for four years, built his own agent harness, and says plainly that he is not anti-AI. His essay attacks one specific claim: that “coding is solved” and engineering is now mostly a matter of taste. The objection is economic — generating code got cheap, but generating code was never where the money went. The 288-comment thread on Hacker News is where that argument gets stress-tested, and where the strongest disagreement arrives with receipts of its own.

What the essay argues

  • Creation is cheaper; creation was never the expense. Maintenance, reliability, security and scalability — the non-functional requirements — are most of the lifetime cost of software a business depends on.
  • Only three categories of software can skip reading the code: personal projects, proofs of concept, and weaponized AI. All three either tolerate high risk or deliberately point it at someone. Healthcare, finance, automotive, defense, power plants, aviation and manufacturing do not.
  • Accountability can’t be delegated to something that can’t be punished. Ownership rests on three pillars — knowledge, mandate, accountability — and removing any one of them breaks it: “AI can explain it to you but it cannot understand it for you.”
  • Why coding LLMs appear to work: we built a feedback loop that feeds compiler and runtime errors back to the model and loops until most errors are “solved or hidden.” Underneath, the engine is still stochastic, and gets less accurate as the context window fills.
  • He points at the flagship artifact of the narrative. Claude Code has shipped bugs where it returns Bun’s help menu, silently deletes its own installer, and bills for capacity users already had — from the vendor that owns the model, the harness, the prompt and the runtime.
  • Fallacies he names and dismantles: “you can create a full spec upfront,” “English is the new programming language,” “the leverage has shifted to taste,” “AI is an equalizer” (it is a multiplier, and the direction of the force vector is what matters). His receipt on overhead: bumping five npm dependencies, all patch releases, took his agent 12 minutes and 72 steps. By hand it takes under a minute.

The “AI overdose” checklist near the end is only half a joke — zero tolerance for disagreement, running to AI for anything slightly challenging, more time with AI than with people — and it ends with a trick: he hides item five and asks whether you noticed you were skimming.

The ask is aimed at leadership rather than at tooling. Don’t force AI into every workflow and surface; prioritize reliability and accountability over velocity, because the customer absorbs the bugs. And keep an AI-free project of your own, for the day you’re back on the job market: “Don’t sacrifice your long term relevance for short term velocity.”

What the thread adds

  • hibikir — a legal correction to one of the essay’s premises. “You cannot be responsible for what you can’t control” doesn’t hold: law holds people accountable for things they don’t control all the time. “Treat it like the releasing a wolf pack, or selling an unsafe toy that can maim children. There’s precedent everywhere.”
  • bluegatty — a correction to the mechanism, not the conclusion. LLMs are good at code because they were “trained by the compiler”: verification-based training means code is the domain where models have the strongest verifier, not the weakest. Their split: “‘Coding’ per se is 100% solved… The LLM is like a writer’s assistant, who has perfect prose and grammar, but doesn’t really write ‘stories’.”
  • efficax — the strongest counter-position, from someone who says they wrote code behind US debit card transactions: “Reading the code does not mean you understand the code.” The alternative to reading is having LLMs build fuzzers, property tests and full traces and analyze every scenario — “The LLMS are very good at logic, by the way.” layer8 replies that testing is not the same as understanding or proving correctness, and jdkoeck that you cannot reason about a program without reading at least its high-level code, “because they’re reliable abstractions, unlike prompts!”
  • temp00345 — the dissent most likely to sting: “This article would be 100% correct if it came out 1 year ago, 75% correct 9 months ago, 50% correct 3 months ago and it’s probably 25% correct now if not less.” Their advice is to try Opus 5.5 or Astra 6 on an entire app, UI and all, and compare it to a year ago. an0malous answers as a practitioner: the latest models still ship silent failures — one that would have deleted all user data without anyone noticing — and “if I do even 3 months of pure agentic coding with no code reviews, it’s aged 10x faster than a human coded codebase.”
  • askonomm and whatever1 — the casualty is review itself. Review used to be the thing that kept bad code out of the trunk, and it can no longer scale to the volume; some shops have answered by having AI review AI. “Even if you are competent I cannot review your 5,000 lines of code you produce per day vs the 100 you were producing before the LLM apocalypse.”
  • manny_rat and thesumofall — two commenters dispute the premise rather than the argument. manny_rat has 20 years in industry and never had to worry about risk at that level: “I’d be genuinely surprised if even 1% of software requires aviation levels of risk tolerance.” thesumofall: “the author underestimates how boring and simple 90% of enterprise software is,” and most of it runs fine anyway. mxey replies with the obvious objection: “The majority of existing software runs without a glitch? Are you being serious?”
  • argee — reframes the whole debate as a motte-and-bailey. The claim that survives is “programmers no longer need to type the code out by hand”; the claim being smuggled in is that “software architecture is solved, there is no longer any need for human intervention in the architecture or design of any software.”

The question the rebuttals don’t answer

Several of the newer-model rebuttals in the thread argue from personal speed. o_nate asks them to close the loop instead: “it’s not enough just to point to newer models without explaining how the newer models solve these problems. Can the new models take full end-to-end ownership of a system? If not, how do they solve the problem of humans taking ownership of AI generated code?” That is the essay’s actual claim, and across the top of the thread nobody answered it directly — the discussion kept resolving into “try the new model,” which is a different statement.

HN publishes no per-comment scores, so the ordering here is HN’s own ranking, and handles are pseudonymous. This is a slice of the thread, not a consensus.