--- title: "Make the agent argue first: plan the plan, defend the design" url: "https://toddpaulbrownjr.com/writing/make-the-agent-argue-first/" author: "Todd Paul Brown Jr." description: "Before Cadence got code, a 1,105-line prompt made the agent plan its plan, and a design agent defended 19 features; arguing up front was cheaper than rework." kind: "article" updated: "2026-09-26T02:50:34+00:00" --- # Make the agent argue first: plan the plan, defend the design I shipped [Cadence](/builds/cadence/) — a proofread-by-ear desktop app — in five days of work spread across July 2025. Before any of that code existed, I spent a day making the agent plan its plan and then defend 19 feature ideas one by one. Arguing up front was cheaper than rework. The thing that changed how I work with coding agents is this: I stopped asking them to build, and started asking them to convince me the design would survive contact with reality. ## The opening prompt forbade code The first Cadence prompt was 1,105 lines. Its ninth line said the agent could not write any code yet. Instead, I asked for six deliverables: an audit of the open-source speech model's repository, a product spec, architecture decisions, a phased roadmap, design requirements, and a handoff prompt for a separate design agent that would argue for each feature. I had asked Claude Code to get the speech model running, expecting a working app. What I got was a model checkpoint and a Python script. A model is not a product. I ended up designing all of the features I was expecting the tool to ship with, before I understood what I was actually working with. The plan-the-plan prompt exists to make sure that doesn't happen twice. ## A design agent had to defend 19 features The handoff prompt created a design agent whose job was to argue for every feature on the roadmap. Each feature got an entry in what I called the reconciliation ledger: the agent's justification, my notes, and a grade — Essential, Beneficial, or Decorative. Roughly half were rejected. The agent proposed things like hover-over definitions, a reading-speed slider, and visual chapter previews. Every one of them had a reason: accessibility, user control, cognitive load. The agent made its case in writing, citing specific user needs and implementation risks. I cut the ones that didn't carry their own weight. What survived: content-addressed blocks so highlighting, notes and change detection all line up on the same units; a diff-and-reconcile engine so notes follow the text when a manuscript is revised; stale-detection so only changed paragraphs re-render; and a notes export. The ledger exists as a 19-entry Markdown file. This was cheaper than letting the agent build everything and discovering later which parts I'd never use. ## The riskiest component was attacked first The diff-and-reconcile engine — the thing that makes notes follow revised text — was the riskiest piece of architecture. I had the agent build it first, then I attacked it: I gave it edge cases and tried to make it fail. Three bugs confirmed, each fixed with a regression test. Only then was it declared safe to build on. By the time the rest of Cadence was wired up, the diff engine had 305 test functions expanded by parametrization into 368 backend tests. It has processed 2,995 segments across two real projects — a 63,000-word manuscript and 51 company knowledge-base documents — with zero failures. That adversarial review session happened before the agent wrote the app around it. Building it first meant I could trust it when everything else depended on it. ## A Windows quirk that failed silently One bug made it through testing and lived in production for a week. A hidden file attribute on an entire project folder made every chapter show as stale and refuse to regenerate. The JSON writes kept succeeding, so the app looked fine. The audio never updated. The worker couldn't log the failure either, because Windows doesn't surface that attribute to most file APIs. The fix landed as two commits: one to detect the hidden attribute and warn, and one to let the worker log errors even when the file operations report success. Both changes went into the test suite. The silent-failure mode is exactly the kind of thing you don't find until the app is running on real work. Planning the architecture and defending the features didn't catch it. Shipping did. ## Where that workflow sits against the industry About the same time I was building Cadence in July 2025, the industry was converging on a shared architecture for agent systems. Anthropic published "Effective harnesses for long-running agents" in November 2025, eight months after I started LEGION and four months after Cadence shipped. OpenAI named "harness engineering" as a discipline in February 2026. The planning workflow I used — make the agent argue its design before it writes code — is one answer to the problem those harness papers describe: agents that build things you don't need, or that ignore constraints you thought you'd made clear. I wasn't inventing anything. I was solving the same problem a lot of people were solving in the same months, before the pattern had a common name. ## What the workflow actually does The plan-the-plan prompt and the design-defense ledger do two things: they make implicit assumptions explicit, and they move the cost of a bad decision earlier. When the agent has to justify a feature in writing before it builds it, you see the assumptions it's making. When you see those assumptions, you can correct them before they're compiled into 300 lines of UI code. And when the agent writes the tests first — especially for the riskiest component — you know whether the architecture will hold before you've built the entire app around it. The workflow is not a silver bullet. It didn't catch the Windows hidden-attribute bug. It didn't prevent every bad choice. But it did prevent most of them, and it compressed five days of building into something that shipped with 368 backend tests, 2,995 segments processed, and zero rendering failures. Cadence has narrated 6.94 hours of audio from that 63,000-word manuscript, produced in 98.2 minutes of GPU time, in 1,869 segments, with zero failures. It has narrated all 51 company knowledge-base documents, 2.51 hours of audio. The thing works, and it works because the agent argued its design before it wrote the code. You can see the numbers and the architecture on the [Cadence](/builds/cadence/) build page, and the full test counts and segment renders on the [receipts](/receipts/) page.