Autonomous Coding Agent Not Merging Pull Requests? Count Merges

If your autonomous coding agent is not merging pull requests, check the queue before you check the model. In our experience the usual cause is work that was never winnable: the task points at a file the agent may not touch, or names the wrong files. The agent looks busy while it discovers this, one task at a time. The only number that tells you the truth is merges.

We ran into this in September 2026 on our own coding lane. This post covers what the dashboard showed, what had happened underneath, what we changed, and a check you can run on your own setup this week.

Why does a coding agent look busy and merge nothing?

A coding agent looks busy because every step before the merge produces visible output: a claimed task, a prepared workspace, model calls, a diff. None of those steps prove that a reviewable change reached the main branch. A run can log all of them and still end with nothing to review.

Our September 2026 cycle is the clean example. The coding lane had been down for a while because of a credentials outage. When that was fixed, the first healthy cycle ran for several minutes. It claimed a batch of tasks, made real model calls, produced real diffs in places, and logged a normal-looking finish.

Every task in the batch ended on hold. No pull request was opened. No merge happened. The health check said the lane was fine, and it was, in the narrow sense that it was running. A lane that is running and a lane that has shipped are different facts.

A second cycle that same week repeated the shape. Part of the batch burned time on the same forbidden file twice. The rest did real work, but the independent verifier refused one patch because the file that held the actual problem was not in the diff. Busy, again, with a thin result.

What was actually going wrong?

The tasks were unwinnable at the moment they were queued, not when the agent tried them. Two kinds of failure sat underneath, and both came from a scope fence: the list of paths an agent may change, which we use to keep a coding agent inside the work it was asked to do.

The deliverable was a forbidden file. Several tasks existed to change a file the fence excludes on purpose, such as a workflow definition or an agent’s own manifest. The fence was right to refuse. The task should never have reached the agent. The agent spent a full workspace setup and a full run to learn what a one-line check at queue time would have said.

The task named the wrong files. One task declared a set of files it expected to change. The agent, correctly, edited a different file where the real fault lived. The step that opens the pull request then compared the diff to the task’s file list, found no overlap, and refused. The agent was right and the task text was wrong, and the system converted good work into a hold.

In both cases nothing was broken in the model. The agent did what a careful engineer would. The queue fed it work that could not end in a merge.

A wider look at that month’s escalations to a human pointed the same way. Most were mechanical: workspace collisions, the scope fence, the verifier running out of room or finding no change, and patches that failed their own tests. Only a minority were a case of the task lacking information. The usual advice, “write better specs,” addresses the smallest slice.

Why is activity the wrong metric for an AI coding agent?

Activity measures effort spent. Merged changes measure value delivered and survived review. Research on AI coding output keeps finding a gap between the two. An agent can be prolific at the activity end and thin at the merge end, and the dashboards most teams build by default sit at the activity end.

Two public findings frame this.

In its 2025 State of AI-assisted Software Development report (published September 2025, nearly 5,000 technology professionals surveyed), Google Cloud’s DORA research group found that AI adoption now has a positive relationship with delivery throughput, but still a negative one with delivery stability. Its summary line: AI “doesn’t fix a team; it amplifies what’s already there.” More change volume, without strong checks downstream, shows up as instability.

In March 2026, the evaluation group METR had four maintainers from three open-source projects review 296 AI-written pull requests that had passed an automated benchmark. Maintainer merge decisions came out about 24 percentage points below the automated grader’s scores, after adjusting against merged human patches. METR is careful to say this is not a hard ceiling on capability, since the agents received no feedback and could not revise.

Read together: passing a machine check and being merged by a person are separate bars, and DORA’s own measures sit on the merge-and-deploy side, not the “how many runs” side. DORA defines throughput by change lead time, deployment frequency and recovery time, and instability by change fail rate and deployment rework rate. None of the five counts agent runs.

Activity signal (easy to log)	Outcome signal (what counts)
Tasks claimed this cycle	Changes merged this cycle
Model calls and minutes of run time	Time from claim to merge
Diffs produced	Diffs a reviewer accepted unchanged
Lane health check green	Reverts or fixes needed after merge
Tasks “completed” by status	Merged commit is on the main branch

What fix held?

Three changes held, and one is still open.

We changed what the lane reports. Merges per cycle, with holds and their reasons next to it, now sit above any health indicator. A cycle with zero merges and a green light is read as a failed cycle with a working machine, which is what it is.

We read hold reasons as a queue problem. A hold caused by the fence, or by a wrong file list, is information about the task, not the agent. Counting them by cause told us where the inflow was bad. Re-running the agent would have changed nothing.

We keep tasks small and checkable. The ones that merged were small, scoped, and carried a command that proves the change. That is the same shape we describe in our write-up of an AI coding agent that opens pull requests.

The open item: the upstream fix. A task should be rejected when it is created if its only target is a path the fence forbids, and its stated file list should be checked against its own description before it enters the queue. That rule is designed and filed. As of this writing we have not confirmed it live, so we are not calling this closed. Until it is, the agent still occasionally pays for a task it could never win.

One more trap, which we also met: resetting a stuck task does not mean the next cycle picks it up. The lane took older queued items first, so the reset tasks sat. If you reset, check that the thing you reset was the thing that ran.

What can you check this week?

You can test your own setup in an afternoon. Pick the last full week of agent activity and answer five questions from the logs.

1. How many changes merged, and how many did the agent claim? Put the two numbers side by side. If you cannot get the first one from your tooling in a minute, that is finding number one.
2. For each task that did not merge, what stopped it? Sort by cause, not by agent. Fence, wrong file list, failing test, collision and missing information are different problems with different owners.
3. Could the stopping cause have been known at queue time? Be strict. A forbidden path is knowable on day one. A failing test is not.
4. Does your health check measure running or shipping? If a cycle can be green with zero merges, add a second line that is red in that case.
5. For merged work, is the commit on the main branch? Not a branch, not a status label. The commit itself. We cover that check in why a status field is not evidence.

GitHub’s own documentation for its coding agent makes a related point from the other side: the agent can open a pull request, and repository rules or branch protection can still block it. A block there is a design feature. Make sure your dashboard shows it as a block, not as quiet activity.

Where does this fit?

Measuring merges is part of running coding agents as an operation, not a demo. Someone has to own the queue, the fence, the hold reasons and the one number that says whether the week produced anything. That is the work in an AI Workforce Sprint: we set up the agent, the fence and the reporting against your repositories, fixed price and fixed scope, and hand over the code and documentation.

Our own record is public on the agent fleet proof page, including what has gone wrong and how it was handled.

A tomte, our word for one production agent with one defined job, earns its place by what reaches the main branch, not by how many hours it ran. If you have an agent that stays busy and ships little, Start async. Send us the repository, the last week of logs and what you expected. We reply within one business day, and there are no meetings.