A build-review loop in your own repo. Built right the first time.
For founders, small product teams, and agencies already running Claude Code, Cursor, or Codex. We stand up a loop in your repository that specs the work, builds it, reviews it adversarially, and opens pull requests you can read with confidence.
I architect it, I build it, and then I try to break it.
The gap this closes
Most teams adopting coding agents land in the same place. Prompt, wait, read the diff, prompt again. Throughput is capped by how much attention you have on any given day.
A loop lifts that cap. It only works if three things are right. The spec has to be disciplined enough that an agent cannot read it two ways. The review has to run somewhere separate and genuinely try to break the change, with no memory of having written it. The guardrails have to be enforced by the repository, not requested in a prompt.
Get those three right and every iteration compounds. Get them wrong and the loop ships confidently broken code, faster than you can read it. Knowing the difference before it costs you a week is what this engagement is for.
What is a guided buildout?
A guided buildout is a build-review loop stood up properly inside your own repository. I design the architecture, write your stage contracts against your actual codebase, build it, and set up the guardrails — then I try to break what it produces. We run one full cycle on real work together, and you finish owning a loop that runs, and the judgment to change it.
I build it. You own it.
I design the architecture. That means the four stages, Spec, Build, Review and Merge, and the three laws that keep quality flat across a hundred iterations instead of drifting after the tenth. I write your three stage contracts and tune them against your actual codebase, not a generic template. I set up the guardrails. Then we run one full cycle together on real work and tune what that cycle exposes.
You do not need a developer on staff for any of this. What is deliberate is the handover: it is documented as it is built, so you finish owning a loop that runs, and owning the judgment to change it when your codebase changes. Nothing important stays in my head.
How it works
Blueprint first
One paid ninety-minute session maps the loop to your repository and checks it against the five prerequisites. Why this matters: the buildout starts on ground we have both already looked at.
Architecture, not just prompts
Your tracker becomes the loop's memory. Statuses, labels and the claim-lock are designed on purpose, not improvised at the first collision. Why this matters: state lives somewhere durable, so an interrupted run resumes instead of starting over.
Adversarial review, built in
Review runs as a separate context whose only job is to break the change. Why this matters: nothing gets to rubber-stamp its own work.
Guardrails that are enforced
Branch protection, merges by pull request only, secrets kept out of the agent's reach, and a hook that blocks a direct push. Why this matters: an instruction can be lost in a long context. A hook cannot.
One real cycle, tuned together
We take one real piece of work all the way through the loop and tune the contracts against what actually happened. Why this matters: this is the highest-leverage hour in the whole project.
A path to hosted automation
Once the contracts are stable, the loop moves to scheduled cloud runs. Why this matters: you stop being the thing that starts it.
What you walk away owning
- A working, tuned loop running in your own repository
- Your three stage contracts, written for your stack and your conventions
- Your tracker set up as the loop's state machine, with the statuses and locks documented
- Guardrails enforced at the repository level, not held in a prompt
- One full cycle run end to end on real work, and the tuning that came out of it
- A clear path to hosted automation when you want the loop running on a schedule
Who this is for
This is for you if
- You are already running a coding agent and you have hit the ceiling of prompt-and-wait
- Your repository has tests, or you are happy for me to build them as part of the work
- You want consistent throughput without supervising every prompt
- You want it built properly without putting a developer on it
This is not for you if
- You cannot give an outside collaborator access to the repository. I build the loop where it will run, and there is no version of that from the outside.
- You are looking for a button that works with no setup
- The work is genuinely exploratory and cannot be specified before it starts
Three steps, in order
Step one. The Loop Blueprint. $997
A ninety-minute architecture session and a written blueprint for your specific repository. Which loop to build first. How your tracker and state machine should be shaped. A gap-check against the five prerequisites. Your three stage contracts, adapted to your stack. The full $997 is credited toward the Guided Buildout.
Step two. Loop Engineering: Guided Buildout. $4,997
I architect it, build it in your repository, and try to break what it produces. Capped at one loop, in one repository, so the work stays deep rather than wide.
Step three. Loop Operations. From $2,000 per month
Optional and ongoing. Tuning, new contracts as your codebase grows, scaling to hosted automations, and a regular look at what the loop is actually catching.
The guide this installs
I wrote Loop Engineering, the technical guide this engagement installs. It is verified against current tool documentation and written to be handed straight to an agent and acted on, rather than read and admired.
The guide is the map. This is the guided install, in your repository, with someone who has already built the thing.
Build it right the first time
A loop is a multiplier. That is the whole appeal, and it is also the whole risk, because a multiplier works in both directions. A well-built loop compounds good judgment across every iteration. A badly built one compounds a bad assumption just as efficiently, and you find out about it a hundred commits later.
The difference is set at the start, in the architecture. Please book the Blueprint and let's look at your repository properly.
Questions
Do we need a developer?
No. I architect the loop, build it in your repository, and then try to break what it produces. You do not need an engineer on staff to get it running. It is documented as it is built, which is what makes it yours to run and change afterwards.
What do we need in place before we start?
A repository, and access to it. If there is no automated test suite, I build one as part of the work — a loop with nothing to check its output against just ships confident nonsense faster, so it is not optional, but it is not yours to arrange first either. The Blueprint tells you which of the five prerequisites you already have and what I would be standing up.
Which coding agent does this work with?
Claude Code, Cursor, or Codex. The architecture is the same across all three. The stage contracts are written for whichever one you run.
How long does it take?
It depends entirely on your codebase, so I do not quote a fixed window. The Blueprint is where we look at your repository properly and scope it — that is the point of doing it first, and it is the honest answer rather than a date I would have to walk back.
What is the difference between the free guide and the buildout?
The guide is the map, and it is genuinely complete — you can build from it yourself. The buildout is me installing it in your repository, with the contracts tuned to your stack and one full cycle run alongside you.
Do we have to keep paying after the buildout?
No. Loop Operations is optional. It exists for teams who want ongoing tuning and someone watching what the loop catches. Plenty of clients finish at step two.
What if our repository is not ready?
Then the Blueprint tells you exactly what is missing, in writing, and what I would be standing up as part of the buildout — before you spend $4,997 finding out. That is a good outcome for a $997 session.