Fabricate, Collaborate, Elaborate, Delegate, Validate: Why My Bootstrapping Command Produces Better One-Shot Code

The right consistent process saves your time and energy and your AI collaborator's context window and token budget.

Many AI coding sessions follow the same arc. The first hour is great. The model is sharp, the code is clean, the direction is clear. By hour three, something has gone wrong. The model contradicts an earlier decision. The file structure it's generating doesn't match what exists. The test it writes assumes a pattern that was deprecated two features ago. You didn't change models. You didn't change your prompting style. What happened?

Context decay happened. The model's working memory filled up with recent work, and the architectural decisions from the beginning of the session got buried. The model is not stupid. It just forgot what it agreed to.

Context window management is the key to solving this problem, but I've found that shifting the problem even further left can make all the difference. My thinking has evolved to a strategy where I try to spend my cycles in creating a mental model of the problem we're solving in collaboration with the AI. Then I have the AI create an extremely detailed spec from that mental model that it can follow in context-bounded parallel sessions. If I do that up-front work well, the problem is broken into chunks small enough that context is never overwhelmed.

I also try to automate as much repetitive work as I can -- so I built a /bootstrap command as my solution to this problem. It includes four phases of work that happen before a single line of production code is written, and a fifth phase that keeps the work honest after it starts.

Phase 1: Fabricate

The first phase is physical construction: copy the template, update the project name throughout, ask whether to set up GitHub locally, with a public or private remote repo. No decisions, no creativity, no ambiguity. Just scaffolding.

This phase matters not because template copying is hard but because it establishes the physical substrate before the conceptual work begins. Every future decision will be made in the context of a real project directory with real files. The model is not reasoning in the abstract. It is standing in a specific place.

The GitHub questions belong here too, even though they feel trivial. Getting configuration decisions out of the way before the creative conversation starts means they will never intrude on it. Small frictions, deferred, become big frictions later. Small frictions eliminated stay eliminated.

And finally, a consistent project structure means I don't need to think about where to go to find my implementation plan, my progress tracking file, etc. I don't need to think about whether I remembered to include the right project name, or set up a git repo, or included my Claude.md file. A little discipline and consistency allows you to concentrate on the interesting problems, rather than the minutiae.

Phase 2: Collaborate

The second phase is effectively a single instruction: "Ask me what we're going to build."

This is a commitment device. The act of describing your idea to a model -- in natural language, out loud (or in writing), with the model listening -- surfaces ambiguities you didn't know you had. Vague ideas that felt complete in your head become obviously incomplete when you try to articulate them to something that will take them literally.

The phase is deliberately unstructured. Bootstrap could impose a template here: enumerate features, define users, specify constraints. It doesn't. The free-form prompt -- "what are we going to build?" -- is a design choice, not a gap. Exploration requires room to move. An idea you are forced to describe in bullet points before you fully understand it becomes a worse idea. The Elaborate phase that comes next will impose the structure. Collaborate exists to let the idea breathe first. We're brainstorming.

The phase ends with a README.md that captures the description. This is not documentation for later. It is externalized intent for now. Both parties -- human and model -- have just signed the same piece of paper about what is being built.

The git commit that follows ("Initial project setup with README") is the signature on that paper. You now have a recorded starting point. The session has a constitution.

Phase 3: Elaborate

The third phase is where my bootstrap implementation earns its keep: the model asks questions, one at a time, multiple choice where possible, and does not stop until it actually understands the design.

One question at a time is not a stylistic preference. It is a cognitive load management decision. A developer who gets ten clarifying questions at once answers them all shallowly. A developer who gets one question at a time, with the model waiting for a real answer before proceeding, gives the model ten real answers instead of ten glances.

The phase ends with a trick I saw in an early blog post from Jesse Vincent (author of the superpowers framework for Claude Code) [1] that I loved -- the model describes the design back in sections of 200-300 words, confirming alignment at each step. This is not a summary for the developer's benefit. It is a forced verification pass that catches mismatches between what the developer described and what the model understood before any implementation decisions are made.

This Q&A process also handles what looks like a missing feature: there is no formal loop-back path to Collaborate. If a design question in Elaborate reveals that the original idea was significantly wrong, there is no explicit instruction to revise the README and start over. But the loop-back happens anyway, because the agent asks for clarification. Ideas shift during questioning. New constraints surface. Better approaches emerge. The agent absorbs these in real time and will fold them into the implementation plan it produces at the end -- which means the plan reflects the idea as it stood at the end of Elaborate, not as it was described at the start of Collaborate. The README may be a snapshot of a slightly earlier version of the thinking. The plan is current.

