HN Split 24 to 24 on 'Coding Is Not Solved', and Lobsters Barely Showed Up
The author of "Coding is NOT solved" called the Hacker News reaction overwhelmingly positive. We sorted 84 top-level comments and got 24 for, 24 against, while Lobsters gave the essay 1 point.
The WJS Desk
Oct 1, 2026 · 6 min read
Alex Ewerlöf's essay "Coding is NOT solved" went up on September 26, reached Hacker News two days later, and had 562 points and 539 comments when we read the thread tonight. The next day Ewerlöf added an update to the post saying the thread had brought "an overwhelmingly positive feedback (kinda unusual for that particular community)".
That is a claim we can check. We read all 85 top-level comments and sorted every one not written by the author. Then we went to Lobsters, where the same argument turned up this week in a different form, to see whether the two communities even agree on what the question is.
The argument, stated fairly
Ewerlöf's case is that "coding is solved" is a narrative pushed by people who sell tokens. His claim is that writing code was never the expensive part. Maintenance, reliability, security and the rest of what he calls non-functional requirements are, and "most software that requires hiring and paying software engineers has low risk tolerance". He adds that an AI cannot be held accountable, that LLMs are probabilistic, and he spends a long section on bugs in Anthropic's Claude Code as evidence of where the narrative leads.
The strongest opposing case, the one its holders would sign, is that the essay describes models from a year ago. On this view the old failure examples no longer reproduce, most paid software is nowhere near as critical as aviation, and accountability has always sat with the employer rather than the tool. Nobody in the thread seriously claimed software engineering is solved. The fight is over whether writing the code is.
We sorted 84 comments, and it is a tie
Of the 85 top-level comments, one was Ewerlöf's own. We put the other 84 into five buckets. Edge cases are a judgment call, so here are the buckets, and you can argue with them.
| Top-level position (84 comments) | Count |
|---|---|
| Backs the essay: coding is not solved, and the essay is right | 24 |
| Rejects the essay: coding is effectively solved, or the essay is out of date or self-promotion | 24 |
| Accepts the conclusion but attacks the arguments | 15 |
| Definitional: "coding is solved, software engineering is not" | 6 |
| Off-topic, jokes, style complaints, or genuinely undecided | 15 |
24 for, 24 against. Even if you count every "right conclusion, wrong reasons" comment as support, which is generous since most of them were explaining what was wrong with the essay, you get 39 of 84, under half. The two biggest subthreads split the same way. The largest, at 157 replies, opens with a rejection. The second, at 114, opens with support. "Overwhelmingly positive" describes the vote count on the submission better than it describes what people wrote under it.
The takes
The support side's most-replied comment came from askonomm:
"What I've found is that AI allows lazy and incompetent developers to be more lazy and more incompetent. This then has the effect that product quality suffers more, faster."
efficax started the thread's biggest argument by turning the essay's premise around. Reading code was never understanding it, they wrote, and LLMs can build fuzzers, property tests and full traces at a scale no human reviewer can:
"Reading the code does not mean you understand the code."
temp00345, who described 30 years of programming experience, put a depreciation schedule on the essay:
"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."
thesumofall went after the risk argument directly: "I think the author underestimates how boring and simple 90% of enterprise software is." argee, on the support side, named what they saw as the trick in the slogan itself: "'Coding Is Solved' should occur to you as a classic Motte & Bailey style argument." armchairhacker summed up the 15-comment middle bucket in one line: "Coding is not solved, but the author's arguments are wrong." And Marha01 asked for the thing neither side brought:
"If anyone claims that coding is solved or not solved with such conviction, I expect some hard data, like comparing the density of bugs in human written vs. AI code, and how it trends over time. This article is just vibes."
What the platforms disagreed about
On Lobsters, Ewerlöf's essay sank without a word. It had 5 points and no comments when we first looked tonight and 1 point an hour later, still with no comments. What Lobsters did discuss, on September 29, was a Communications of the ACM opinion piece, "AI Didn't Make Programming Easier. It Just Made It Differently Difficult": 26 points and 11 comments, filed under the site's vibecoding tag. CACM's page blocked our fetch, so we only quote the lines commenters quoted from it.
The difference is not which side won. It is that Lobsters barely engaged with the question at all. HN argued about whether the essay was right. Lobsters' two highest-scored comments, at 20 and 19 points, made fun of the essay's picture of the new workflow. adam_d_ruppe quoted the essay's line that the human becomes "less a conductor of keystrokes and more a shaper of intent" and replied:
"People keep saying things like 'i didn't get into programming to type' and im like 'how do you interface with your ai' and they're like 'typing' lol."
marginalia went further, calling voice interaction "a hilarious trainwreck waiting to happen" where people "are expected to listen to meandering claudian monologues". The one openly enthusiastic comment, from jackklika, called it "one of the best writeups on how agentic development feels for my brain". It scored 2.
The CACM essay had been on HN too, in July, with 166 points and 145 comments. There the top thread engaged with its central idea, that the hard part moves from recall to judgment, and bnfcl's reply was about who gets to build that judgment: "to evaluate if it makes sense, you first need experience writing the code." HN argues about AI coding on the merits, and splits down the middle. Lobsters treats it as a genre, and scores the jokes.
The best comments nobody engaged with
HN hides comment scores, so on that side we can only measure replies. The sharpest rebuttal in the thread got none. Sevii wrote:
"Most software engineers do not work on low risk tolerance code."
manny_rat made the same point separately, from 20 years at software companies where risk was never the concern, and also drew zero replies. If that premise falls, most of the essay's case falls with it, and nobody on the support side answered it.
On Lobsters, mwcampbell asked the question the CACM title invites, and it scored 1: "If the title is literally true, is there any good reason at all to bother with LLM-assisted programming, requiring us to learn new ways of doing things and possibly taking a step backward in the process, rather than just continuing to get better at the old way?" If AI coding is only differently difficult, the case for switching rests entirely on the "differently" being worth it, and neither essay makes that case with numbers.
Our read
The middle bucket is right, and it is also the bucket the author's update leaves out. Coding in the sense of producing working, reviewable changes to a system someone else designed is not solved: several commenters described models over-building a simple class, designing types badly, or producing a codebase where fixing one bug created ten more. But several of the essay's arguments are weak, and critics picked them off. Letter-counting examples tell you nothing about code. Accountability has always sat with the person who ships, whatever tool they used. And the risk-tolerance premise does not describe most of the industry.
Neither side brought a bug count. Until someone does, "solved" is a mood, not a measurement.
What would change our mind is Marha01's missing dataset: defect density in AI-written against human-written code, in the same codebase, tracked for a year. It is buildable. That nobody in 539 comments had it tells you where the argument really is.
Your turn
What does your team's production code actually tolerate? If a bug in the code you shipped last week would cost an afternoon rather than a lawsuit, does that change which side of this you are on? And for a debate where the loudest argument turned out not to be about what the feature blocked, read our test of what Claude Code's plan mode actually prevents.
