Charity Majors: code is now disposable, so engineering discipline matters more, not less

The argument: code went from treasured to regenerable overnight

Charity Majors' essay starts from one economic claim: in 2025 the cost of producing code collapsed. Generating it went from hard, slow, and expensive to effectively free and instant. Lines of code, she writes, went from being treasured, reused, and carefully curated to disposable and regenerable, practically overnight.

That inversion is the whole argument. Borrowing Chad Fowler's framing of "Phoenix" architectures, she recasts code as a materialized view of understanding — useful while current, disposable when stale. The historical parallel is the 2013-era shift from hand-tuned servers to immutable infrastructure: mutability creates drift, regenerability creates confidence. If you can rebuild a server from a spec, you stop fearing its deletion. Apply the same logic to application code.

The sharp line, again from Fowler: code becomes precious when it is the only place knowledge lives. Move that knowledge into specs, behavioral tests, and production observability, and the code underneath becomes replaceable without anxiety. So the discipline AI demands is not less review and more vibes — it's the opposite. Formal specs, real test coverage, and observability become the durable artifacts, and humans should stop trying to be the quality gate at the moment they're worst at it: reading and validating output.

"This time it's different" — and why some readers stopped trusting that phrase

The essay opens by declaring that the "AI code is slop" position, mainstream for most of 2025, was answered decisively last November. That framing drew the loudest pushback in the thread.

"It's easy to forget that people said this exact thing about every model after GPT 3.5. … 'You are prompting it wrong' becomes 'you are using Gemini, but you should use Claude' which then becomes 'well, all of your criticism is now irrelevant, because everything is fixed in this new version'." — a commenter who lays out the moving-goalposts pattern step by step

Others found the piece itself thin. "Each individual paragraph was fine, but the whole thing together was meandering and dare I say pointless," one reader wrote — a complaint echoed by the user who reduced it to a one-liner: "using artificial intelligence requires more expertise than not using it?"

The agreement came with a darker observation

The people who took the thesis seriously mostly did so from their own keyboards. Simon Willison, creator of Datasette and co-creator of Django, zeroed in on the economics claim:

"So much of my intuition about software development is based on 25 years of accumulated experience on how long it will take to write different bits of code. Should I add validation for this one edge-case…"

The whole calculus of "is this worth the time" breaks when the time goes to zero. A working engineer who now does what he calls documentation-driven development put a number on it:

"I am committing code that is better written, better documented, easier to reason about and maintain … and I'm doing it for 1/4 the price, at 4x the speed. But it's not vibe coding. Discipline is critical." — an engineer who describes himself as a former senior lead

But the most uncomfortable counterpoint reframed the whole productivity story as a detection problem.

"It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. … Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents … with perfect formatting and at least superficial plausibility." — an engineer describing the pressure from the C-suite to maximize AI use

And the founder of a migration-tooling startup named the day-to-day cost Majors' optimism glosses over:

"Reading AI code all day is agonizing. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable." — the founder of Tern

The split is really about where knowledge lives

Strip away the temperature and the thread and the essay agree on more than they disagree. Majors says the durable thing is no longer the code; the skeptics say that's exactly why teams full of plausible-looking output are now harder to audit, not easier. Both are describing the same shift — knowledge migrating out of the source files — and both land on the same prescription: if code is cheap, the rigor has to move upstream to specs, tests, and the humans who can actually tell whether the output is right. The disagreement is whether most organizations will pay for that rigor, or just enjoy the speed and skip it.