An AI coding agent that opens pull requests: the job, the fences

An AI coding agent that opens pull requests is a builder with a narrow job: take a written spec that someone has already locked, make the change on a branch, prove it with a stated check, and hand the result to a reviewer. It does not decide what to build, and it does not get to merge anything that touches money, secrets or its own rules.

We run one inside our own group. This post is the job description, step by step, and the fences that keep it useful instead of dangerous.

What does an AI builder agent actually do?

It does five things, in order, and stops when any of them fails. It reads a locked spec. It opens a branch. It makes the change inside an allowed set of folders. It runs a verification command the spec named in advance. It opens a pull request with the result written up.

That is all. The agent never picks its own work from a wish list, and it never widens the spec halfway through. A person (or a planning agent a person trusts) writes the spec. The builder only executes it.

A tomte, our word for one production agent with one defined job, is the right shape here. This tomte has one job: spec in, pull request out.

Step by step: from locked spec to pull request

1. The spec arrives locked. It names the goal, the files or folders in scope, the acceptance criteria, and one verification command. A spec with no runnable check is rejected at the door, because “looks right” cannot be audited later.
2. The agent claims the story. One story at a time, so two builders never fight over the same files.
3. It works on a branch. Never on the main line. Everything it does is a diff someone can read.
4. It stays inside the fence. Each repository has a list of folders the agent may touch and a list it may never touch. A change outside the fence is not submitted, it is held for a person.
5. It runs the named check. If the check fails, the story goes to a held state with the error text attached. The agent does not quietly rewrite the check until it passes.
6. A second agent tries to refute it. A separate verifier, told to assume the change is wrong, reads the result against the spec. The builder does not mark its own homework.
7. The pull request opens with a plain write-up: what changed, which check ran, what the verifier concluded.

Steps 4 and 6 are the ones people skip, and they are the ones that matter.

Where does a person still decide?

At the merge, for anything that can hurt. Our rule is that the builder may only reach the main line without a person when every gate holds: checks green, the change is small, it sits inside the fence, the verifier passed, a daily cap is not exceeded, and a kill switch is on. Anything touching payments, payroll, ledgers, authentication, deployment settings or the builder’s own machinery is excluded outright, however clean it looks. Those pull requests wait for a human merge click.

The deny list is deliberately over-broad. A false positive costs one person one click. A false negative is an unreviewed edit to code that moves money.

GitHub’s own documentation for its cloud coding agent lands in the same place. Its guidance is to review the agent’s work thoroughly before merging. If a repository requires approvals, the person who asked the agent to work cannot count as the approver, and by default the repository’s automated workflows do not run on the agent’s pushes until a person approves them, because workflows can be privileged and reach secrets. Sources for those points: GitHub Docs, reviewing pull requests created by Copilot, checked October 2026.

Why the fences matter more than the model

Because the common failure is not wild code. It is code that is almost right. In the Stack Overflow 2025 Developer Survey, 66% of developers named AI solutions that are “almost right, but not quite” as their top frustration, and more developers said they distrust the accuracy of AI tools (46%) than trust it (33%).

Almost right passes a casual look. It also passes tests written by the same agent. We cover that failure in detail in our post on AI pull requests that pass tests and still have bugs. The short version for this post: the fence, the pre-named check and the separate verifier exist so that “almost right” gets caught by a structure, not by luck.

The 2025 DORA report from Google, based on nearly 5,000 technology professionals, found AI adoption among software professionals at 90%, up 14% on the year before. Its framing is the one we work to: AI is a mirror and a multiplier. It boosts teams with solid practice and exposes the weak spots of fragmented ones. A builder agent multiplies whatever review discipline you already have.

What changed when we ran one

Three honest observations, as of October 2026.

• Small, scoped work moved faster. Stories that fit the fence and carry a runnable check are the ones the builder handles well: a new field, a reshaped report, a fix with a clear reproduction.
• Unfenced ideas stalled, correctly. Stories that wanted to cross into protected folders were held, which is the design working, but it also meant a person had to look at them.
• A vague spec produced a vague pull request. The builder is only as good as the lock on the spec. Most of our held stories trace back to a spec with a weak check, not to bad code.

We have not removed the person from the loop and we do not claim to have. We have moved their attention from reading every line to reading the verdict, the diff and the gate that held.

What would this cost as a Sprint?

A builder like this, scoped to one of your repositories, is an AI Workforce Sprint: from $9,500, fixed price, fixed scope, four to six weeks. It is built on your accounts and handed over with documentation, so you own the delivered code, data and documentation. The Sprint covers one working agent. The fence list, the verification commands and the merge rules are written with you, in writing, because those are the parts that decide whether the agent is safe.

It is built from patterns we already run in production, which you can see on the agent fleet proof page. It is not a promise that a builder replaces your engineers. For the first weeks, expect it to take the small, well-specified work and leave the rest to people.

For related reading on the cost side, see what an agent costs per task.

Start async

If you have a backlog of small, well-understood changes and no rule yet for who reviews what, Start async. Write to us about the repository and the kind of change, and we reply in writing within one business day. No meetings.