Catching a misalignment at this stage costs nothing. Catching it after three phases of code are complete costs time.

Phase 4: Delegate

The fourth phase is the most important and the most underappreciated: write the implementation plan into docs/plans/, then write a PHASES_SUMMARY.md that covers all phases concisely.

The plan has a specific audience, with another gem derived from Jesse Vincent's blog post [1]: "an engineer with zero context for the codebase and questionable taste."

That characterization is not an insult. It is a precision instrument.

Zero context means the plan must be self-contained. It cannot say "use the existing pattern" -- it must specify which file contains the pattern, which lines to look at, which tests to copy. It cannot assume the implementer knows which library the project uses or why. Every architectural decision made in the Elaborate phase must appear explicitly in the plan.

Questionable taste means the plan must be prescriptive, not aspirational. "Write clean, maintainable code" is useless guidance. "Functions longer than 30 lines should be decomposed before adding tests" is actionable. The plan has to anticipate the shortcuts a reasonable developer under time pressure might take and close them.

The zero-context engineer is every AI agent that picks up this plan in a fresh session. This is the connection to one-shot code quality. The implementation plan is not a document for human developers. It is an external memory store for AI agents. It contains everything the model would need to know to produce correct first-draft code in a context window that has never seen the original design conversation.

When you delegate to a fresh agent instance with a good plan, the agent does not have to infer what you wanted. It has a spec. It has file paths. It has test strategies. It has the decision rationale behind non-obvious choices. The first draft is better because the agent is answering a specific question rather than guessing at an ambiguous one.

Phase 5: Validate

The fifth phase is not part of bootstrap. Bootstrap ends when the plan is written and committed. Validate is what happens every time you hand that plan to an implementing agent.

The pattern: delegate a phase of the plan to a fresh agent context, then validate what came back before moving to the next phase. Not "does this code run?" -- that's a test. Validate means: does what was built match what the plan specified? Did the agent make a unilateral decision that should have been a question? Did it take a shortcut that will cause problems two phases from now? Did it discover something during implementation that changes what the next phase should do?

The agent cannot answer these questions on its own. It just built what it built. Validate is the human step that keeps Delegate from becoming Abdicate.

This is where the staleness loop closes. When validation reveals a deviation -- the agent built something better than specified, or found a reason the plan was wrong -- the plan gets updated before the next delegation. The plan is not a contract to be honored. It is a living record of current intent. Validate is how it stays current.

The pattern repeats for every phase: Delegate, then Validate, then Delegate again. Not as a bureaucratic checkpoint but as a forcing function: the developer who validates before moving forward is the developer who catches the subtle drift before it compounds into an incoherent codebase.

Enveloping the Loop

There is a useful spectrum for thinking about where humans sit relative to autonomous AI work.

At one end, we have Human-In-the-Loop. The human is a checkpoint inside the process. The agent does a step, the human reviews it, approves it, and the agent does the next step. The human's judgment is inserted at every inflection point. Nothing proceeds without them. This is safe, slow, and expensive -- and it describes most of how people use AI coding tools today, whether they name it that way or not.

At the other end: no human at all. Maximum leverage. The system runs, evaluates, improves, and ships without asking anyone anything. This is the theoretical ceiling of AI productivity -- and it is not realistic for anything that matters, because there is always something the machine cannot evaluate: whether the goal was worth pursuing in the first place, whether the output fits a context the spec didn't capture, whether the metric was measuring the right thing.

The productive middle is Human-Before-the-Loop: the pattern Andrej Karpathy demonstrated with his autoresearch project [2]. The human defines the goal, the search space, and -- critically -- the scoring criterion that tells the system what counts as progress. Then they step back. The loop runs autonomously, evaluates its own outputs against the criterion, discards failures, keeps winners, and iterates. The human returns to interpret results, not to supervise experiments.

Garry Tan's summary of that project: "design the arena, let AI iterate" [3].

Software developers have been building their own versions of this. Laird Popkin's autocoder [4] applies the same pattern directly to production coding: a fully automated loop where the agent writes code, runs tests, evaluates failures, revises, and iterates -- with the human's role compressed almost entirely to specifying what the system should do and reviewing what comes out. It is Human-Before-the-Loop for software, in the same way Karpathy's autoresearch is Human-Before-the-Loop for ML experimentation. Define the success criteria precisely enough, then get out of the way.

