*Published August 11, 2026* --- Forty years ago Fred Brooks wrote the line the whole industry has spent the AI era rediscovering. In *[No Silver Bullet](https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf)*, he argued the hard part of building software was never the code. It was deciding what to build: the "essential complexity" of specifying a correct, coherent thing, versus the "accidental complexity" of expressing it in a language a machine can run. Brooks predicted tooling would never touch the essential part, because that part is thinking. For most of software's history that prediction stayed abstract: writing the code was still most of the visible work. You typed it, reviewed it line by line, and reading it was how you knew what the system did. Then a model started writing the implementation in minutes, and Brooks's distinction stopped being a book-club argument and started showing up in who gets hired. When accidental complexity collapses toward zero, what's left is the essential complexity, and that is most of the job that remains. ## The inversion Salvatore Sanfilippo, who wrote Redis, [is blunt about it](https://antirez.com/news/169): if you control the ideas, reviewing the generated code line by line is "suboptimal and often pointless." Capture the ideas in a design document, and let the model regenerate the implementation against it. Mark Essien [describes his actual day](https://x.com/markessien/status/2076714143692849209): hours writing and validating a plan, then twenty minutes of code generation. "The plan is now the coding, not the coding." This is the inversion. The plan becomes the authored artifact: the design, the constraints, the acceptance checks, the non-obvious decisions the code can't explain to you. The code becomes its compiled output, something you can regenerate and mostly shouldn't hand-edit. [Don Norman's work on automation](https://jnd.org/the-human-side-of-automation/) names the general shape of this: automate what you can, and the human job becomes high-level guidance and collaboration, not a smaller leftover of the old task. The scarce act shifts from producing code to specifying and validating intent. Code review stops asking whether the syntax is right and starts asking whether the design was understood. ## The lesson is not "plan more" This is where most takes overshoot, and it's worth slowing down. Bureaucratic specification was friction before AI and it's friction now: a forty-page requirements document nobody executes, a design review attended rather than decided. Those are accidental complexity mistaken for the essential kind. Making the plan the artifact does not resurrect Big Design Up Front: the [Agile Manifesto](https://agilemanifesto.org/)'s authors were right that "responding to change" beats "following a plan," and that critique still applies if the plan reverts to the old comprehensive spec. What relocates upstream is intent clarity, not ceremony. The distinction is Brooks's own: capture the essential decisions (what the thing is for, which constraints are load-bearing, what must be true for it to be correct), and skip the accidental scaffolding a competent agent can infer. In practice that's Gojko Adzic's *[Specification by Example](https://gojko.net/books/specification-by-example/)* practice: the spec worth keeping is the one that executes, because if you can't run it, no one will keep it current. The healthiest form is thin, closer to an architecture decision record than a requirements binder: a bloated plan decays fast, and a hand-maintained one competes with the code for the attention it was meant to save. ## Where it breaks A thesis this clean should make you suspicious, and the honest version has four hard edges. The first is "nobody needs to read the code." As an attitude toward regeneration, that's fine: you rebuild rather than nurse the implementation. As a literal claim, it's dangerous. When [researchers at NYU](https://arxiv.org/abs/2108.09293) had GitHub Copilot generate programs across security-relevant scenarios built around high-risk CWEs (including MITRE's Top 25) in a 2022 study, roughly forty percent were vulnerable, faithfully reproducing insecure patterns from training data. Unread output ships exploitable defects, and the line-by-line read doesn't disappear so much as relocate onto the constraints, the type system, and the test suite. That burden falls on whichever conscientious engineer keeps doing it, until they burn out, and unlogged, it's how technical debt accrues. The second edge is "the plan decides the outcome." It decides what you *meant*, not what happens at runtime. Charity Majors's [argument against spec-worship](https://x.com/mipsytipsy/status/2031877161821544653) holds here: code is never the whole story, since the same code behaves differently across systems and usage patterns, and only telemetry reports that. The plan is the authored artifact for intent; the running system and its observability are the authored artifact for runtime truth, and conflating the two leaves runtime unaccounted for. The third edge: as [Thariq](https://x.com/trq212/status/2073100352921215386) puts it in *A Field Guide to Fable*, the map you hand an agent only represents the work, and the territory it meets never fully matches. Every gap becomes a guess, and delegating more in a single pass compounds the guesses into drift. A complete authored plan is a fiction; a good one is a live document you rewrite as implementation surfaces what you missed. The fourth edge is the cost of the plan's new authority: a confidently wrong plan builds the wrong thing in twenty minutes, and every downstream agent inherits it unread. The same speed that makes a good plan powerful makes a bad one expensive, which is the real argument for keeping the plan small: not minimalism for its own sake, but so its errors stay cheap to catch. ## What it's really about None of this undoes the inversion so much as bounds it. "Upstream" means intent, judgment, and the constraints that gate regeneration, not a bigger pile of documents and not away from the running system. There is also a cost even Sanfilippo's own account doesn't settle, though he's honest enough to flag it: if juniors never read the code, it's not obvious how they build the judgment that lets a senior tell essential from accidental complexity. That judgment came from years reading and repairing other people's code, and a world that authors plans and regenerates code stays quiet about where its planners come from. I've written before about how [cheap code shifts value toward whoever supplies the expensive context](https://para.ngpcloud.org/cheap-code-expensive-context). This is the companion claim, one level down: what the human now *authors* is the intent, the thin, load-bearing statement of what should be true and the constraints that decide whether the output counts, not the code itself. The engineers who pull ahead won't be the ones who plan the most, but the ones who can tell essential complexity from accidental and write down only the first. Brooks would recognize the shape of it. The hard part was always deciding what to build. We finally have a machine fast enough that the deciding is most of the job that remains, and the edges above are the rest.