Dex Horthy (founder of HumanLayer, author of the "12-factor agents" manifesto) argues that the quality of a coding agent's output is bounded entirely by what's in its context window. His team's answer is frequent intentional compaction: a research → plan → implement workflow that keeps context utilization under 40%, replaces line-by-line code review with review of research files and plans, and uses sub-agents purely for context control. The payoff: shipping production-grade code in 300k-line brownfield repos with no slop — while he hasn't opened a non-markdown file in an editor in nearly two months.
/compact — write a structured progress file yourself and use it to onboard a fresh agent, rather than trusting auto-compaction.Dex opens with a short history: HumanLayer published the "12-factor agents" manifesto (principles for reliable LLM applications) in April, before the industry-wide context-engineering conversation took off in June. He frames the talk as the sequel to that work — not "how do we build agents," but "how do we get the most out of today's models." He cites two influences: Sean Grove's "The New Code" talk (arguing the spec, not the throwaway prompts, is the durable artifact) and a Stanford study of 100,000 developers showing AI-generated code causes heavy rework and can actively slow people down on complex, brownfield tasks.
"The only thing other than like training your own models and messing with the temperature, the only thing that improves the quality of your outputs is the quality of what you put in, which is your context window."
The workflow wasn't chosen — it was forced. Working with one of the best AI coders he'd met, Dex was receiving 20,000-line PRs of complex Go systems code (race conditions, shutdown ordering) every few days. It was unreviewable. The team adopted spec-first development as the only way to stay aligned. Over roughly eight uncomfortable weeks, he learned to stop reading every line of code — reading the tests and the specs instead — and now ships multiple PRs a day.
"I shipped six PRs last Thursday and I haven't opened a non-markdown file in an editor in almost two months."
The naive pattern is shouting corrections at the agent until you run out of context, give up, or cry. Slightly smarter: when it goes off track, stop and start fresh with steering. Smarter still is intentional compaction — deliberately writing out a structured progress file (what you found, what matters) and using it to onboard the next agent, rather than relying on /compact, which Dex dismisses. The guiding question is always "what actually takes up space in the context window" — searching for files, understanding flow, and especially MCP tools that dump big JSON blobs.
Because everything an agent does is a loop of choosing the next tool or edit, Dex optimizes context for correctness, completeness, size, and trajectory. Inverted: the worst thing in a context window is bad info, then missing info, then noise. He references Jeff Huntley's "Ralph Wiggum as a software engineer" — running the same prompt in a loop overnight — as a deceptively dumb technique that works remarkably well precisely because it respects how context windows behave.
"Everything that makes agents good is context engineering."
Many people reached for Claude Code sub-agents to mimic an org chart (product manager, data scientist, front-end engineer). Dex argues their real value is context control: send a sub-agent to "go find where this happens," and it returns just the answer, so the parent agent gets to work without carrying the burden of all that reading and searching. The catch is the game of telephone — you have to prompt the parent to prompt the child about exactly how to return information.
The daily practice is building the entire workflow around context management, keeping utilization under 40% throughout three phases. Research understands how the system works and emits file names and line numbers so the next agent doesn't re-search 100 files. Planning enumerates every change — files and snippets, plus explicit test/verify steps — and is far shorter than the resulting diff. Implementation just writes the code; if he's shouting at Claude, it means the plan was bad. Human review happens on the research and the plan, not the 2,000-line PR, so problems get caught early. Dex notes their CLAUDE.md and slash commands are tested for weeks before anyone's allowed to change them.
"I can't read 2,000 lines of Go code every day, but I can sure as heck read 200 lines of an implementation plan."
Two case studies. On a podcast with the BAML founder, Dex one-shot a fix into a 300,000-line Rust codebase — it was good enough that the CTO merged it before they finished recording. Separately, a 7-hour session with the Boundary CEO shipped ~35,000 lines adding WASM support to a programming language, roughly one-to-two weeks of work. The takeaway hierarchy: spend your time specifying the right problem and making sure the agent understands the system, because errors at the research level cascade into thousands of bad lines.
"A bad line of code is a bad line of code. And a bad part of a plan can be hundreds of bad lines of code. And a bad line of research ... can be thousands of bad lines of code."
Dex expects coding agents themselves to get commoditized; the hard, uncomfortable part will be the team and workflow transformation — getting people to embrace new ways of communicating and structuring work. His intern shipped two PRs on day one and around ten on day eight. The closing exhortation: figure this out, or you're going to have a bad time.
"Everything that makes agents good is context engineering."
"I shipped six PRs last Thursday and I haven't opened a non-markdown file in an editor in almost two months."
"Code review is about a lot of things, but the most important part is mental alignment."
"A bad line of code is a bad line of code. And a bad part of a plan can be hundreds of bad lines of code. And a bad line of research ... can be thousands of bad lines of code."
| Approx. Time | Topic |
|---|---|
| 0:00 | Intro — Dex, HumanLayer, and a history of "12-factor agents" |
| 1:30 | Influences: "The New Code" and the Stanford rework study |
| 3:00 | The unreviewable 20,000-line PR and spec-first development |
| 4:30 | The goals (that were forced upon him) |
| 5:00 | Naive prompting vs. intentional compaction |
| 7:00 | Why context is everything; the equation and "Ralph Wiggum" |
| 9:00 | Sub-agents for context control |
| 10:00 | Research → plan → implement, keeping context under 40% |
| 11:30 | Human review and code review as mental alignment |
| 12:00 | Case studies: 300k-line Rust one-shot and WASM support |
| 13:30 | The error hierarchy and what's next |