Alexandru Nedelcu opens with three sentences he has heard in the past month: “I haven’t written code since 2025”, “Code reviews are dead”, “People no longer read code”. His claim is not that the tools are weak. It is that the thing being traded away has no way of showing up on a scoreboard until it is far too late to fix.

The mechanism is the argument worth keeping. Code maintainability and good architecture have no good measurements, because their effects take months or years to appear. Any reinforcement learning needs a reward signal that can be measured immediately. So the signal models train on is not maintainability — it is rules from rulebooks written for beginners, plus patterns from code in the wild, which is mostly bad. His sharpest line is the falsification test: if maintainability had a discernible fitness function, “it would’ve been baked into our linters”.

What bad code actually looks like gets a paragraph that reads like symptoms rather than metrics:

  • Changing one thing breaks the program “in very non-deterministic ways”, or breaks logic somewhere else entirely — the butterfly effect.
  • Adding a feature means editing code in several places and still missing one, producing inconsistencies.
  • The design’s invariants are unclear, and the authors who understood them are no longer around to guard against violations.
  • It is hard to test without mocks and exposed implementation details, so the tests are fragile and end up blocking the refactoring you need.

Experienced engineers smell this long before the damage is measurable, on intuition built from long hours debugging production and swearing never to repeat the mistake. That intuition resists being written down as rules, because everything is context-dependent — hence his formulation that experts don’t follow the rules, they make them.

Then the concrete failure of the tools he is not against. Ask a state-of-the-art model to simplify code and it splits functions into smaller functions that are not actually reusable: to understand the original you now have to read the extracted pieces too. Defining reusable, clarifying functions is an art that takes mastery, and on the Dreyfus model most developers are still “advanced beginners” at it — as is the AI.

The part he frames as the real loss is the learning loop. Developers who let a model both write and read code stop making choices, stop taking responsibility for mistakes, and so stop learning from them. The model does not learn from its mistakes either. Nedelcu is explicit that he is no Luddite — he uses LLMs daily for “all the boring, soul-sucking shit”, teaches colleagues what he learns, and likes the efficiency — but he treats it as a tool, and thinks “its light will also fade”. He ends with a prediction companies will hate and buyers may yet reward: more of them will boast a “NO-AI” policy as a competitive advantage, and they will be right. The assembly-line objection gets a specific answer — software is a special case, because everything the industry does is already automation at scale, and LLMs are not the only means of it. You can ask a model to write a C/C++ compiler, or you can clone GCC for free and get a better one.

What the thread adds

The 232-comment thread on Hacker News is unusually good for this genre, and its best contributions are about measurement rather than taste.

  • davedx lands the direct hit on the essay’s central claim: “Who has no wisdom? There are dozens of ways to measure code maintainability. Cyclomatic complexity is just one.” bunderbunder supplies the research the essay skipped — cyclomatic complexity has been “pretty solidly discredited within the maintainability research community for decades”, and Sonar’s cognitive complexity only correlates around 0.5 with how hard programmers actually found the code to read. The essay’s position survives this only in the weaker form: measurements exist, good ones are the hard part.
  • davedx on the continuum, which is where most working engineers actually sit: “You can absolutely use coding agents AND have maintainable code. But yes, the coding agents will not magically make everything maintainable if you don’t tell them to.”
  • NalNezumi moves the cost from code to institutions: “The problem imo is the slow deterioration of institutional knowledge that offloading the mental task of wisdom gathering to AI is causing”, by analogy with manufacturing offshoring — America reaching a point where it “simply didn’t even have the capacity, or expertise anymore to produce stuff”. jordanb notes the dismissals sound identical to the ones that greeted outsourcing at the time.
  • FinnLobsien gives that argument its sharpest form: without people who know what good looks like, you lose the ability to learn from colleagues and to improve anything at all. weego has a field report: an outside MBA’s AI-driven “deep dive” produced a national marketing campaign that copies the market leaders.
  • EastLondonCoder — the simile the thread kept quoting: “Suno generated music has a very unpleasant feeling of sounding like competent music with nothing to say. I’d say that vibecoded software is similar.”
  • peterpanhead voices the fatigue (“These posts are getting old, very quick”), and goda90 answers with stakes: “I work in an industry where software bugs can cause real harm to real people. I care that my coworkers are producing more bugs than ever because they don’t take the time to think about the code anymore.”
  • dnautics provides the counter-anecdote on wisdom: “Usually I am wiser than the AIs but there have been times where the AI has pushed back and made me see the light on some poor design I was about to pursue.” ACCount39: “Sometimes, a rubber duck is good enough. But sometimes, you can benefit a lot from a rubber duck that can say ‘actually, your entire line of reasoning is wrong’.”

