My last post ended with a promise to dig into why Sprint Planning and Story Points are dead. That post argued that code is becoming a disposable medium and speed is the only advantage that compounds. If that’s true, then our current way of managing work is dead weight.
In my experience, sprints just turn into one long high-pace marathon. They give non-engineers an illusion of control. The board, the velocity chart, the standup – it’s a performance of progress, not a measure of it. We’re already living in continuous flow. We’re just pretending we aren’t, and paying the overhead of the pretence.
Sprints were the best tool we had for a constraint that no longer exists. So what replaces them?
The Fallacy of “Effort”
Story Points were already broken before agents entered the picture. Every team argues about what a point even means. Is it complexity? Effort? Time? Nobody agrees. Estimates are almost never right. There are always unknown unknowns that blow up the plan mid-sprint. And even though points are supposed to be team-specific, managers still compare teams by velocity as if it means something. We spend more time debating the number than doing the work.
In the Model-First world, the whole concept is irrelevant. The agent doesn’t get a headache from a complex refactor. If a task takes 10 seconds or 10 minutes, the marginal human effort collapses toward zero. We are moving from Time-Based Estimation to Compute-Based Budgeting.
Old World: “This feature will take two weeks.”
New World: “This feature has a bounded compute budget: a $50.00 token ceiling and a 100-iteration limit.”
The Self-Producing Loop
Sprints were designed to provide “focus” and “predictability.” But a two-week plan is obsolete before it starts when your velocity is measured in minutes.
The “Backlog” is no longer a curated list of tickets groomed by a Product Manager. It’s a constant feed.
- Customer support tickets, APM errors, and real-time telemetry are ingested by agents.
- A separate prioritisation agent triages that feed against a company-level directive: your goals, your values, your current strategic bets. It’s not reacting to whatever’s loudest. It’s filtering through what actually matters to you right now. A company in growth mode weights conversion experiments higher. A company post-incident weights reliability work higher. Same system, different weights. Humans can override the priority weights at any time.
- Agents generate PRDs, write the code, and push it through the full backpressure pipeline: security gates, deployment controls, blast-radius limits, canary thresholds.
The Super Sprint never stops. It doesn’t sleep on weekends. It doesn’t wait for a “Monday Planning” session.
If a bug is detected at 2 AM, fixed at 2:05 AM, and deployed via canary at 2:10 AM, that doesn’t fit in a two-week sprint. You’re either in the loop or you’re in the way.
Coordination at Machine Speed
The 2 AM bug is easy mode. The harder question: what happens when 50 agents are all pushing fixes at 2 AM with no human coordination? You get merge conflicts, cascading deployments, and feature interactions nobody planned for. Uncoordinated agents at machine speed is just chaos at machine speed.
This is where the backpressure architecture from my model-first post becomes critical. Deployment queues, blast-radius limits, automated rollback thresholds, canary gates that hold until metrics stabilise. The Super Sprint doesn’t mean uncoordinated chaos. It means the coordination is mechanical, not ceremonial. The standup is replaced by a deployment pipeline that enforces sequencing, isolation, and rollback automatically. No calendar invite required.
But mechanical coordination only solves the agent layer. Humans still need to coordinate too. Someone has to set the company-level directive that the prioritisation agent filters against. Someone has to decide the token budgets, the blast-radius thresholds, the boundary between tier 1 and tier 2. If three PMs are all adjusting priority weights independently, you’ve just recreated the coordination problem at a different layer. The Super Sprint doesn’t eliminate human decision-making. It compresses it into fewer, higher-leverage choices: setting the weights, drawing the boundaries, and reviewing outcomes. Concretely, that means someone is tuning the prioritisation weights when strategy shifts, someone is reviewing overnight deployment outcomes and adjusting canary thresholds, and someone is deciding which customer-requested features get promoted to the wider cohort versus pruned. The meeting isn’t gone. It’s just shorter, less frequent, and focused on policy rather than tickets.
There’s a subtler risk here too. The loud failures are obvious: merge conflicts, cascading deployments, broken canaries. The dangerous ones are silent. Agents optimising for short-term metrics while gradually fragmenting the user experience. Changes that pass every canary gate individually but compound into technical debt that no single test catches. Local optimisation masquerading as progress. This is why human review of outcomes, not just tasks, matters. The dashboard isn’t a scoreboard. It’s a diagnostic tool for detecting drift that no automated gate is designed to catch.
Planning is a Speed Tax
We used to spend hours in rooms sharing “opinions” and writing “proposals” because building software was expensive. We had to be sure we were right before we spent $100k in developer salaries on a feature.
That math has flipped.
If building and shipping a feature costs $2.00 in tokens and 5 minutes of compute, the meeting is more expensive than the failure. Stop talking. Just build it, ship it to 1% of users, and let the data decide.
But not everything is a $2 experiment. There are three tiers:
- Cheap to test, cheap to revert. UI copy, feature flags, layout changes. Full Super Sprint. Ship it, measure it, roll it back if it tanks. Users never notice.
- Cheap to test, expensive to revert. Data model changes, pricing changes, anything that creates user expectations. Ship to a tiny cohort, but with a human reviewing before wider rollout.
- Expensive to test, expensive to revert. Architecture, platform migrations, brand. This is where the meeting is cheaper than the failure. Humans plan this.
The Super Sprint owns tier 1 fully and accelerates tier 2. Tier 3 is where traditional product thinking survives. The human deciding “this needs eyes before it goes wider” isn’t bureaucracy – it’s just another form of backpressure. The same principle, applied at the product layer instead of the security layer.
There’s also a category of quality that metrics don’t capture in a canary window. Brand coherence, long-term UX consistency, the feeling that a product was designed with intention rather than assembled by a thousand independent optimisations. A/B tests can tell you which button converts better this week. They can’t tell you whether your product still makes sense as a whole six months from now. That’s a tier 3 concern, and it’s worth naming explicitly: the Super Sprint optimises the parts, but humans still own the whole.
Instead of “consensus,” we use A/B testing as the only valid opinion. If the metrics tank, the agent rolls it back before the meeting would have even been scheduled.
But What About…
“Who’s responsible when something breaks?”
Accountability in software is already a mess. When a bug ships today, whose fault is it? The dev? The reviewer? The PM? Everyone points fingers.
The Super Sprint actually makes accountability clearer. Every agent action has a log. Every deployment has a trigger. You can trace the full chain: this ticket came in, this agent picked it up, it passed these security gates with these parameters, the blast radius was set to X, the canary threshold was Y. If the bug got through, you know exactly which guardrail was misconfigured and who configured it. The policy is the responsible party. You don’t fix the code; you fix the policy that allowed the code to pass. Compare that to “someone merged a PR on Friday afternoon and nobody noticed until Monday.”
The flip side: if you misconfigure the guardrails, failures happen at machine speed too. A bad PR affects one deployment. A bad guardrail affects every deployment for hours. Fewer decisions, higher leverage per decision.
“What about token costs?”
The Super Sprint doesn’t need cheap tokens to work. It needs tokens that are cheaper than the employee who’d otherwise do the job. That bar gets easier to clear every quarter. Inference costs keep dropping and cheaper models keep getting more capable. Today’s frontier model is tomorrow’s budget model. A task that requires your best model today might run fine on a model that costs a tenth as much in a year, it just takes a few more iterations. The economic backpressure still matters. Token budgets per team, cost-per-deployment tracking, automated circuit breakers when spend exceeds thresholds. But it’s a dial you’re turning down over time, not up.
What a Day Looks Like
It’s Tuesday, 9:14 AM. You open your dashboard. Overnight:
A customer support ticket flagged a checkout bug on mobile Safari. An agent picked it up at 1:47 AM, reproduced it, fixed the bug, and wrote a regression test from the support ticket’s stack trace, ensuring this specific bug can never ship again. It passed through the security gate and deployed via canary. By 2:12 AM it was live. The customer got an automated follow-up before they woke up.
A customer emailed asking if they could filter search results by supplier. The system evaluated the request, determined it was scoped and low-risk, and an agent built the feature and deployed it to that customer’s account. By lunch, they’re using it. By end of week, you’re watching their usage data to decide whether to roll it to a wider cohort or prune it. Not every customer request survives. If usage is low, or if two customers asked for conflicting filters, the system flags it for a human product decision. The Super Sprint says yes fast, but it also says no fast. The customer didn’t file a ticket into a void. They influenced the product in real time, and it cost you $5 in tokens.
RUM data flagged that users were repeatedly abandoning checkout at the shipping options step. An agent analysed the session data, hypothesised the layout was causing confusion, built a simplified variant, and deployed it to a small cohort. By the time you see it on your dashboard, abandonment for that cohort has already dropped 12%. No one asked for this. The system noticed, acted, and measured – all before your morning coffee.
You haven’t written a line of code. Your job this morning is to review the PM’s experiment hypothesis, check the blast-radius settings on last night’s deployments, and adjust the token budget for the search team’s agents. They’ve been burning through their allocation on a complex migration.
There’s no standup. No sprint board. No “what did you do yesterday.” The system already knows.
Most companies aren’t here yet. Most agents still need hand-holding. Most codebases aren’t architected for autonomous deployment. Most organisations aren’t ready to trust a machine with a production deploy at 2 AM. But the direction is clear, and designing around two-week cycles today is designing around a constraint that’s already disappearing.
The Super Sprint is already running.