You can't review your way to trusting an autonomous agent. Let prod be the reviewer.

I spent a morning checking our deploy pipeline against a reference design for shipping features with no human in the loop, going strategy by strategy. The verdict was duller than I wanted. DevBox, the repo, already had about two thirds of the strategies built: the test gates, the type checks, the migration guards, the merge queue. People who had never heard the phrase “autonomous pipeline” had assembled most of one by hand.

The piece that was missing was progressive delivery. We had no canary controller. Nothing in the repo could take a passing change, send it to a thin slice of traffic, watch how it did, and walk it back without being told to.

So I built one, and building it moved where I think the dangerous moment in a deploy lives.

The controller is a level-triggered reconciler. It holds no memory of what it did last. It wakes, reads the current state of a release flag, compares that to where the rollout should be, and nudges one toward the other. Stateless means a crash mid-rollout costs nothing. It comes back, reads the flag, and picks up from whatever is true now.

The signal it reconciles against is a single HogQL query run against PostHog that returns one scalar: healthy or not. If the scalar says healthy, the reconciler advances the flag to the next slice. If it does not, the reconciler rolls the flag back to zero. There is no dashboard a person watches and no Slack message asking for a thumbs up. The number decides.

The release flag is also a switch an operator can throw by hand, and it fails closed. If the flag cannot resolve a tenant, the feature is off, not on. A rollout that loses its footing degrades into the old behavior instead of the new one. That property is the reason I trust the thing to run while I sleep.

Then the tiering, because not every change earns the same autonomy. moneybox, which moves money, parks at the promote-to-prod step and waits for a person; socialbox merges itself the moment the canary stays green. The pipeline routes a change down one path or the other by how much damage a bad version could do before the metric notices.

Here is what the morning taught me. When an agent ships a feature with no one reading the diff, reviewing harder buys you nothing. A review can only check a guess about what code will do before that code runs. The thing that knows what the code really did is the canary, after it ran, read against real traffic. So the trust boundary slid forward, off the pull request and onto a metric that guards a small blast radius and reverts itself, with people kept only where the damage is too large or too quiet for a number to catch in time.

And that last clause is where it stops being comfortable.

Auto-rollback only catches what the metric can see inside the canary window, which is a few minutes of error rates and business counts. An exception trips the error rate, and the reconciler pulls the flag back to zero before the window closes. Corruption that accumulates one row at a time, with every request returning 200, never moves the scalar. It sails through healthy and is still healthy when socialbox auto-merges it to everyone. By the time the damage is large enough to register, the canary is long over and the change is everywhere.

Some harms have no leading indicator at all. There is no scalar that goes red the instant a feature starts leaking one tenant’s data into another tenant’s view, because nothing in the window separates that from a normal read. The metric is fine right up until a customer files the ticket.

And the tiering itself is a judgment the pipeline cannot make. Someone decided moneybox parks and socialbox does not. The reconciler does not know what a blast radius is. It knows which path a change was assigned to, and it was a person who read the code and guessed how bad a wrong version could get. Guess low, and a change that should have parked auto-merges on a green canary into a slice where the metric was never going to see the harm coming.