Introduction
The Harper Reed LLM codegen workflow is a three-stage method for writing software with large language models: hone a spec, plan the build, then execute — using an LLM at every stage. Harper Reed, an entrepreneur and the former chief technology officer of Barack Obama's 2012 re-election campaign, described it in a February 16, 2025 blog post titled "My LLM codegen workflow atm." The post spread quickly through the developer community and was amplified by Simon Willison, Martin Fowler, and Werner Vogels.
The core claim is simple: most AI-coding failures are spec failures. Front-load a rigorous, LLM-assisted specification and a test-driven plan, and the actual code generation becomes far more reliable. This guide walks through each stage, reproduces the exact prompts, and states where the workflow breaks down.
What Is Harper Reed's LLM Codegen Workflow?
The workflow is a spec-driven pipeline with three discrete steps, each handled by a different kind of model:
- Idea honing — a conversational model interviews you to build a detailed specification.
- Planning — a reasoning model turns that spec into small, test-driven build steps.
- Execution — a code-generation agent implements those steps one at a time.
It is the deliberate opposite of vibe coding, where you prompt loosely and accept whatever the model produces. Here the point is to remove ambiguity before any code is written. The technique is applied prompt engineering: the prompts are fixed, reusable, and designed to make the model do the thinking you would normally skip. Reed is explicit that this is a snapshot ("atm" means "at the moment") and assembled from personal work, conversations with other developers, and community best practices — not a formal methodology.
Stage 1: Idea Honing — One Question at a Time
The first stage uses a conversational model (the post used ChatGPT) to turn a rough idea into a specification. The trick is the one question at a time prompt, which forces the model to interview you rather than dump a generic plan:
Ask me one question at a time so we can develop a thorough, step-by-step
spec for this idea. Each question should build on my previous answers, and
our end goal is to have a detailed specification I can hand off to a
developer. Let's do this iteratively and dig into every relevant detail.
Remember, only one question at a time. Here's the idea: <IDEA>
You answer each question in turn. Because every question builds on the last, the model surfaces decisions — data handling, edge cases, error states — that you would otherwise discover mid-build. When the interview is done, you ask the model to compile everything into a single document:
Now that we've wrapped up the brainstorming process, can you compile our
findings into a comprehensive, developer-ready specification? Include all
relevant requirements, architecture choices, data handling details, error
handling strategies, and a testing plan so a developer can immediately
begin implementation.
Save the result as spec.md. This file is the single source of truth for everything that follows.
Stage 2: Planning — From Spec to Test-Driven Steps
The spec is handed to a reasoning model (the post named o1, o3, and DeepSeek R1) to produce a build plan broken into steps small enough to implement safely but large enough to make progress. Reed's test-driven planning prompt is verbatim:
Draft a detailed, step-by-step blueprint for building this project. Then,
once you have a solid plan, break it down into small, iterative chunks that
build on each other. Look at these chunks and then go another round to break
it into small steps. Review the results and make sure that the steps are
small enough to be implemented safely with strong testing, but big enough to
move the project forward. Iterate until you feel that the steps are right
sized for this project. From here you should have the foundation to provide a
series of prompts for a code-generation LLM that will implement each step in
a test-driven manner. Prioritize best practices, incremental progress, and
early testing, ensuring no big jumps in complexity at any stage. Make sure
that each prompt builds on the previous prompts, and ends with wiring things
together. There should be no hanging or orphaned code that isn't integrated
into a previous step. Make sure and separate each prompt section. Use
markdown. Each prompt should be tagged as text using code tags. The goal is
to output prompts, but context, etc is important as well. <SPEC>
The output is prompt_plan.md — a series of ready-to-run prompts, one per step, each wiring its work into what came before so no code is left orphaned. Reed then asks for a companion checklist with a short prompt:
Can you make a `todo.md` that I can use as a checklist? Be thorough.
That produces todo.md, which you tick off as each step lands. Reed estimates stages one and two take roughly 15 minutes combined — the plan is deliberately front-loaded work.
Stage 3: Execution — Feeding Prompts to a Codegen Agent
Execution is mechanical by design: paste the prompts from prompt_plan.md into a code-generation tool one at a time, test after each, and move on. Because each step is small, test-driven, and integrated with the last, the agentic workflow stays inside a window you can actually review.
The original post used Claude.ai (copy-and-paste) and Aider (which runs tests and iterates autonomously). Claude Code shipped days after the post, and Reed's follow-up, "Basic Claude Code," documents switching to it as the execution AI agent while keeping the same spec-and-plan front end. In that follow-up Reed makes the test-driven point sharply: have the agent build the test and a mock first, then make the mock real in the next prompt — the most effective counter to hallucination and scope drift.
Greenfield vs. Legacy Codebases
The full three-stage pipeline is a greenfield workflow, for projects that start from nothing. For legacy (brownfield) codebases, Reed runs a tighter per-task loop: use a tool like Repomix to pack the relevant code into a single context bundle, then prompt the agent for one targeted change — a code review, a missing test, a bug fix — at a time. The spec-then-plan discipline is relaxed because the existing code already encodes most of the decisions; the constraint that survives is doing one reviewable thing per prompt.
Why the Workflow Works
The insight worth keeping is that most AI-coding failures are specification failures, not model failures. A vague request lets the model invent structure, choose abstractions that do not fit, and accumulate technical debt fast — a concern raised repeatedly in the 522-point Hacker News discussion of the post. The workflow attacks that at the source: the one-question interview extracts a complete spec, the planning prompt refuses "big jumps in complexity," and test-driven steps give the agent a fixed target so it cannot silently drift. It is a close cousin of Anthropic's advice on context engineering for agents — curate what the model sees so it makes fewer wrong turns.
It also rhymes with other named-practitioner methods. Y Combinator's Garry Tan popularized a senior-engineer review prompt for Claude Code that forces a plan-and-review pass before any code is written. Both bet the same way: spend the tokens up front on thinking, and the code that follows is cheaper to trust.
Limitations and Caveats
Reed is candid about the boundaries, and they matter:
- It is a solo workflow. Reed warns against running agents in parallel across a shared codebase: "the bots collide, the merges are horrific." The method assumes one person driving one plan.
- It is model-dependent and dated on purpose. The post's own hedge — "this is working well NOW, it will probably not work in 2 weeks" — is why it says "atm" in the title. The specific models named (o1, o3, R1, Aider) are already a moving target.
- It is easy to go "over your skis." A good plan can outrun your ability to review it; skipping the review because the tests pass is how bad architecture ships fast.
- There is real idle time. Waiting on token generation between steps is a genuine cost, and Reed notes the energy consumption of the whole approach as a standing concern.
Conclusion
Harper Reed's LLM codegen workflow is not a tool or a product — it is a discipline: spec, plan, execute, with an LLM at each stage and a human reviewing every step. The reusable prompts are the artifact people copy, but the durable idea is that front-loading a rigorous specification and a test-driven plan turns unreliable code generation into something you can actually ship. Treat the specific models and tools as interchangeable — as Reed does — and the three-stage shape is what carries over.
For other named-practitioner approaches to AI coding, see Garry Tan's gstack and the Ralph technique.