Agile solved a real problem. When a person wrote every line by hand, you could not know if a plan was wrong until weeks in, so you batched work into short cycles, shipped a thin slice, and corrected course. The two-week sprint was a feedback machine tuned to human typing speed. It worked because the constraint it was built around, slow manual production, was real.
That constraint is gone. Agents generate in minutes what used to take days, and the bottleneck slid from writing code to deciding what to write and trusting what came back. AWS responded by replacing the sprint with the bolt in its AI Development Life Cycle, arguing that forcing three hours of AI-assisted work into a two-week ceremony is cargo-culting the ritual after the reason for it expired. Here is how the two actually differ.
Planning: story points vs specs
A sprint plans in estimates. You size stories in points, guess velocity, and fill a two-week bucket. The estimate is a proxy for how long a human will type.
A bolt plans in specs. The unit of work is whatever you can specify in a paragraph and verify in an afternoon, so the question is not "how many points" but "is this shaped tightly enough for an agent to build and a person to check." When typing time approaches zero, point estimates stop measuring anything real. The spec becomes the plan.
Cadence: fortnight vs hours
The sprint checks in every two weeks. The bolt closes every few hours. This is not a cosmetic difference. A two-week cadence lets an unverified pile of generated code accumulate out of sight until the review crunch at the end. An hourly cadence makes the pile impossible to hide. You start a bolt, close it, and only then start the next, which forces work-in-progress limits the sprint never needed.
Roles: author vs specifier and verifier
In a sprint the engineer is the author. In a bolt the engineer is the specifier and the verifier, and the agent is the author. The tech lead's job shifts from assigning stories to setting the repo conventions and agent rules that make generation predictable. The manager stops counting points and starts reading how many bolts cleared the gate and which ones bounced. The bounces carry the signal, because a bolt that fails verification twice is telling you the spec was weak or the work was too big.
Metrics: velocity vs verified throughput
This is where teams get burned. Sprint velocity counts what was produced. Applied to agentic work, that number lies, because generation is no longer the hard part. The honest metric is verified throughput: bolts that passed the gate and stayed green in production, watched alongside the escape rate of defects that slipped past every check. Rising throughput with a flat escape rate means the loop is healthy. Rising throughput with a rising escape rate means your gates are theater and you are shipping the productivity paradox in a faster wrapper.
What survives the switch
Not everything about Agile was a workaround for slow typing. Thin slices, tight feedback, and shipping to learn were always good ideas, and the bolt keeps all of them; it just runs them at a new tempo. What the bolt drops is the machinery that only existed because production was slow: the fixed fortnight, the point poker, the big-batch review at the end.
The practical mistake is treating the bolt as a faster sprint. Speed is not the feature. The feature is matching the unit of planning to the speed of execution, and building a verification gate strong enough to trust the output at that speed. Get the gate wrong and the short cycle just delivers unverified code sooner.
For the mechanics of running bolts as a team, see the members-only bolts playbook. For the spec side of the loop, start with what spec-driven development is, and for the bigger picture, AIDLC vs SDLC.
The sprint measured typing. The bolt measures trust. That is the whole shift.