Back to Explore
NewsVibeFix 编辑部Updated Oct 20, 2026

'Programming Is Dead' or 'Still OK to Love It'? HN's Great Debate on the Meaning of Programming in the AI Era

An October 8 programming obituary, an October 17 defense of loving code, and an October 19 Ask HN thread with 610 comments — three texts forming the full spectrum of mourner, lover, and working stiff. Verbatim quotes and analysis on the vibe coder identity question: whoever holds the design holds the identity.

A late-night coding desk: hands typing on a keyboard, code glowing on the screens

In the second and third weeks of October 2026, Hacker News hosted an unusual grand debate — not about a model or a launch, but about a more fundamental question: now that AI writes code, why do humans still program?

The debate unfolded across three posts forming a complete spectrum: on October 8, the independent blog dumbmatter published My obituary for programming, writing an obituary for "programming" as a profession; on October 17, chriskiehl published It's still OK to enjoy programming, a defense of love; on October 19, an Ask HN thread — How to deal with shipping AI-written code you don't understand? — drew 610 comments and dragged the debate back to earth: never mind the meaning of it all, the code ships tomorrow, what do we do?

The three map neatly onto the vibe coder community's triple identity anxiety: the mourner, the lover, the working stiff. This article lays out each side's own words — no paraphrase, no dilution — because the value of this debate isn't in its conclusion, but in how beautifully those original words were said.

The obituary camp: dumbmatter writes programming's eulogy

dumbmatter opens with a confession: he was very slow to use AI coding agents. "It seems like a lot of programmers never actually liked programming and are thrilled to have a machine do it for them." But not him — "But I like programming! That's the fun part!"

Note how important this setup is: dumbmatter isn't a sore loser whose job got automated, nor an armchair critic who's never touched an agent. He's someone who deeply loves programming, adopted AI late, was won over by it, and then felt afraid. That tearing feeling of "I love it, but I'm betraying it" is the emotional foundation of the whole obituary — a eulogist must once have loved deeply, or the eulogy doesn't hold. Had he always hated programming, this would be a polemic, not an obituary.

His business (zengm.com) is having one of its best years ever; work isn't a grind, so he felt entitled to ask: since I enjoy it, why not keep writing code by hand? He wasn't blind to what was happening around him either: "A lot of slop and hype, but a lot of real stuff too." Engineers he'd respected for years saying they no longer write code. Non-programmers accomplishing things previously far beyond their grasp.

Then he finally tried an agent. The three questions that follow are the finest passage in the piece:

"I can just give it a bug report or an error log entry, and almost instantly it pinpoints the issue and fixes it?"

"I can tell it to try making my code faster, and suddenly it runs 2x or 3x as fast?"

"I can kindly ask it to do that big refactoring I've been putting off for years, and it just does it?"

"But if the AI can refactor my code so easily, did it even matter?"

Note the cruelty of this turn: he's not frightened by the AI's power, he's stung by its ease — if something can be done effortlessly, what was its value ever built on? Was it built on "difficulty"? And once difficulty is gone, what meaning remains?

Then he begins the eulogy proper, recalling what programming used to be:

"Programming turned into one of the greatest jobs you could imagine. You got paid to work on tricky little logic puzzles. The trickier the puzzle, the more you got paid."

"We have these incredible machines that can do absurdly complex calculations for us, but only if we are clever enough to give them the exact right instructions... It was a real life superpower."

"What a time to be a nerd. Money, status, power." Then the pen turns, and the eulogy reaches its climax:

"What do we have now? It's no longer solving little logic puzzles. More like being plugged into the Matrix, gaining new abilities without truly understanding, accomplishing great things with little effort."

"But if the great thing can be accomplished with little effort, is it really so great? Does any of it matter? Just as the Matrix is not reality, vibecoding is not programming."

He closes by admitting his own contradiction: "And I like programming, right? Then why more and more do I reach for the agent before the text editor?" — the eulogist himself uses the very thing he's eulogizing about. That self-referential honesty is the obituary's greatest strength.

