Running autonomous AI coding agents in production

Most conversations about AI coding agents stall on the wrong question. Which model, which framework, which IDE. The question that actually decides whether an agent survives contact with a production repository is narrower and much less fun: what has to be true before its code reaches the main branch?

Our answer is four gates. The agent only works on issues a human assigned to it. A human approves its plan before any code exists. Review runs as separate passes before the pull request goes up. And no agent ever merges its own work.

We run a small fleet of agents on our own work, and one of them writes code. It opens pull requests in the repositories our business runs on, without a person starting it. That is not a demo environment and there is no undo button on it.

Three of those gates sit on the dev agent itself. The fourth applies to every agent we run. None of them is clever, and all four are the kind of rule that looks like bureaucracy right up to the first time it saves you.

Our dev agent never picks up work. It does not scan the backlog for something that looks like a fit. It does not claim unassigned issues and it does not take over anyone else's. It acts on one thing, and that is a GitHub issue a human explicitly assigned to it.

This sounds like a limitation on the agent. It is really a limitation on the blast radius. An agent that chooses its own work has an unbounded scope by definition, and once scope is unbounded you lose the ability to say what the thing was supposed to do in the first place. Every question you will later want to ask (why did it touch that file, who wanted this, was this in scope) resolves back to the assignment.

The assignment is also the cheapest permission system you will ever build. There is no policy engine to configure. Someone decided this agent should do this task, and that decision is visible in the issue history with a name on it.

The agent reads the issue, writes a plan, and stops. A human approves that plan explicitly: a 👍 reaction, an approved label, or a comment that says yes in so many words. Without one of those, no code gets written.

What matters is that the approval is a decision on the record and not an inference. An agent allowed to read agreement out of a conversation will eventually find it in a message that was not agreement at all, and afterwards nobody can point at the moment the work was authorised. A reaction, a label and an explicit yes all survive that test. A thread that trailed off does not.

This is also the cheapest place in the pipeline to stop the wrong work, and the only place where "should this exist at all" is cheap to ask. Reading a plan takes minutes. Reading the diff that the wrong plan produced takes far longer, and by then there is finished work on the table arguing to be kept.

What the gate does not do is make the work free. It moves the cost from writing to reading, and reading is where the human stays. That trade is the entire deal, and anyone selling autonomous agents as a way to stop thinking about the work is selling something else.

Before the pull request goes up, the work goes through separate review passes, each carrying its own question. Does the code do what the plan said it would. What risks does it introduce, security first. Is this something the next person can maintain.

Several passes, because one is not trusted. A single review asked to find everything tends to find whatever it noticed first and then write a confident summary. Splitting the work gives each pass one narrow question, and a narrow question is the only kind a reviewer answers well. A pass that comes back with nothing serious ends the review, unless the change touches something sensitive, so a clean change does not pay for ceremony it does not need.

Notice what review deliberately does not reopen: the decisions the plan already settled. That question belongs to Gate 2 and it is far cheaper there. Once a diff exists, "should this exist" costs a rewrite instead of a comment. An agent will happily implement a well-specified bad idea to a high standard, and the only cheap place to catch that is before it starts.

One rule applies across the whole organization and it has no exceptions. Agents do not merge autonomously, and they never merge changes to their own configuration. The merge happens outside the agent, after a human has approved that exact commit.

The configuration part is the sharp edge. An agent that can merge changes to its own config can widen its own permissions, and it does not need any intent for that to go wrong. One plausible-looking pull request that relaxes a rule, merged by the thing the rule constrains, and the boundary is gone without anybody deciding to remove it. Keeping merge outside the agent is what makes every other gate hold, because it is the one gate the agent cannot route around.

Note that this is not a statement about code quality. We would keep the rule even if the agent's code were better than ours. Governance is about who holds which privilege, not about who writes better functions.

The usual objection is that a strong pipeline makes the human merge redundant. Let the tests, the linter and the security scan decide, and merge on green.

That works for the failure modes CI was built for. It does not work for this one. CI checks the change against rules that already exist, and the change we are worried about is a change to the rules. A pull request that loosens a permission, drops a check or widens an allow-list passes every test in the suite, because nothing in the suite is written to object. Green means "consistent with the current configuration", and the current configuration is the thing being edited.

The same gap shows up in a smaller way on ordinary code. Tests confirm the behaviour somebody thought to specify. The question of whether this feature should exist has no test, and that is the question an agent is least equipped to ask about its own work.

Gates are only as good as the reviewer's ability to see what they are approving. On one of our projects, every pull request already gets its own preview environment, provisioned automatically in Coolify.

A diff tells you whether the code looks right. The preview tells you whether the thing works. Those are different questions, and with agent-authored changes the second one matters more than it used to, because the author cannot be asked "did you actually try it" in any meaningful sense. Making the running version one click away is the difference between review as a real check and review as a formality that scrolls.

The whole fleet costs us roughly $400 per month, about 8,500 Kč. Two people doing comparable routine work would cost us somewhere around 400,000 Kč a month. That is a factor of roughly forty-seven.

Read that number carefully, because it is easy to read it as something it is not. It is not a productivity measurement, and it is not a headcount plan. What it actually buys is the ability for a small team to spend its people on its own products instead of on routine internal operations. Pull requests sat in our repos for three months because they were never anybody's priority, and they were never anybody's priority because the work was real but small. That is exactly the shape of work the agents now pick up.

The number also leaves something out, and it is the same thing every vendor comparison leaves out. All four gates above spend human attention: a plan to approve, review findings to read, a merge to perform. That time is real, it scales with the number of agents, and it is not in the $400. Anyone who quotes you an agent cost without a review cost has given you half the equation.

If you are putting coding agents anywhere near a production repository, these four in this order:

None of this depends on which model you use, which is the point. The models will keep getting better and the review cost will keep going down, and not one of these four rules will get cheaper to skip.

If you want the version of this conversation that starts from your repositories rather than ours, that is what our AI platform work and our rollouts in large companies are for. If you are earlier than that and still deciding what agentic development means for your team, start with agentic coding and with how we think about governing what an agent is allowed to call.