What an Agent-Run Sprint Actually Looks Like

Descriptions of agent-assisted development tend to be either a demo of one ticket or a vision of full autonomy. The shape in between — what two weeks of real work looks like when agents do a meaningful share of it — is more useful and less discussed.

The most visible change isn't speed. It's that the distribution of human time inverts.

Where the time goes

Before: most of the week implementing, with specification, review, and coordination filling the gaps.

After: most of the week specifying, reviewing, and deciding, with implementation as the gap-filler. The engineer's day becomes a sequence of context-switches between directing work and judging it — which is closer to a tech-lead's day than to an individual contributor's, applied at every level.

⚠️ That inversion is the part people find hardest, and it's rarely mentioned in productivity claims. Directing and reviewing is more cognitively fragmenting than sustained building, and some people find it substantially less satisfying. Both effects are real and neither shows up in throughput numbers.

The rhythm that emerges

Monday: specification-heavy. The scarce resource is well-specified work, so the week front-loads it. Tickets get written with acceptance criteria concrete enough to implement against, ambiguities resolved in one batch rather than discovered one at a time.

Mid-week: parallel work-in-flight. Several changes running at once, each in its own branch or worktree. The human's loop is: check what came back, review it, redirect or accept, start the next.

The constraint appears here immediately — a person can only meaningfully review so many changes a day. Work-in-flight gets capped to review capacity, not to generation capacity, and teams that don't cap it accumulate a queue instead of throughput.

Continuous: the escalation queue. Work that came back blocked, ambiguous, or wrong. This queue is the real signal about specification quality, and reviewing it weekly tells you more about your process than any velocity metric.

End of week: the integration problem. Individually correct changes that interact badly. More parallel work means more integration surface, and this is where the time saved on implementation partly returns.

What genuinely goes faster

• Well-specified, well-patterned implementation. The core claim, and it holds.
• Test writing, given a contract to work from.
• Mechanical refactors with a verification path.
• Investigation breadth — checking six hypotheses in parallel rather than serially.
• The boring long tail: the small fixes and internal tooling that never got prioritized, which is where a lot of the actual value shows up.

What doesn't

• Deciding what to build. Unchanged.
• Resolving ambiguity with whoever knows the answer. Still gated on their calendar.
• Reviewing. Human, serial, and now the constraint.
• Debugging genuinely novel problems in systems nobody fully understands.
• Cross-team coordination. Unchanged, and now a larger share of elapsed time.

→ The pattern: anything with complete inputs and a mechanical check got faster. Everything else is where the week now goes.

✅ What teams doing this well have in place

• A cap on concurrent work-in-flight, set by review capacity.
• A specification checklist that determines whether a ticket is agent-eligible, applied at triage.
• Small, single-purpose changes as a hard rule, because review is the bottleneck.
• An oracle for every task type — tests, type checks, schema validation — so iteration doesn't need a human.
• A weekly read of the escalation queue, treated as the primary process signal.
• Deliberate hands-on work kept for people, to maintain the ability to review credibly.

💡 The metric worth tracking

Not velocity. Elapsed time from "decided to do it" to "in production," and where within that the time sat.

That number captures whether the speedup reached delivery or just moved the queue. Teams that measure only implementation throughput report large gains and can't explain why delivery feels similar — the answer is usually that specification and review absorbed it.

The takeaway

An agent-run sprint isn't the same sprint faster. It's a redistribution: more time specifying and reviewing, less time implementing, with review as the new constraint and integration as the new time sink. Cap work-in-flight to what can be reviewed, front-load specification, keep an oracle in every loop, and measure elapsed time to production rather than throughput — because the gain is real and it lands somewhere other than where the demos suggest.