One easily missed brutal line sits in the middle: "It's addictive and meaningless." Addiction and meaninglessness coexisting — not a contradiction for effect, but a precise clinical description. What's addictive is the dopamine (instant fixes, immediate feedback); what's meaningless is the sense of worth (it's too easy — too easy to need me). dumbmatter unwittingly delivers the most accurate psychological diagnosis of the vibe-coding era: our era's alienation isn't "labor is too hard," it's "achievement is too cheap." The old alienation was the assembly-line worker not knowing what they were building; the new alienation is knowing everything, accomplishing everything, while the exchange rate of accomplishment collapses.

The final lines deserve memorization:

"It's addictive and meaningless. It's a good friend, a trusted colleague, a slave."

"It will obsolete us. Us programmers now, us humans next?"

"We are truly in The Age of Wonders and Terrors."

My take: dumbmatter isn't mourning "programming" itself — he ends by asking himself why he can't put the agent down. He's mourning the era of programming as a privileged profession: solving puzzles for high pay, wielding a superpower ordinary people lacked, holding the authority to decide what was possible. AI didn't kill the joy of programming; it killed programming's scarcity — and scarcity was exactly what the golden age's money, status, and power were built on. This obituary's true subject is the programmer's priestly-caste status.

The defense camp: chriskiehl, "work is not life"

On October 17, chriskiehl's response fit in a single headline: It's still OK to enjoy programming. The verdict lands in the opening:

"Yes, at work, where you are paid to produce value for a business, the economics of purely hand-written code have changed. But that's work. Work is not life."

"The loudest voices on the internet are the saddest and most infectious."

This is the sharpest cut in the whole debate: separating "work" from "life." dumbmatter's obituary is sad because he welded "programming" to "profession"; chriskiehl says the welded part (work's economics) has indeed changed, but the "life" part is nobody's to take.

He also diagnoses how sadness spreads: "the more of this doom stream you consume, the more it starts to infect you... But this disappears as soon as you disconnect." — "programming is dead" is first an information-feed mood, not a factual judgment. The "everyone is mourning" you scroll past in your timeline and the joy you genuinely feel in front of your editor can be two entirely unrelated things. chriskiehl's advice is simple and blunt: disconnect, write code, the joy comes back.

Then his examples, written with great charm: he still hand-writes code on weekends to learn game programming — "My current level of sophistication is a buggy Breakout clone with terrible collision detection." "I write it by hand because I enjoy it. I struggle with problems because solving them makes me happy. It doesn't bother me that Claude could one-shot it, because that's not the point."

Even better is the second example: one weekend he spent exploring how far he could push type safety in Java using ideas from dependently typed languages like Agda — "There is no point to this." A few weekends before that: recursion schemes. "Technically, this was not fun. I spent hours of banging my head against a wall." Yet it was worth it: "I do know that many of the most beautiful ideas in programming only become clear to me after years of baking in my mind."

The closing verdict hits hard:

"It's OK to enjoy things. Doing so requires no economic justification."

This sentence deserves to be chewed over three times. "Requires no economic justification" — the subtext: our era's greatest spiritual pollution is the demand that everything first answer "what's it for." Learning Agda is useless, banging your head on recursion schemes is useless, hand-writing Breakout is useless — but chriskiehl proves from experience that "useless" is precisely love's litmus test: useful things, AI will do better than you sooner or later; useless things are the part that makes you you. dumbmatter's sadness comes, in a sense, from being too used to measuring programming by "usefulness" — when AI made all usefulness cheap, he felt meaning collapse. chriskiehl says: then stop measuring by usefulness. That's not cope; that's cutting the problem off at the root.

But the finest stroke is footnote [2] — a seemingly casual confession that actually dismantles the debate's binary:

"I also have a blast vibe-coding. I've got a suite of apps for which I've never looked at a line of code. I suspect doing so would horrify me. 'Programming' this way is also fun. Often extremely so. But in its own unique way."

