Earlier this week I planned a significant upgrade to synthesis-skills, my open-source collection of skills for AI coding agents, and used the work as a live test of synthesis engineering itself. I did the designing and deciding, then assigned models from two vendors to deliberately different roles: one executed my plan; the other attacked the result. The releases are public. The two failures came from my own project records. Together they define the Built/Deployed Gap, a failure class teams can test for in their own systems. I wrote this account for CTOs and engineering leaders evaluating what disciplined AI-assisted engineering actually involves, and for practitioners who want the specifics.
The setup: separation of powers, by design
The upgrade itself, in plain terms: I added a review process that records every finding and how it was resolved, staleness checks that flag project notes nobody has kept current, and release checks that verify a release contains exactly the files it claims to, with each release’s acceptance manifest committed beside the code. Eight releases, plus two same-day patch fixes, across three days.
I wrote the plan with Claude Fable 5, Anthropic’s newest model, because that’s where I wanted design depth. The plan fixed the release order and the constraints I hold all my AI-assisted work to. Four examples: reproduce a defect in a failing test before fixing it; record any omission where the next reader will see it; never let “the checker passed” stand in for “the change is correct”; and drive every review finding to a terminal state.
Execution I handed to OpenAI’s Codex agent running GPT-5.6 Sol at maximum reasoning effort, unattended against that written plan. It worked release by release from mid-afternoon until past midnight, and picked the thread back up the next morning: reading the project files to reconstruct where things stood, opening pull requests, running the checks I’d specified, writing progress notes to a shared record file that I and both models could read. I supervised through short reports, and the decisions stayed mine alone. One of them I approved from a train, in two words, and the tooling paused at that gate until “I approve.” was captured verbatim in the record, because in this discipline an approval someone paraphrased is not an approval I gave.
Why two vendors instead of one? Not redundancy, and not hedging. Models from different vendors fail differently, and the practice turns that difference into coverage. The executor couldn’t see the designer’s conversation, so my written plan had to actually contain the plan. Handing work to an agent that cannot ask what you meant is the fastest honest test of whether your documentation says what you think it says. And the reviewer that came later arrived with different questions than the executor had asked itself, which is precisely where the findings came from.
What the cross-review caught, and the name it earned
When the execution finished, I turned Claude Fable 5 around into the reviewer role and ran the adversarial review, using the very review protocol this upgrade had shipped, which is the kind of recursion I enjoy. The upgrade held up. And the review surfaced two serious gaps that share one shape.
A control that shipped but never switched on. One of the new safety checks, a commit-time gate, had a complete test suite, all green, and had never actually run in production, because its one activation setting was missing on the machine it was meant to protect. Every commit for days had sailed past a control that was politely announcing its own absence. The tests proved the gate worked when configured. Nothing anywhere proved it was configured. I had written before that a green config is not a working agent; this was that lesson catching my own tooling.
A record that was safely stored and quietly invisible. The upgrade’s own project history (decisions, findings, evidence) had been faithfully committed and pushed to a side branch, and never merged into the main branch that every other session of work actually reads. Backed up: completely. Part of the record anyone consults: not at all.
Both defects lived beyond the checks that had been run: one in activation, the other in integration. I call that boundary the Built/Deployed Gap, and once you have the name you see it in familiar forms: an alert rule defined but not enabled, a backup never restore-tested, a feature flag whose call site moved. The checks in this upgrade missed the gap because they stopped at build and branch state. Deployment probes, restore tests, live controls, and independently derived review extend the surface.
An independently derived review adds a second path for asking the questions the first checks omitted. Both gaps were repaired and re-verified the same day. The newly activated commit gate’s first act in production was to refuse a commit from the session that had switched it on. I enjoyed that result: the refusal was evidence that the control enforced its rule even against its author.
What the pattern gives you
The result: eight public releases in three days, v4.50.0 through v4.57.0, each with its changelog entry and pull request in the open repository; fifty-three of fifty-four review findings driven to verified repair, and the last one recorded as an open design decision rather than forgotten. The review caught defects beyond the existing checks, and both repairs landed the same day.
The full workflow is open source in my tooling. Three practices from this exercise make the operating model concrete:
Write the plan so the executor cannot depend on your unwritten intent. An agent without access to the author’s chat tests whether the written plan can stand on its own. Documentation gaps surface before execution makes them expensive.
Rotate in a reviewer with different context, and give it artifacts before explanations. Starting from the same chat and assumptions risks reproducing the author’s blind spots. A reviewer that derives its own inventory adds questions the executor did not ask.
Keep the record in files, not in chat. Chat history is a scratchpad tied to one tool’s context. Repository files let a second model, a colleague, or future you pick the work up, verify it, and challenge it. The record is the project.
I designed this exercise, set its constraints, made every judgment call, and own its results. That is the shape of the discipline, and it doesn’t bend with the number of models involved. What the models multiplied was how much of my own standard I could enforce at once. The full practice, from the Direction Dynamic to the review protocol this upgrade shipped, is documented at synthesisengineering.org, and every skill named here is in the synthesis-skills repository under CC0. Pick one control that passed in CI and verify, from the running system, that it is enforcing what you think it is.