The short version
Caron argues that AI is unbundling the developer role the way word processors unbundled the typing pool: the typist role vanished in the 1980s and 90s, but typing never went away. Companies firing engineers by the thousands are, in his view, confusing a role with the bundle of tasks inside it. AI replaces the tasks; it does not replace the function that coordinates them.
The engineer's job shifts from doing the work to governing it: keeping AI-produced code maintainable so the best people don't end up as "slop janitors," managing outcomes and risk, and intervening at the inflection points where agents need redirecting. In the Q&A he goes further and says spec-driven development never worked, calls it waterfall reborn, and would "bet my company" that going back in that direction fails. The idea worth stealing: figure out where in your workflow a human decision actually changes the outcome, and own those points, because that is the part of the role that survives.
Key takeaways
A role is not its task list
If you define your work as a bundle of tasks, AI can replace each task one by one. What it can't replace is the function those tasks served inside the workflow. The whole talk hangs on keeping those two things separate.
The typing pool is the template
Managers once handwrote letters and sent them to a room of typists for typing, corrections, and retyping. Word processors absorbed every task in that loop, so the typist role ceased to exist, but typing just moved into everyone's hands inside a new workflow. Caron says the same shift is already underway for developers, and tells on himself: a colleague asked him about software he'd bragged about writing, "Did you write it, or did Claude write it?" His answer: the AI could never have come up with the idea (a proxy between client and database), because it lacks his business sense.
Mass layoffs read the analogy wrong
He points at the reported 8,000 cuts at Meta and 12,000 at Amazon as leadership believing an AI agent can take over the role of a developer, when it only takes over some of the tasks. Counterintuitively, he expects AI to increase the number of people working in the software development life cycle, though "those will not be Rust developers or Go developers or, God help us, React developers."
Bolting AI onto existing workflows produces slop faster
Task-level change means making Claude or Copilot write code faster inside the process you already have; he notes most vendor talks at the conference still pitch exactly that. His line: you can't stuff the square peg of AI software development into the round hole of Jira. System-level change alters who creates value, already visible in non-engineers building products over a weekend with Lovable. Those people can build, but they're badly placed to make the decisions. The best engineers are well placed, and that's where the role goes.
The surviving role is governance
Overseeing maintainable code (David Farley's definition: code that's easy to change), because AI often produces the opposite and turns the best engineers into slop janitors. Managing outcomes, because every hallucination story ends with the AI doing something no human would have thought to do. Controlling change, meaning no runaway agents. And managing risk: if you don't design the workflow up front, someone will eventually ask an agent to "identify all the PII in my database," at which point the PII sits in the model's context and the protection is defeated.
Developer and product owner converge
Product owners get more involved in creating code by working at the inflection points; developers have to get much better at understanding the business reason the software exists. Donella Meadows' "leverage points" turn into the actual job description: find the places in the new workflows where human intervention changes the outcome, and own them.
Q&A: spec-driven development is waterfall reborn
Asked about agile versus spec-driven development, he answers that spec-driven development never worked at all: defining everything up front was called waterfall, it didn't work when humans typed, and he doubts it works when AI types. "I would actually bet my company on it." He mentions his friend Adam Tornhill just blogged on the topic.
Caveats
The talk is a position piece. It offers no experiments or metrics, and the Meta and Amazon layoff figures are the speaker's shorthand for news reports, unsourced in the talk itself. Caron runs a database tooling company, and his recurring example (a proxy between client and database that keeps PII away from both engineers and agents) is close to what his company sells. The spec-driven verdict is a single Q&A answer rather than a worked comparison, and talks we've shared here before (Martinelli's spec-driven lessons, the spec-in-the-loop talk) argue the opposite corner. His frame draws on Donella Meadows' "Thinking in Systems" and Sangeet Paul Choudary's 2025 book "Reshuffle."
Why it matters for Teams AI builders
Most of what this community discusses is task-level: better prompts, better harnesses, faster loops. This talk argues the task level is exactly what commoditizes first, and it suggests a usable exercise: write down your own workflow, mark the points where a human decision actually redirects the outcome, and check how much of your week happens at those points versus in the parts an agent already handles. The PII example also generalizes into something immediately actionable: any data your agent is asked to find or summarize ends up in its context, so "protect the data by asking the agent to locate it" is a self-defeating workflow, and it has to be designed around before you give an agent database access.
Join the discussion
Caron would bet his company that spec-driven development doesn't work, while two earlier talks we shared here argue specs are precisely how you keep agents on the rails. Where do you land after your last few projects: did writing the spec up front pay off, or did it rot into waterfall the moment the code diverged from it?