The Code Is Ready. The Team Is Still Figuring It Out.

Coding agents can finish a change before the team knows whether it should ship. Faster implementation is useful. But if the release still waits on the same people to understand what could break, we have accelerated only part of the work.

For engineering and QA leaders, that changes where the next hour should go. Another implementation may be easy to start. Resolving the question holding up a release may be more valuable.

A growing pile of completed implementations is not the same as a growing ability to ship them responsibly.

Green checks, unanswered question

Consider a hypothetical billing change. An agent updates the retry logic, the tests pass, and a reviewer approves the implementation. Then the QA lead asks: if a payment succeeds but the response is lost, could the retry charge the customer twice? The answer depends on more than the code in the diff. It depends on which request identifier survives the timeout and what the receiving service remembers. A test that fails the request before payment cannot settle what happens after payment succeeds.

This is not evidence of a defect. It is an unanswered release question. Mechanisms such as Stripe’s idempotent requests address repeated operations, but the team still has to verify its own integration uses the mechanism correctly. The QA lead flags that the team cannot complete this scenario before the planned release without help. Meanwhile, the coding agent is ready for its next task.

Where should the next hour go?

The easy response is to keep everyone busy. Start the next change while this one waits. That can be sensible for independent work. But if the next change needs the same overloaded specialist or unavailable environment, we are adding to the queue rather than clearing it.

More pull requests alone do not tell us whether the team has become more productive. The implementation count can go up while the release owner waits longer for answers.

There is some external evidence for this tension. In Madrona’s June 2026 survey, engineering leaders identified review queues and requirements clarity as bottlenecks. Many also reported faster delivery with stable or better quality. These are self-reported observations, not proof that every team has the same problem. The useful question is where our own work is waiting.

Calling everything in that queue “code review” makes it harder to answer. Reading an implementation, understanding a dependency, preparing a failure test, and deciding whether the result is acceptable are different jobs. Another reviewer cannot compensate for an environment that does not exist or a requirement nobody has settled.

Give verification time and ownership

Start with implemented changes still waiting for verification. Name the unresolved question, who owns getting it answered, and what they need. Make that work visible enough to allocate time to it.

In the billing example, the QA lead and engineering manager agree that the payments engineer owns answering the retry question, with the integration owner helping reproduce the lost response. They need evidence that the retry preserves the idempotency key and the payment records show one charge for that operation. The next billing feature can wait if it needs those same people. Independent work can continue. Keep the scenario as a repeatable check. Verification is shared work, not additional scope silently assigned to QA.

When verification cannot finish in time, the release owner must make the trade-off explicit: reduce scope, move the date, assign qualified help, or explicitly accept the remaining risk within agreed release requirements. A deadline does not turn an unverified change into a verified one.

Automation belongs here too. It should help investigate affected behavior and repeat meaningful checks, not just produce more tests that agree with the implementation. An agent can write code and tests around the same mistaken assumption. Verifying AI-generated code requires a way to challenge that assumption, not merely confirm consistency.

The evidence also has to describe the version being released. If the code changes after verification, someone needs to decide which results still apply. Otherwise, a green report can answer a question about yesterday’s candidate.

Measure what reaches a release decision

Look at how long implemented changes wait for verification, which questions keep returning, and where specialist time is repeatedly needed. Then compare that with rework and problems reaching users. Shipping faster by skipping necessary checks is not the improvement we are after.

The objective is not certainty or another approval ceremony. It is a release owner who can explain what was checked, what remains uncertain, and why the remaining risk is acceptable. That is the job of release verification.

Before asking the team to start more changes, look at what is already waiting to ship. The best use of the next hour may be answering one of those questions.