What first-pass verification rate measures

First-pass verification rate is the percentage of agent tasks that pass verification on their first attempt, with no rework and no human correction. It is the most useful number to track on an agent programme. Oddly, it tells you far more about how well you wrote the task than about how well the agent did it.

What exactly is being counted?

Each task gets one attempt and one verdict. An agent picks up a task, does the work, attaches its evidence, and the gate either accepts it or refuses it. If it passed the first time it entered verification, it counts. If it came back a second time, it does not count, even if the second attempt was good.

Two boundaries matter, and both are easy to get wrong. First, a task that was never verified does not belong in the denominator. If you include it, you are measuring coverage instead of quality. Second, a task the agent abandoned before attaching anything counts as a failure. Leaving it out makes the number look better in the exact case you most need to see.

Why does it measure the specification rather than the agent?

Because an agent that fails verification usually did what it was asked to do. What it was asked for was not what you wanted.

A person given a vague task will ask a question, or guess and mention the guess in stand-up. A model does neither. It picks whatever reading its context makes most likely, says nothing about the choice, and returns a confident answer. When the gate then refuses the work, the cause is nearly always a definition of done that did not say what "done" meant.

You can see this in practice. Swap the model and the rate barely moves. Rewrite the definitions of done and it moves a lot. The industry has reached the same conclusion from the other direction. Redis's 2026 context engineering survey found that 73% of practitioners say agents fail more often from broken context than from broken models, and 83% say fresh context matters more than more parameters.

How does it relate to change failure rate?

It is the same idea moved earlier in time.

DORA's change failure rate asks what share of deployments cause a problem in production. It is a post-release measure. It is a good one, but by the time it moves, the bad change has already shipped. First-pass verification rate asks what share of work is right before anything lands. It is the same question, asked at the gate instead of after an incident.

Asking earlier matters more than it used to. The 2025 DORA report found AI adoption improving throughput while having a negative relationship with delivery stability. More change is arriving, and more of it is failing. A metric that only fires after release tells you about those failures once they have shipped.

What counts as a good rate?

We are not going to invent a benchmark. Nobody has a defensible cross-industry figure for this yet. A number made up to sound authoritative would be worse than no number, because you would plan against it.

What we can say is how to read your own. The absolute value depends almost entirely on how strict your gates are. So you cannot compare it between two companies, and you can barely compare it between two projects. Watch the direction instead. A rate falling while throughput rises means more work is going out on weak specifications. A rate at 100% usually means the gate is not checking anything. Nobody reports that problem, because it looks like success.

Always read it beside cycle time. A high first-pass rate that costs three weeks of specification per task is not a win. Looking at both numbers together catches that, and either one alone does not.

How do you raise it?

By changing the input, because that is where the variation comes from.

• Write the done-test before the work, not after. A definition of done written after the output exists ends up describing the output.
• Make it something a check can pass or fail. "Handles errors gracefully" cannot be checked. "Returns 429 with a Retry-After header when the rate limit is hit" can.
• Fix the definition, not the task, when something fails. If a task fails twice on the same ambiguity, every future task built from its template will hit the same problem.
• Watch it per template, not only per project. The project average can hide one kind of work that fails constantly.

What does it not tell you?

Whether the work was worth doing. A task can pass its gate and deliver nothing anybody needed, and this metric will still count a pass. It measures whether the work matches a specification, so any gap in the specification is also a gap in the metric.

It also says nothing about escaped defects. Verification catches what it was built to catch. Anything else reaches production with a passing report attached. That is why reopen rate sits beside it as a headline metric. It is also why you should be wary of anyone who presents a first-pass rate on its own.

In Cognibl the rate is computed per project from the gate's own verdicts. It never comes from anybody's self-report, because a pass rate built from self-reports only measures what workers said about their own work.