describe the-build-machine
The Build Machine
A solo-engineer workflow with team-grade review and verification discipline.
ship_or_revise = reviewed
Described at an architectural level. The underlying work sits in a sensitive, private-domain environment, so this page covers how the system is built, not what it touches.
Problem
Speed is easy to buy and easy to regret.
Agentic tooling can change a large codebase fast, but velocity without control is just faster mistakes. The point is not to hand the wheel to the model; it is to keep the architectural decisions with the engineer while automation handles the mechanical work, with every change passing through review before it ships or goes back.
Architecture
Own the architecture
The engineer sets direction and boundaries; the model accelerates the build inside them, never past them.
Tooling over prompting
Hooks, commands, and MCP servers wrap the model in repeatable operations rather than one-off requests.
See the whole repo
Cross-repo mapping gives the model the context to change large systems coherently, not file by file.
Guardrails by default
Quality gates and review passes are part of the workflow itself, not an afterthought bolted on.
Tradeoffs
Control over speed
Automation is bounded by guardrails, trading a little raw speed for changes that stay coherent.
Review over autonomy
The model proposes broadly, but a human approves; independence is capped to keep judgment in the loop.
Repeatability over convenience
Work goes through tooling rather than ad-hoc prompts, trading quick hacks for a process that holds up.
Verification
Workflow guardrails
Automated checks bound what a change can do before it is even proposed.
Review passes
Changes are read and approved by a person, not merged on trust.
Test and verify loops
Every change is exercised and verified before it is considered done.
Failure modes
- Unreviewed merges
- Agents cannot merge. The path to production runs through a person, by construction.
- Architectural drift
- Structure and interfaces are owned by a person, so generated code fits the system instead of reshaping it.
- Plausible-but-wrong output
- Verification catches what looks right and is not, before it ships.
- Unrepeatable magic
- Operations live in named tooling, so any change can be re-run and inspected later.
Deliberately not
- Ship on trust. Tests, review, and verification set the pace, not generation speed.
- Own architecture. That stays with the engineer.
- Depend on unrepeatable prompting. The workflow has to run the same way twice.
My role
I built the harness and own the architecture inside it.
- agent workflows
- MCP tooling
- quality gates
- review discipline
- final merge call
Agents accelerate execution; the design decisions, the boundaries, and the final review are mine. The value is in the harness around the model, not the model alone.
Outcome
A toolchain where solo delivery keeps team-level discipline. Speed comes from automation; safety comes from keeping a person in charge of what matters.
Stack
- MCP / hooks
- agentic commands
- quality gates
- cross-repo mapping
- review passes
- test + verify loops