My take: this footnote is the essay's true thesis. chriskiehl is no anti-AI hand-writing fundamentalist — he hand-writes Breakout on weekends and vibe-codes an entire suite of apps. His position isn't "only hand-writing counts," it's "both joys are joys; neither gets to excommunicate the other." dumbmatter says "vibecoding is not programming"; chriskiehl's footnote answers: true, it's not that kind of programming, but it is fun in its own unique way — the word "programming" has already split open. The obituary camp holds vigil for the old meaning; the defense camp registers the new meaning. That, I believe, is this debate's deepest layer.

Three camps in the HN programming-meaning debate: the obituary camp, the defense camp, and the pragmatists, with core arguments and verbatim quotes

The pragmatist camp: Ask HN, "the code ships tomorrow"

The October 19 Ask HN thread yanked the debate from the clouds back to the ground. The post quotes a Meta engineer's LinkedIn post:

"I'm an engineer at Meta and I never felt this uncomfortable doing my job. I'm writing code these days and it all feels like a black box... You understand the high level, but not every detail. And maybe this is becoming the new standard. It goes against every instinct of being a software engineer."

"Now I'm trying to figure out how much I need to understand before I'm comfortable moving forward. Are other engineers feeling this too?"

Among the 610 comments (at posting time), the top answer came from bitwizeshift — the pragmatist camp's standard answer:

"I don't let the LLM design the code at all, I let it implement a design I have created... I take the time to create the full hierarchy of abstractions and actors that I want my code to do. I decide, at the UML level, how abstractions will sit and interact — and then I make the LLM implement those gaps."

"I've found that LLMs are HORRIBLE at writing decent abstractions... It will always get the job done, but it will often be unmaintainable."

Humans own the design; AI owns the implementation — a sentence every vibe coder should print and tape to their monitor. It echoes chriskiehl's footnote: the joy of vibe-coding can stay, but "design," the part where engineering judgment lives, must not be outsourced.

One small argument in the comments deserves a close read. fasterik wondered: "I wonder if the people having issues are primarily junior developers who have never seen how real software is built." swatcoder's reply cut deep: "Most people in the industry right now, even at FAANG and even among people carrying 'senior' titles... have spent the last decade pulling tickets off JIRA and pasting least-change-possible patches." — seniors may be no luckier at reading AI code. A decade of ticket culture that changed code without designing it had already hollowed out many people's design muscles; AI just tore off the fig leaf. That exchange explains why bitwizeshift's "design first" sounds like common sense but works like a luxury.

The comments hold more quotable practitioner wisdom. ChrisMarshallNY: "Testing. Lots and lots of testing... I don't find coding errors, but I do find implementation errors... Nobody's perfect. Trust; but verify." — note the distinction: coding errors (written wrong) vs. implementation errors (built wrong) are two different things, and in the AI era the latter is the main battlefield.

Others poured cold water. michaelt noted that "lots and lots of automated testing invites lots and lots of lines of code — making code reviews even more challenging." onion2k shared a working solution: turning project guardrails into a reusable skills repository, aiming for "enough confidence to say this change didn't break anything." SimianSci's retort was sharp: "we've made a whole bunch of new work around verification and testing of said stuff? What have we gained aside from shifting where time and effort is spent?" onion2k's answer deserves to be the pragmatist motto: "The verification is what we always wanted but never had time for."

And one comment you can't laugh at. birdsongs: "I just approve PRs, because I have to. I don't know what else to do." — when review becomes a rubber stamp, "understanding" is already dead. The darkest moment in the whole debate, and the future vibe coders should fear most.

Notably, the pragmatists have no single "right answer," only ways of living. Some lead with design (bitwizeshift), some with test barrages (ChrisMarshallNY), some with guardrail engineering (onion2k), some with the ostrich strategy of only watching their own code (birdsongs, wry smile). The Ask HN title asks "How to deal with," not "How to solve" — coping admits the problem is here to stay; solving fantasizes it will vanish. 610 comments produced no winner, but they produced consensus: in the black-box era, an engineer's dignity lies not in "understanding everything" but in "having a backstop." Tests, guardrails, design, small steps — not substitutes for understanding, but scaffolding for it.

Why HN, why now