The question the thread couldn’t answer

Several commenters converge on the same ask in different words: if maintainability is real but slow to measure, what do you actually do about it when the incentives point the other way? abroszka33 states it most plainly: “The trillion dollar question is how you do this, if your employees do not care (they are optimising for salary & time spent not code quality) and you have no way of telling apart AI slop vs. good maintainable code.” skybrian answers with the individual workflow — keep reading the code, ask the agent to clean up what you understand — and kkapelon rejects it as scale-limited: “This only works in small projects. For large projects, it is close to impossible.” davedx says the answer is instructing the agents on what to maintain, with no evidence that instructions survive a large codebase. matthewmccc turns the institutional-knowledge argument into a question of its own — “which begs the question - will institutional knowledge not matter before long?” Across 232 comments nobody lands an enforcement mechanism, which is the same gap the essay leaves: the diagnosis is sharper than the prescription.

Where the thread pushes back

  • The strongest objection is that the piece is a snapshot dressed as a law. sobiolite: “We’ve had strong coding agents for less than a year. Anyone making such a definitive statement about how vibe-coded projects progress over time is basing it on guesswork, not evidence.” Tade0 adds the asymmetry the essay needs: “paying off tech debt requires a better model than creating it… there are people who will create tech debt no matter the tool.” kkapelon supplies the constraint nobody else mentions: context windows went 256k, then 1M, “and now it has stalled there”.
  • The reply that no-AI is a special case gets the strongest dissent of all: CharlieDigital — “Sad to say, but this is no different from human written code” — with ACCount39 pointing at Flash Player and the Bethesda engine as codebases “deep in decay long before AI was capable of contributing to them”. On that reading AI is not a new disease, just a faster route to one, “and without having to hire bargain” developers. npn draws the line differently: humans remember the intent behind a bad implementation, which is what makes it fixable later.
  • Others simply do not recognize the essay’s picture. smerrill2: “Code maintainability is not a problem when you don’t have to open a file and inspect how something works anymore. You use english to add to it. You sit on chairs everyday where you don’t give a shit how they were created.” mjr00 calls that an “unhinged junior dev … take”; cryptonym accepts the chair analogy and reverses it — “If you are as dumb with software as I am with chair making, you should refrain from building software for others”; iillexial adds the fact the analogy misses: “LLMs also suffer from a bad code. LLMs very quickly lose track of their own shit and start producing more bugs.”
  • And the genre critique is worth hearing once: hypfer found no new thought in it — “‘This is bad and you are bad’ requires people to not defend their reality through rationalization” — while Kuyawa is the living counterexample, “I haven’t coded since may 2026, not a single line”. ttul takes the logic to its end: “If you’re reading code, you’re probably doing it wrong… We are all senior software engineering managers now, with a fleet of cheap and ambitious young engineers doing all the authoring.”

The essay’s contribution is not the prediction — nobody, including the thread, can settle that yet. It is the reason the usual productivity numbers cannot see the problem: a reward signal has to fire this week, and architecture takes years to fail.

On reading comments as evidence: HN handles are pseudonymous, the site publishes no per-comment scores, and the order here follows HN’s own ranking rather than a vote. This is a slice of a 232-comment thread, not a consensus.