Mark Seemann’s blog has spent most of 2026 circling AI, and this post is him answering a reader’s letter in public, with permission, because he says his answers aren’t rigorous — “the situation is so uncertain that I can only answer to the best of my abilities.”

The letter is the part that travels. The reader has no formal CS background and, with LLMs, built a fairly large TypeScript system: APIs, PostgreSQL, LLM pipelines, research automation, multi-model workflows. It felt like magic until he tried to make it a product — fix one error with AI, another appears, then a part behaves in a way he doesn’t understand. His conclusion: “I may have built a system that is above my own level of understanding. When everything works, that gap is almost invisible. When it doesn’t, it becomes very real.”

Seemann’s own position is declared up front: he hasn’t decided on AI but leans toward disliking it, while working with it and finding it impressive — “It’s usually when it impresses me the most that I resent it maximally.” The essay is short on prescriptions and long on uncertainty, which is roughly the point.

What he does argue:

  • If he were starting a career today, he’d seriously consider carpentry, metalworking or gunsmithing — trades where hand-eye coordination still separates people from robots.
  • As an economist, he can’t imagine 30-40% unemployment among knowledge workers leaving the economy intact, and he’s sceptical of the “technology always creates new jobs” argument. New jobs did appear in past transitions, but “often not for those people who lost their jobs. Coal miners didn’t just become programmers overnight,” and the China-shock example created its jobs “just not in the Western world.”
  • On abstractions, the reassuring part: developers have always worked above layers they didn’t understand — web developers didn’t know compilers, compiler writers didn’t know chip design. The old rule of thumb was to understand the level directly below yours and the one above, which was enough to troubleshoot most problems.
  • On speed, the deflating part: LLMs make directed questions cheap, but he doubts human learning speeds up much, because “the bottleneck is hardly the teachers nor the materials, but how fast a human brain can absorb new knowledge.”
  • On his own practice: he doesn’t use LLMs for learning. “LLMs don’t hallucinate; they bullshit,” he writes, and he’ll only ask them falsifiable questions — “Can I make this Haskell expression more succinct?” — never “What should I learn next?”

The essay ends without a program, which leaves the thread to argue about whether one exists. The 120-comment thread on Hacker News supplies what the essay deliberately withholds.

What the thread adds

  • japhyr — says they wrote Python Crash Course and received “this exact same email this week.” That is another recipient of the letter, not independent corroboration of the reader’s project or a separate case. Their advice is explicit: “You have to intentionally build your understanding as you build your projects.” senko pushes back on the novelty: developers could already build MVPs without understanding TCP sockets or B-trees. The disagreement is over which details can safely remain hidden, not whether every developer must understand every layer.
  • agentultra — the blunt prescription this thread keeps circling: “you have to be able to program it yourself before you can build it with an LLM. Otherwise you have no way of judging the output.” Their advice is the old, slow route — “There’s no royal road to knowledge, skill, and learning.”
  • aethertap — describes a teaching experiment: keep a handmade project going without AI; specify data structures, algorithms and architecture when using a model; and write down debugging hypotheses before asking it to investigate. The crucial qualification is in the same comment: “We just started this so I don’t have much in the way of results yet”. This is a concrete proposed method, not evidence that the method produces independent programmers.
  • bborud — reports a secondhand operational anecdote about a friend’s company: “And suddenly nobody was able to do anything. Because nobody had actually read the code and had no idea how it worked.” They attribute the interruption to a Claude outage during deployment. The thread supplies no independent verification of that incident.
  • purpleflashing — supplies the beginner’s perspective that the published discussion asks for. They describe generating small Python extensions for Sphinx, struggling to extend them, and eventually rewriting code themselves: “When I program something poorly, I can at least explain what I did and what my idea was”. They explicitly say they have not measured time spent with and without LLMs. This is an account of maintenance and comprehension difficulties, not a productivity comparison or proof that beginners cannot learn with AI.
  • AnodicElegy — the thread’s substantive disagreement with the essay, aimed at the China-WTO analogy: US unemployment “peaked soon after, decreased to well below the point it had been at China’s entry,” which they read as support for replacement rather than displacement. wuisce defends the narrower point Seemann actually made — the new jobs didn’t go to the workers who lost theirs, which is why the Rust Belt and northern England were devastated.
  • js8 — argues that natural language is a worse substrate for maintaining programs: “Meanwhile, we already have automated programmer - it’s called a compiler.” jeremyjh disputes the framing: “LLMs do not execute natural language. Natural language describes a problem or request, and LLMs generate and test formal logic they predict will satisfy the request.” These are competing arguments about the workflow, not findings about how much understanding a maintainer needs.

Where the abstraction analogy breaks

In a reply to senko, aposm distinguishes a deliberately designed API from generated integration code: “The things that LLMs allow novices to skip nowadays aren’t designed with that in mind”. They use payments and authentication as examples where misunderstanding generated setup can have serious consequences. This sharpens the practical question: is the hidden detail behind an established interface, or is it an unexamined decision in code you are responsible for maintaining? It is a useful counterargument to the claim that the missing rung merely moves upward, not evidence that every generated integration is unsafe.

Where the thread splits, and what it keeps asking

The split is whether foundations can be learned while shipping, and it doesn’t resolve. agentultra and Barrin92 say no: the reader “outsourced the building of a product,” and you could “replace the word ‘model’ in the article with ‘guy I hired on fiver’ and there would be no difference.” japhyr and dack say yes, with discipline — build real things, then dig into the code with the model until you understand it, treating the bug you just hit as the curriculum. Trusteando raises a fair question about the format itself: a veteran who learned in the 1990s “can perhaps give you only one side of the coin,” and someone learning from scratch today would show the other. travthedev asks the version of it that never gets a clean answer: how much programming knowledge is enough before you can call yourself a solo developer?

Not everyone in the thread sees a crisis. asp_hornet reports the opposite experience — bugs caught earlier by AI review, more and better tests, faster shipping, less bikeshedding — and lolakutty gets four replies’ worth of argument from one line: “Sorry, programming is still fun. LLMs can’t change that.” And cortic quietly deflates the central confession: “I feel like that about a lot of code i did myself” — a few months or years is enough to forget your own system, AI or not.

A note on reading comments as evidence: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering here is HN’s own ranking, not a vote. This is a slice of the thread, and disagreements are quoted as disagreements.