This debate happening on HN is no accident. HN has the highest "identity density" in programmer culture — here, "programmer" isn't just a job, it's a self-identity. So when AI started mass-producing code, the first to feel existential vertigo were precisely HN's people. dumbmatter's obituary, chriskiehl's defense, and the Ask HN survival thread arriving within twelve days shows this isn't one person's mood — it's a whole tribe's collective symptom.

The propagation chain matters too: Simon Willison (noted tech observer, Django co-creator) shared the obituary camp's piece on October 19 (per our scout). When an observer of Willison's stature starts sharing a "programming obituary," the question of programming's meaning has graduated from forum grumbling to industry topic. And chriskiehl's rebuttal hitting #6 on HN's past-7-days board (644–686 points, 260–533 comments, scout snapshot) shows the defense camp is no niche consolation — as many people want to defend programming as want to bury it.

The timing is equally telling: October 2026, nearly four years after ChatGPT detonated vibe coding, "AI writes code" long since turned from novelty into routine. The debate comes after routinization, not amid shock — people aren't panicking, they're digesting. Digestion-era debates are far more honest than shock-era ones: no exaggerated doomsday prophecy, no cheap techno-optimism — just the genuine confusion of people who still have to show up for work tomorrow.

My take: the three camps aren't arguing about the same thing

Laid side by side, the three pieces reveal an interesting structure: they aren't actually arguing about the same thing. dumbmatter mourns programming as a profession — the era that traded scarcity for money, status, and power. chriskiehl defends programming as a life — hand-writing Breakout on weekends, joy that needs no defense. The Ask HN thread discusses programming as engineering — the code ships tomorrow; black box or not, you have to hold the line.

Split into three layers and the conclusion is clear: programming isn't dead; what's dead is the monopoly of "only humans can program" and the equation "programming naturally equals a high-paying profession." dumbmatter's sadness is real, but it's the sadness of a priestly caste losing its monopoly; chriskiehl's joy is real too, because joy never needed a monopoly's endorsement.

