The Saved Time Piles Up Between Rounds

Coding intervention is down to half a round per request, yet delivery improved only ten to thirty percent. That time sits in the gap before anyone picks up the artifact.

Here is what happens when you hand the coding to an AI: it delivers a version within the hour, and then nothing happens. The reviewer is in another meeting, the PM is on another request, and the code sits in the channel for three days. The AI could have kept working the whole time, but it does not know it may start — nobody has looked at the last version yet.

By the end you can answer:

• Why didn't faster coding turn into faster delivery?
• How do you measure waiting instead of guessing at it?
• When a request has gone quiet for days, when should you nudge it and when should you not?

Coding is no longer the bottleneck

Start with a measurement. In one team's mature business scenarios with a reasonably complete harness, human intervention in coding was down to about 0.5 rounds per request — people almost never had to step down into the code. At that level of investment, if the delivery cycle were mainly decided by execution, delivery should have gotten several times faster.

It got ten to thirty percent faster. Across 39 shipped requests, split into four complexity tiers, every tier improved, but nowhere near several times over; delivery still runs in days and weeks tmall-efficiency.

So where did the saved time go? The answer is in the unit of measurement. R&D used to be viewed by stage — requirements, development, testing each with an owner. Once the AI carries a request from solution to deployment, people work in rounds of "state a request → the AI delivers → accept or correct," and whoever picks it up can be any role. People also run several requests in parallel: when the AI finishes, the person who should pick it up may be somewhere else entirely.

So the unit has to refine from stage to round. A round starts with a human input and ends when the AI delivers and a person picks it up with the next input:

cycle = Σ(each round: time the AI spends + time until the person returns) + external waits

The two halves of that formula belong to two different kinds of work. The time and round count on the AI side belong to the harness and business knowledge — whether a round lands accurately, how many rounds it takes, whether people still have to descend into the code depends on the model, the toolchain, the skills, and the accumulated business knowledge. The time until people return, plus external waits, belong to collaboration — who needs to judge the artifact, when they pick it up, whether it is worth pushing right now depends on how the organization arranges pickup.

Both halves decide the cycle. Optimize only the first and you get the numbers above.

Measure the waiting: flow efficiency

Without a number, the discussion stalls at "feels busy lately." Here is one that needs zero reporting and can be computed daily:

Flow efficiency = active days ÷ elapsed days. A request counts as "moving" on any day with a message, an AI reply, or a tool call. Consecutive days with none mean it stopped.

A request that moved on seven of fourteen days has a flow efficiency of 0.5. Be careful about what it answers: it measures continuity of activity, not effective hours and not percent complete — but nobody has to fill anything in, it is computable every day, and it is the starting point for everything after.

With that number you can ask what determines the cycle. In the actual data, shipped requests split into low, medium, and high flow efficiency had median delivery cycles of roughly 22, 14.5, and 8 days; after controlling for complexity, change size, and when the group was created, flow efficiency had the largest absolute partial correlation among the candidate factors tmall-efficiency.

These are observational results. The sample is not random, and flow efficiency shares time information with the cycle, so you cannot call this causation, nor read the gap between groups as "the benefit of reminders." But it supports an actionable judgment: in scenarios where coding barely needs people anymore, squeezing execution further buys far less than compressing pickup waiting.

Silence is a clue, not a verdict

Knowing that waiting is the bottleneck, the instinct is "nudge when it has been quiet too long." There is a scar worth mentioning here: one team's first version watched only the number of quiet days and fired a templated message when the threshold hit. It was pulled fifteen minutes after launch — the person had said "let's look at it next week" the day before, and the system still came knocking today.

So silence is only an entry point for investigation. Before sending anything, reconstruct the last handoff: what artifact went to whom, what that person is still missing, whether there is a new arrangement.

The reconstruction narrows the scope in three steps:

First, who is it waiting on. Read the AI's last message before the silence. Of 261 quiet periods, the most common category was "waiting for a human response" at 66 percent — the AI had already submitted a proposal, code, or test report and needed a review, an acceptance, or a new instruction; the rest were missing materials, review or scheduling, permissions and environment tmall-efficiency. But that last message only preserves the moment the handoff started, not its outcome, so it is a clue to verify, never a nudge to send to a specific person.

