Guardrails That Make Agent-Written Code Safe to Merge
The harness is the scaffolding in your repository that an agent works inside, so every session inherits your standards. You will build one.
Full day · Three-hour edition available
Engineers and technical founders using coding agents on real projects.
Bring a laptop with Claude Code, Codex, pi or a comparable coding agent installed and authenticated. Bring a repository you actually work in; the final hour installs the harness in it, and a sample codebase is provided for anyone who cannot.
A founder spent around eight weeks of his spare time adding 349,000 AI-generated lines to a community platform we had built. Our brief was to make it production-ready and ship it. On the surface it worked. Underneath, anyone signed in could read strangers' private chats, and the tests that came with it passed. Three of us could not review our way through it. At that volume, reading harder stops being a strategy.
He kept building while we refactored. We had two jobs at once: rein in what was already there, and stop it happening again.
This is not a prompt-engineering workshop or a tool demo.
Agents generate faster than any team reviews. What piles up in that gap is cognitive debt, verification debt and architectural debt, and none of it shows up in a diff. The harness is the scaffolding in your repository that an agent works inside, so every session inherits your standards. You will build one. Five layers.
Repository instructions every agent session picks up, whichever tool it runs in.
Deterministic enforcement (custom analyzers and lint rules, strict type checking, post-edit and pre-commit hooks, CI that blocks the merge) so your rules live in machinery the model cannot argue with.
A task ledger that governs context as much as work: one agent implements, another reviews, consequential changes wait for your approval, and each agent gets enough context to do its job and not so much that it starts making tests pass around its own gaps.
Model routing that sends each task to the cheapest model that can do it, which is a cost decision as much as a quality one.
Verification the model doesn't grade: tests written from the spec by a session that never saw the code, a call to every endpoint as every kind of user, and checks that every balance matches its transactions.
You spend the day deciding where the model may go, then letting it go there fast.
You will wrap a deliberately vibe-coded codebase in these controls, layer by layer, and watch each one surface a defect the last one missed. The defects are the ones we hit on that project, generalised so they land in any stack. The last hour is your own repository.
Every merge faces one test. Your phone wakes you at three in the morning, production is broken, your AI provider is overloaded. Can you debug it half asleep? If not, it does not merge.
The engagement and what was underneath. Owners who became babysitters. A model's "all good" reports what it can currently see, so the validation loop has to be designed by people and kept independent of whatever produced the code. The three debts, plus identity debt. The Overload Rule as merge gate: if you could not debug a change half asleep, with production down and your AI provider overloaded, it does not merge.
Maximising the deterministic surface: every rule a custom analyzer, lint rule, type checker or hook can enforce moves out of prose and into checks that fail the build, with error messages written for the model. Then the prose layer: repository instructions agents actually follow, doc canon against agent memory, glossaries, recurring processes packaged as named workflows. Guarding the guard: hooks fail open. Lab on the hand-kept balance pattern.
CI that runs tests, lint and analyzers and blocks the merge; local hooks can be bypassed, CI can't. A test with every fix to code nobody fully owns, even with no suite.
One task ledger as the only active queue. Implement-then-review with the reviewer in a separate context. Approval gates on schema and money changes. Context as a governed resource. The reviewer catches some defects and the checks catch the rest: an agent reviewing an agent repeats its blind spots.
Deny, ask, isolate. Secret handling. Which actions are irreversible. The seed route: the model's answer to a fair need, and the engineer who decides otherwise.
Spec-first tests from a session that never saw the code; a call to every endpoint as every kind of user, with canary records; ledger invariants and a reconciler; client types generated from the API. Lab on access, money and contract drift.
Isolation, task ownership, merge order and linear history. Two agents green alone and red together, then fixed.
Cheapest adequate model per task, top model for review and judgment. What to trust (run logs, tool-recorded statistics) and what never to trust (a model's own account of what it did). Tool adapters for Claude Code, Codex, pi and others are taught here.
Sequencing the layers for a live codebase, floor first. The Overload Rule on your own next merge. Anyone who brought nothing works the seeded codebase.
Attendees bring their own agent (Claude Code, Codex, pi, etc.) and work one seeded codebase throughout, so each layer is felt against the previous one's failures. Every exercise breaks the thing deliberately before fixing it, so each control is earned rather than asserted.
Tell us what your team is working with and what should be different afterwards.