Orchestrated Builds

I recently released a major feature at Boords over 14 rounds and roughly 125 commits. I didn’t write the implementation. Neither did my main agent session. Almost all of it was written by a model I never spoke to directly.

In You Don’t Need to See the Code I wrote about the shift from maker to manager. This post is about what happens when you push that further: the manager stops doing the work entirely and starts running a team.

The pattern lives in a skill called /orchestrated-build. Here’s how it routes work, and why.

Three tiers

Every request goes through the same chain:

1. The orchestrator is my main agent session, running GPT-5.6 Sol (the most capable, and most expensive, model I run). It plans, writes briefs, makes design decisions, gates quality, and pushes. It does not implement.
2. Round managers are background subagents, one per feature phase or polish round. Each gets a written brief and owns its round end-to-end: explore the code, break the work into chunks, get them built, review them, commit.
3. Codex (running GPT-5.5) does the actual implementation. Managers hand it well-scoped chunks with exact file paths and reference implementations to mirror.

Reports flow back up the same chain. Codex returns diffs, managers return structured round reports, and the orchestrator turns those into decisions: push it, fix these three things, or ask me.

Why route it this way

Each seat in the chain plays to a different strength.

Sol is expensive and good at judgement. Burning it on writing CRUD endpoints is a waste; you want it reading review findings, spotting the design decision hiding inside a bug report, and writing the kind of brief that makes everything downstream go well. The brief quality determines the round quality, so the most capable model writes the briefs.

GPT-5.5 is fast, relatively cheap, and excellent at coding when given clear directions. Given a chunk like “add the sharing modal, mirror the one in Storyboards, here are the exact files”, it churns through it quickly. It’s the wrong model to hand ambiguity to, and the routing means it never sees any.

The managers exist for a less obvious reason: they keep the main thread open. Because rounds run as background subagents, my orchestrator session is free while a round builds. I can queue the next brief, triage a review, or answer a question about something else entirely. Without that layer, the expensive model sits blocked for an hour watching a progress bar.

Each manager also holds its round’s context. When a review comes back with findings, they go to the same manager that built the round, which still remembers why it made each choice. No re-explaining, no cold starts.

The review loop

Every round passes through three review layers before it reaches a human reviewer:

Layer 1 happens while building: the manager reviews each chunk itself, plus one read-only Codex review per chunk, and fixes findings before committing.

Layer 2 is the one that earns its keep. Before anything gets pushed, the orchestrator runs an independent review of the whole round diff: a fresh read-only pass with a targeted hunt-list, ending in an explicit SHIP or FIX verdict. On FIX, findings go back to the round manager with decisions attached (“gate everything on the flag, don’t relitigate”) and the loop repeats until SHIP. I re-run the touched test suites myself too, because “all tests pass” in a report is a claim, not evidence.

This independent layer caught genuine blockers in nearly every one of those 14 rounds. Chunk-level review keeps missing a category of bug: each chunk is fine, but the seams between them aren’t. Only a whole-round pass sees the seams.

Layer 3 is Greptile, which reviews the PR after every push. This adds two kinds of protection the first two layers can’t. It’s a different vendor’s model, so it has different blind spots than the ones that built and reviewed the code. And it sees the whole PR rather than a single round’s diff, so it catches drift between rounds. Anything Greptile finds that both pre-push layers missed becomes a new check in the layer 2 hunt-list, so the gate gets stricter over time.

Three layers sounds like a lot of process. In practice layers 1 and 2 are minutes of model time, and layer 3 runs while I do something else. The alternative is me reading every diff line by line, which is slower and, honestly, worse at it.

The models are slots, not the point

I’ve named specific models here because that’s what I run today, but the structure doesn’t care. There are three slots:

• A judgement seat: whatever model is currently best at planning, review, and design decisions. Today that’s GPT-5.6 Sol. It’s also the most expensive seat, which is fine, because it produces the fewest tokens.
• An implementation seat: whatever is fast, cheap per token, and strong at directed coding. Today that’s GPT-5.5.
• An outside opinion: a model from a different vendor than the first two, so its failure modes don’t overlap. Today that’s Greptile.

When the next generation of models lands, the slots stay and the names change. The routing logic (expensive judgement at the top, cheap volume at the bottom, independent review before anything goes out) is the part worth keeping.

This is the same shape as any functioning engineering team, which is probably not a coincidence. A tech lead who writes every line is a bottleneck. A team with no code review lets bugs through. The org chart predates the models by some decades; we’re just rediscovering it at lower cost.

Caveats

This is heavyweight machinery, and most tasks don’t need it. The first routing decision is whether to orchestrate at all:

A single small fix goes faster done directly, no orchestration. The skill itself says so, because early on I kept spinning up managers for one-line changes and it was slower every time.

It also lives or dies on brief quality. A vague brief produces a confident manager building the wrong thing at speed, which is a worse outcome than building it slowly yourself. The time I used to spend writing code now goes into writing briefs and triaging review findings. That trade is worth it, but it is a trade.