Dex Horthy (HumanLayer) walks through why he reversed his own advice on "review the plan, not the code." His team ran that experiment for four or five months, ended up with an unusable six-service codebase the model had architected, and rebuilt the product from scratch, with his co-founder hand-typing the new data architecture in VS Code. His current position: models have gotten much better at many things but not at writing maintainable code, because maintainability has no fast oracle to train against, so humans still need to read code while continuously investing in the skills, detectors and feedback loops that make the "factory" better.
- Writing plan files in mid-2025 was valuable mostly as a trick to keep a model working longer and to compact intent so you could resume from a clean context window, back when results degraded past roughly 100k tokens (the "dumb zone").
- Inspired by Sean Grove's "the spec is the new code" talk, Dex's team tried reviewing only plans, not code; the plans contained inline diffs, teams ended up reviewing nearly the same code twice, and after 4-5 months the codebase became unmaintainable.
- Letting the model own system architecture produced a sprawling stack of six services (desktop app to Rust socket to Go daemon to Claude Code sessions to MCP servers to SQLite), which forced a full rebuild by hand.
- Dex frames planning as an "expected pain" calculation: don't argue with a model over button color, but get aligned before it picks a database schema, because the cost of rework scales with how deep the decision sits.
- Models are improving at maintainability much slower than people assume; on Slop Code Bench (University of Wisconsin) a top model scored 14.8% and a newer one 16.3%, and Dex argues this is because there's no fast oracle for maintainability to build RL environments around.
- A software factory differs from a real factory: a bad car only hurts one buyer, but bad code degrades every future piece of work because it becomes a pattern the model copies, so the existing codebase is itself the dominant context.
- The compounding path is to treat human review comments and session traces as raw material for improving skills, linters and nightly cleanup agents, rather than designing a whole factory up front.
- Dex predicts the software factory stack will decompose into open interfaces and components like Kubernetes did, and warns against building your whole workflow inside one vendor's walled garden.
It's the concrete origin story of the reversal, including why teams ended up reviewing the same code twice instead of saving effort.
We wanted to be living in the future. And so we said, cool, let's try this... If you read the plan, like the code is not as important. Ton of issues with that. First of all, the plans contained all of the code that was going to be written.
The sharpest argument in the episode for why code quality compounds differently once agents are reading your repo as context.
In a factory, if a car comes out at the end of the line and it's bad, whoever was going to buy that car is going to deal with it. But if you ship bad code in your software factory, it degrades every future piece of work that goes through that factory, because there's more bad patterns for the model to see.
If you ship bad code in your software factory, it degrades every future piece of work that goes through that factory.
There's no fast oracle for software maintainability.
When people say we are drowning in PRs, my pushback is: no, you don't have too many PRs, you have too many bad PRs, because you're letting people turn off their brains when they're coding.