Trunk-based delivery with an AI pair: what changed in our review gates

We run trunk-based development with agentic tooling in the loop: short-lived branches, an AI pair producing a meaningful share of the mechanical code, merges to main every day. The interesting part is not the tooling — every team has the tooling now. The interesting part is what happened to our review gates, because “the machine wrote it” turned out to change where we spend attention, not how much of it we spend.

What the tooling actually generates well

The honest inventory is narrower than the marketing and wider than the scepticism. Agentic tooling is genuinely good at work that is pattern-dense and judgement-light: database migrations from a schema diff, scaffolding for a new service that mirrors the last one, API clients generated from a spec, test fixtures, mechanical refactors across a hundred files, the fourth CRUD endpoint that looks like the first three. This is a real share of any codebase’s daily churn, and handing it over is pure gain — the work was never interesting, only necessary.

What it doesn’t

What it does not generate is judgement. Which trade-off the domain can live with. What the field should be called so the next engineer guesses right. Which feature not to build. Whether this dependency will still be maintained in three years. Where the security posture actually needs to be paranoid rather than conventional. These decisions live in context the tooling does not have — conversations with the client, scars from the last incident, knowledge of where the roadmap is going. Our delivery loop is built on that split: spec compression and assisted implementation for the mechanical, senior engineers on the decisions. The loop fails exactly when someone lets the tooling make a call it was never equipped to make.

The gates: same bar, regardless of author

Trunk-based delivery only works if the gates in front of main are trustworthy, because there is no long-lived branch to hide on. Ours do not care who — or what — wrote the diff:

  • Static analysis — linting, type checks, dependency and security scanning. Machine-written code fails these at least as often as human code, just in different ways: plausible-looking APIs that do not exist, subtly wrong error handling copied from a pattern that did not apply.
  • Eval suites — for AI-facing behaviour, regression evals in CI with pass thresholds that gate the release. A prompt change goes through the same gate as a schema change.
  • Human sign-off — a senior engineer reviews the diff for the things the machines cannot see: intent, naming, fit with where the system is going.

The rule is deliberately blunt: the same bar for machine-written code as for ours. The moment generated code gets a softer review because “it’s just boilerplate”, the boilerplate is where the incident comes from.

An engineer signs every merge

Every merge to main carries a named engineer’s sign-off, and the signature means something specific: I can explain every line of this diff, and I would have written it — or rejected it — myself. “The agent generated it” is not a provenance category in our incident reviews, because accountability cannot be automated. When something breaks at 2am, the question is who understood this change, and the answer has to be a person. This is the same principle we apply in client-facing AI systems — humans gate consequence — applied to our own pipeline.

What got faster, and what deliberately didn’t

Faster: the distance from an agreed spec to first running code. Migrations, scaffolding, fixtures and mechanical refactors stopped consuming senior attention. Branches got shorter because the mechanical middle of a change collapsed, which is exactly what trunk-based delivery wants.

Deliberately not faster: review, sign-off, and the eval gates. We did not shorten human review to match the new pace of generation — we protected it, because it is now the scarcest step in the pipeline and the only one that catches what the other gates cannot. Throughput improved because the mechanical share of the work shrank, not because the bar moved. If your AI adoption plan involves lowering the bar to realise the speed, you are borrowing the speed from your future incident budget.

This delivery loop — spec compression, assisted implementation, review gates, an engineer signing every merge — is how our Applied AI practice and our dedicated teams ship. We wrote about the production side of the same discipline in RAG: from demo to production. If you are working out what agentic tooling should change in your pipeline — and what it must not — book a technical call, not a sales call.