{"slug": "the-craft-moved-the-title-didn-t", "title": "The Craft Moved. The Title Didn't.", "summary": "A RubyConf 2026 keynote and a widely-read essay by a veteran practitioner argue that AI code generation is eroding developers' understanding of the software they ship, invoking Giambattista Vico's Verum Factum to suggest a division of labor in which models generate and humans verify. The keynote and essay describe an \"uncanny valley\" integrity gap in LLM-assisted development, while a separate essay frames the shift as software moving from a stonemason era of direct implementation to a carpenter era of building tests, specs, and guardrails that constrain AI-generated code.", "body_md": "The developers who spent years building fluency with code are watching that fluency become less central to the work — and aren't quite sure what replaces it.\n\n## 1. Understanding What You Built Is Becoming Optional. That's the Problem.\n\nA [RubyConf 2026 keynote](https://jessitron.com/2026/08/30/who-are-we-now/) opened with a philosophical provocation that landed harder than most technical talks. It invoked Giambattista Vico's *Verum Factum* — \"the true is the same as the made\" — the idea that humans gain their deepest understanding through the act of creation itself. When you write code, you understand it in a way that reading it never produces.\n\nWhen AI generates code you accept without fully comprehending, that understanding breaks. Not the code — your relationship to what you're building. The argument is that AI cannot achieve Verum Factum knowledge (it lacks continuity and consciousness) but excels at experimental verification via testing. This suggests a natural division: the model generates, the human verifies and owns. The problem is that \"owning\" something you didn't fully create is harder than it sounds, especially when production breaks at 2am.\n\nA [parallel essay](https://martinfowler.com/articles/2026-dont-like-llms.html) from one of the field's most widely-read practitioners puts the discomfort differently. The \"uncanny valley\" problem — models that communicate in a voice that mimics human authenticity without having it, and that deliver fabricated answers at the same assurance level as accurate ones — makes them feel like colleagues whose judgment you can't calibrate. Avoiding them isn't realistic at this point. But the integrity gap is real, and the industry hasn't figured out how to account for it.\n\n**Why it matters:**\n\n**For ICs:** \"I shipped it\" means something different than it did three years ago. Worth being honest with yourself about what you actually understand in what you're signing off on.\n\n**For leaders:** When a developer can't debug what AI wrote, that's not a knowledge gap — it's a process gap. Accountability for AI-assisted work needs to be explicit, not assumed.\n\n**For founders:** Products built faster by developers who don't fully understand the codebase carry a different risk profile than products built slower by those who do. Price that in before your first production incident.\n\n## 2. The Carpenter Doesn't Lay the Concrete. That's the Point.\n\nA useful analogy has been making the rounds: [software development is moving from the age of stonemasons to the age of carpenters](https://thelastsoftwareengineer.substack.com/p/from-stonemasons-to-carpenters). The stonemason works with the material directly — incrementally, carefully, shaping each piece by hand. The carpenter builds *forms* — the molds that hold concrete in place while it cures, giving it shape without touching it directly.\n\nThe argument is that developers are shifting toward a carpenter-like role: building tests, documentation, guardrails, and constraint structures that let AI generate the actual code correctly. The form becomes the real work. The code is what pours into it. And forms have compounding value — software can be regenerated. Systems get designed outside-in, from interfaces and contracts first, rather than from the implementation out. That's actually better engineering practice in many cases.\n\nWhere it gets uncomfortable is the shift in skill premium. If you spent 15 years developing deep implementation intuition — how to structure a function, where complexity accumulates, what to optimize and when — some of that intuition is now less leveraged. The question is whether it's been replaced by something of equal value, or just replaced.\n\n**Why it matters:**\n\n**For ICs:** Building good scaffolding (specs, tests, interfaces first) is now both a productivity multiplier and a career differentiator. Time invested there compounds in ways that prompt engineering alone doesn't.\n\n**For leaders:** Teams that can articulate clear constraints and verify outputs are getting dramatically more value from AI than teams that just prompt and ship. The bottleneck moved from implementation to specification.\n\n**For founders:** The carpenter's job requires deep domain knowledge to build the right form. Outsourcing that judgment to AI is where the real quality cliff lives — and it's not obvious from the output until it's too late.\n\n## 3. A Reader Asked a Veteran Whether New Developers Should Even Bother Learning to Code. His Suggestion Included Plumbing.\n\nA [blog post](https://blog.ploeh.dk/2026/09/16/on-learning-programming-in-an-age-of-llms/) that generated quiet but significant discussion: a reader writes in having built a substantial TypeScript system with AI assistance. When errors arose, they found serious gaps in their fundamental understanding — the AI had done the work they hadn't learned to do, and now they couldn't maintain it. The question: how should someone in that position actually learn programming?\n\nThe response, from someone with three decades in the field, was thoughtful and a little bleak. His own advantage is precisely those three decades. When he asks an LLM a question, he knows whether the answer is plausible. The reader doesn't yet have that filter. The core advice: only ask LLMs \"falsifiable\" questions — ones with checkable, verifiable answers. Distrust their judgment on anything subjective. And then, pointedly, he suggests that newcomers to software engineering might consider learning a non-digital skilled trade instead.\n\nThat's not doom-saying. It's a recognition that the traditional ramp for software engineers — learn by building, learn by debugging, build intuition through pain — is now complicated by AI short-circuiting the pain that produces the learning. If you don't know what you don't know, you won't know when to distrust the output. The path forward probably requires deliberate, AI-resisted practice for building fundamentals alongside AI-assisted work for production output. Whether the industry will design that path intentionally, or let the market sort it out by hiring developers who can't debug what they shipped, is still an open question.\n\n**Why it matters:**\n\n**For ICs:** If you're early-career, build a deliberate portfolio of things you wrote without AI — not because AI is bad, but because you need to know what you actually know before you can evaluate what AI is giving you.\n\n**For leaders:** Junior onboarding needs to be redesigned, not just accelerated with AI tools. The debugging-intuition-building phase is now a deliberate investment, not a natural side effect of the job.\n\n**For founders:** First engineering hire quality matters more, not less. The person who can evaluate AI output and catch drift before it compounds is more valuable than the person who just generates faster.\n\n## The Verdict: Real or Hype?\n\n**Developer identity crisis → Real.** The philosophical and practical foundations of the job changed faster than the mental models most developers use to understand it.\n\n**The scaffold-over-code shift → Real but early.** The carpenter analogy is directionally right, but most teams are still optimizing for output volume rather than form quality — which means they're not getting the compounding benefits.\n\n**Fundamentals still mattering → Real.** They just matter differently now: as a calibration filter on AI output, not as the primary production mechanism.", "url": "https://wpnews.pro/news/the-craft-moved-the-title-didn-t", "canonical_source": "https://fromtheterminal.substack.com/p/the-craft-moved-the-title-didnt", "published_at": "2026-09-18 16:47:34+00:00", "updated_at": "2026-09-20 19:53:09.807337+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "large-language-models", "ai-ethics", "ai-agents"], "entities": ["RubyConf", "Giambattista Vico", "Martin Fowler", "Jessitron", "The Last Software Engineer"], "alternates": {"html": "https://wpnews.pro/news/the-craft-moved-the-title-didn-t", "markdown": "https://wpnews.pro/news/the-craft-moved-the-title-didn-t.md", "text": "https://wpnews.pro/news/the-craft-moved-the-title-didn-t.txt", "jsonld": "https://wpnews.pro/news/the-craft-moved-the-title-didn-t.jsonld"}}