Day 3 of 10

Author, do not apply

Day 3 of 10. The single most important rule in my setup is three words long.

Mohamed Mastouri Haddaji · 2026-08-17

Originally published on LinkedIn — read the original.

Author, do not apply.

An agent writes the change. An agent does not put the change into production. Those are two different permissions and they belong to two different actors.

Why the builder cannot be the shipper

There is an obvious version of this argument — separation of duties, four eyes, standard controls. That is not the version that convinced me.

The version that convinced me is that an agent that has just built something is the worst available judge of whether it works. Not because it is dishonest. Because it will verify using the same understanding it built with. If it misunderstood the problem, it will misunderstand the check in exactly the same way, and the check will pass.

Confidence is not the failure mode. Correlation is. The builder's verification is not independent of the build, and non-independent verification is theatre.

What that looks like in practice

Database changes are authored as migrations and executed by a human. Me. By hand. Every statement. Nothing an agent writes reaches the database on its own.

That gate has already paid for itself more than once. A proposed fix to the public leaderboard would have silently reopened a data-exposure hole that had been closed weeks earlier. No error would have been raised. Nothing would have thrown. It was caught in review, one step before it went in.

Code is deployed by the lane owner — never by the coordinator. The agent that asked for a change is never the agent that ships it. If the coordinator could both request and deploy, it would have a closed loop with no outside observer in it, and closed loops are where confident wrong answers live.

Nothing that touches the database goes live without me. gooolll.com sits under a production freeze, and the freeze is enforced by the process, not by hoping.

The objection, and the answer

The obvious objection is that this makes me the bottleneck. It does.

I think that is the correct place for the bottleneck to be.

Seven agents can carry an enormous amount of build, review, media and distribution — genuinely more than I could carry with a team of people, at a speed I could not match. What they cannot carry is the judgement about which risk is acceptable. That judgement is not a capability problem that will be solved by a better model. It is a question about consequences that someone has to own.

So the throughput of the system is bounded by how fast I can review SQL. And the blast radius of the system is bounded by the same thing. Those are the same number, and I would rather they were.

The version that generalises

If you take one thing from this article and nothing else from the series:

Separate the permission to write from the permission to apply, and put a different actor on each side.

That is true for agents. It is true for junior engineers. It is the reason code review exists at all. The only thing agents change is the speed at which the gap between those two permissions gets exploited — which is to say, they change it a lot.

Tomorrow: what the independent check is actually allowed to say. It turns out two answers are not enough.

Day 4: PASS, FAIL, UNPROVABLE NOW.