Bootstrap is not that. Not fully. Call it HBtL Lite. The Fabricate phase establishes the arena's physical structure. Collaborate and Elaborate define what the build is trying to achieve. But the Delegate phase -- and specifically, the instructions in Elaborate to set up TDD and end-to-end tests as part of the plan -- is the moment where the scoring criterion gets defined. The tests are not an afterthought. They are the machine-readable definition of success: the thing the agent can evaluate without asking you at every step whether the work is good.

Once the plan is written and the test infrastructure is in place, the coding loop can run largely without you. The agent builds, the tests evaluate, the agent iterates on failures. You don't need to be in the loop because the loop already knows what "done" looks like.

The maximum leverage point is not being needed. Bootstrap doesn't get all the way there -- but it radically reduces the number of times the coding loop needs to stop and ask.

"Not being needed" is a direction, not a destination. Something always requires judgment that tests cannot supply: a design decision the spec didn't anticipate, an ambiguity in the requirements, a performance tradeoff with no objectively correct answer. Purely removing yourself isn't the goal. Relocating yourself to where your judgment is irreplaceable is.

Bootstrap achieves this by positioning the human at both edges of the loop rather than inside it.

Before: the human is in the four bootstrap phases define everything the loop needs to run.
After: Validate asks the human to run their own checks to see whether what came back is actually what was wanted. The loop itself -- the agent building features, running tests, fixing failures -- proceeds without requiring the human at each step.

This is the difference between Human-In-the-Loop and what bootstrap is aiming for: human enveloping the loop. You define the arena before it starts. You review the results when it stops. In between, the machine iterates. The quality of that iteration is determined almost entirely by the quality of the setup.

The Validate phase closes the envelope. The tests running inside the loop are the automated validation -- the scoring criterion running continuously. The human validation in Validate is the check that the scoring criterion itself was the right one. Both are necessary. Neither requires the human to be present for every iteration in between.

One gap remains.

Validate has no defined criteria. What does a passing validation look like? The current process leaves this entirely to the developer's judgment. This is fine when the developer is experienced and paying attention. It is a problem when they are moving fast and skip the review, or when "looks good" means "it runs" rather than "it matches the plan." A short checklist embedded in the plan itself -- three or four questions to answer before marking a phase complete -- would make Validate more consistent without making it burdensome.

The Bottom Line

Bootstrap works because it treats the session setup as a knowledge-capture problem, not a task-assignment problem. Each phase externalizes a different category of knowledge: the physical structure, the intent, the design decisions, and the implementation strategy. By the time code is written, that knowledge lives in files -- not in the model's context window, where it will decay.

The five phases have a clean internal logic: Fabricate the substrate, Collaborate to let the idea breathe, Elaborate to nail it down, Delegate to a plan that assumes nothing, and Validate to keep the plan and the build from diverging. The first four happen before a line of production code is written. The fifth happens every time a line is handed off.

The deeper goal behind all five is to move the human out of the loop and onto the edges of it -- before and after, not during. The plan is the arena. The tests are the scoring criterion. The loop runs. You review what it produced. HBtL Lite: not Popkin's fully automated coding loop [4], not Karpathy's overnight research machine [2] -- but considerably closer to both than skipping the setup and going straight to the keyboard.

If this resonated, here are some related articles:

For the full Human-Before-the-Loop argument and what Karpathy's autoresearch reveals about where human judgment actually belongs in autonomous AI work: An Evolving Strategy for Knowledge Work: From Human-In-the-Loop to Human-Before-the-Loop | Substack
For a look at HBtL taken further -- a fully automated coding loop that pushes human involvement to the edges: Automating Agentic Coding by Laird Popkin

References

I mentioned the inspiration I derived from Jesse Vincent's blog posts as I built out my /bootstrap command, and he's taken these ideas (and others) much further in his superpowers agentic skills framework, which my team has used often with great success.
Find it at https://github.com/obra/superpowers.

Keith MacKay is a technology strategy consultant and CTO in EY-Parthenon's Software Strategy Group (SSG), specializing in AI disruption and technology diligence for private equity and corporate clients. SSG's AI Disruption Lab conducts rapid assessments of how AI transforms and threatens existing business models and value chains. Keith teaches at Northeastern University and writes about strategy, management, and AI/technology.