Second, which stage it stopped at. "Waiting for a response" at the requirements-discussion stage and at the testing stage need completely different materials checked. If requirements discussion is classed as waiting on the business side, first check whether the PRD's business definitions and constraints are clear; at pre-release validation it may be permissions and environment — one real daily report recorded a request already in development that could not run pre-release validation because it lacked Arthas permissions. Asking "is development done?" misses the point entirely.

Third, what exactly is missing. Split by how much you know about what blocks the next step. A blocker has a confirmed obstacle (a missing permission that prevents validation, a missing business decision that prevents finalizing the design). A suspension has a delivered artifact but no visible continuation and no confirmed obstacle — what is missing is knowledge of the current arrangement: is someone handling it outside the channel, is there another schedule, or has nobody actually picked it up. The difference is not which request stayed quiet longer; it is how much you know.

The output of this step is not a nagging message but a handoff record with evidence: the latest artifact, the unfinished action, the relevant roles, the existing agreements.

Three channels in parallel, not escalating pressure

Once the record exists, it has to be organized by scope of collaboration. A specific problem can be followed up one to one; a single request's continuation may be spread across several roles; and one person also needs to see the overall progress of several requests. The three run in parallel:

The most important part of the daily brief is the filter on its first section, "needs your input": at most five items, each of which must be both fresh (within a day) and verified (the later context has been read and confirms nobody else has pushed it). "You haven't replied" is not "it is still waiting on you" — someone else taking over, the topic moving on, work having progressed are all invisible to rules and require reading the later conversation. Anything that cannot be verified should be left out rather than listed as already stale.

One discipline is easy to miss here: acknowledgement is only a receipt, picking it up is a transfer of responsibility, and only actual resolution counts as solved. The three lead to different follow-ups — an acknowledged item still needs watching, a picked-up item stops being nudged, a resolved one is closed, and closing needs evidence. One replay revealed another way to miss it: the same problem was raised repeatedly, the person it was reassigned to never took it, and yet other topics in the channel were lively — so the timer is set on the problem, not on the channel.

When has it actually paid off

Evaluating the effect takes two steps; you cannot jump straight to the end.

First, check whether the handoff record shows effective progress: materials completed, decisions made, acceptance concluded — recorded separately from receipts, responsibility transfers, and new schedules. Not every reply counts as a benefit.

Then check whether that progress was caused by the reminder. Even when progress appears, it may simply be the schedule arriving or work finishing off-channel. Answering that requires requests left un-nudged over the same period as a control.

This is the step most often skipped, and skipping it means mistaking luck for capability. The same team's reference numbers: of 261 quiet periods, 53 percent lasted two or three days and 32 percent four to seven days; among those labeled "waiting for a human response," 64 percent resumed activity on their own, with a median recovery of 3 days and three quarters within 5 days tmall-efficiency. Since most waiting resolves itself, any claim that a reminder worked has to subtract that natural recovery first.

That team is notably restrained about it: the mechanism for detecting, triggering, and closing waiting items exists, but there is no evidence yet of how much it shortens the delivery cycle — the next step is a same-period control to see whether the benefit justifies the added interruption. That self-limitation is more credible than a flattering percentage.

The cost and the check

This approach requires every request to have a traceable activity record (who said what when, what was delivered) and requires reading later conversation to verify — rules alone cannot detect "someone already took it." For an internal script that runs once or twice, the overhead is not worth it.

The check: pick a request that has been delivered but not accepted, and ask three questions. Can you say whether it is currently a blocker or a suspension? Can you say what the last handoff delivered, and to whom? If you wanted to push it now, would you know who to ask and what they are missing? If all three draw a blank, your bottleneck has probably already moved off the execution side and you have not noticed.

The conclusion is therefore clear: execution and collaboration have to change together. The harness makes artifacts reliable and automatically continuable; collaboration gets artifacts into acceptance, decisions, and subsequent execution in time. Do only the former and the local speedup stays local. Real delivery capability means the request never sits idle in anyone's hands.