One layer deeper: why did this debate erupt in October 2026? Because this is the year the term "vibe coder" completed its journey from joke to identity. In 2025, "vibe coding" was said with a smirk — "you call that programming?" In 2026, vibe coder became a self-adopted label, and a community started asking seriously: "who are we?" dumbmatter's obituary is, in a sense, the old identity-holders' discomfort — "vibecoding is not programming" with the subtext "then you don't count as programmers." chriskiehl's footnote is the new identity's reconciliation — both joys are joys; nobody gets their programmer card revoked. And the Ask HN's 610 comments are the new identity's first real-world "practitioner's survival manual." One debate, three texts, the complete arc of an identity crisis: denial (this isn't programming) → reconciliation (both are fun) → rebuilding (so how do we work now).

For vibe coders, the debate's real identity question isn't "who's right, dumbmatter or chriskiehl" — it's: when you say "I'm a vibe coder," which layer are you identifying with? "Someone who has AI write code for them" (tool user), or "someone who understands systems and owns the design" (engineer)? bitwizeshift's answer already draws the watershed: whoever holds the design holds the identity. The day you let the LLM design for you, you graduate from "engineer using AI" to "operator used by AI" — and birdsongs' "I just approve PRs, because I have to" is the operator's epitaph.

Three practical suggestions for vibe coders, synthesizing all three camps:

  • Design first, outsource implementation (pragmatists): before writing a prompt, fix the module boundaries, interfaces, and data flow on paper (or a whiteboard). LLMs are great at fill-in-the-blank, terrible at writing the exam.
  • Replace line-by-line understanding with tests and verification (pragmatists): accept that you can't read every line — but move the defensive line forward: write tests before letting AI implement, keep diffs small, limit blast radius with feature flags. Tape ChrisMarshallNY's "Trust; but verify" to the wall.
  • Keep a hand-written plot of land (the defense camp): reserve some time each week for "useless" hand-written code — Breakout clones, recursion schemes, whatever. chriskiehl is right that this joy needs no defense; but I'll add: it's not just joy, it's the gym for your "design rights." People who stop hand-writing will eventually lose the ability to design at all — muscles atrophy.

Back to dumbmatter's harshest line: "Just as the Matrix is not reality, vibecoding is not programming." With chriskiehl's footnote in mind, I'd finish the sentence: vibe coding isn't that kind of programming — but that kind was never all programming was. Programming was once a craft for making a living, a puzzle game, a lens for understanding the world — AI took the first layer; it can't take the other two unless you hand them over. And whether to hand them over has always been your call. That, I think, is the true weight of "it's still OK."

A final word for VibeFix readers: next time you're about to tell an agent "write me an xxx," pause three seconds and ask yourself one question — is the "why" of this design in my head? If yes, let it write; you're an engineer. If no, don't rush the prompt — get the "why" straight first, and you're still an engineer. What dumbmatter fears, what chriskiehl loves, and what Ask HN agonizes over all come down to those three seconds. Programming's meaning was never on the keyboard. It's in those three seconds.

Further reading: we previously published a hands-on guide, Vibe Coding Is Turning into Doomcoding (slug: vibe-coding-doomcoding-escape-guide), on escaping death loops when AI-written code collapses — that piece is the "how," this one is the "why"; they read best together.

Transparency notes

  • All three originals (dumbmatter Oct 8, chriskiehl Oct 17, Ask HN Oct 19) were opened and read in full by the author; quotes are verbatim from the originals, Chinese renderings are the author's translations.
  • Comment counts (Ask HN: 610), HN rankings and points (chriskiehl's piece at #6 on the past-7-days board, 644–686 points, 260–533 comments; Ask HN at 474 points) are scout snapshots from October 20, 2026 and will change; the Ask HN comment list I opened matches that magnitude.
  • Simon Willison sharing the obituary piece on Oct 19 was confirmed by our scout; I did not open his blog to verify, and it appears here as background only.
  • The "three camps" / "three layers of programming" framing is the author's analysis, marked as "My take"; practical suggestions synthesize all three sides.
  • The quoted LinkedIn post (Meta engineer Ali Hamie) is cited via the Ask HN thread's original text; I did not open the LinkedIn page (login required).
Views 0Comments 0

Comments (0)

ME
0/1000
Loading comments...

Sources

Browse projectsPublish your project

Related articles

Harness² two-level recursion architecture: task-level Propose–Probe–Compose loop and harnessing-level improvement-harness feedback
News
Google Research Open-Sources Harness²: Freeze the Model, Let the Harness Evolve

Google Research open-sources Harness², a recursive agent-harnessing framework: model weights stay frozen while two recursion levels — task-level Propose–Probe–Compose and harnessing-level experience accumulation — optimize the harness itself. Eight editable components are copy-ready homework for vibe coders; official results claim up to +11.5 points (team self-tested*), and the local demo runs with zero model credentials.

Industry TrendsAI AgentOpen Source
Official MemT-1.0 native memory architecture diagram: Native Memory Block running alongside backbone attention with Local and Hyper Memory Blocks
News
MemTensor Open-Sources MemT-1.0: The Memory-Native Model That Remembers in Its Forward Pass

Chinese team MemTensor releases and open-sources MemT-1.0, a memory-native model family that builds persistent, updatable memory into the forward pass: GDN-2 token-level updates, Mixture-of-Storage scaling, Nano (36B) and Flash (288B) variants. The team candidly admits textual-memory systems still lead on detailed retrieval; licensing is PolyForm Noncommercial — free to explore, not for commercial use.

Model UpdatesAI AgentOpen Source
A blue-lit data center corridor lined with server racks on both sides
News
DeepSeek Open-Sources DeepInfer: Production Inference Stack Launches on NVIDIA and Ascend Alike

On October 20, DeepSeek open-sourced DeepInfer (Apache-2.0), the inference framework behind its production services, launching with NVIDIA SM100 and Huawei Ascend 950 support — just 18 months after it said it would not open-source the full engine. This piece breaks down what was released, what was held back, and why inference cost is agent cost.

Industry TrendsBackend EngineeringModel Updates