Ask an engineering team what unit they plan in and they will say the sprint. Two weeks, a backlog, a demo at the end. That container was designed around a hard constraint: a person can only type so fast, so you batch the work into a fortnight and check in. The moment agents started writing most of the code, the constraint moved, and the container stopped fitting the work inside it.
AWS made the point by renaming the unit. In its open-source AI Development Life Cycle, the sprint becomes a bolt, a cycle measured in hours or days, and the epic becomes a unit of work. The reasoning is blunt: if an agent collapses a three-week requirements analysis into three hours, forcing that output back into a two-week sprint is cargo-culting Agile rituals. The bolt is what you get when you size the container to the new speed.
A bolt is one loop, run tight
Strip away the vocabulary and a bolt is a single loop repeated many times a day: specify the work, generate against the spec, verify the result. Most teams already do all three. They just smear them across days until nobody can see which step is actually slow. Running bolts means separating the steps, making each one fast and explicit, and closing the loop before starting the next one.
The discipline lives at the front. A bolt starts with a unit of work small enough to specify in a paragraph and confirm in an afternoon. If it cannot be shaped that small, it is not a bolt. It is a unit of work that gets decomposed into several bolts first. This is the step teams skip, and skipping it is why their agent runs wander off into plausible but wrong territory.
Why the bolt exists at all
The bolt is a response to a real failure. Generation got cheap almost overnight, but writing code was never the bottleneck. Deciding what to build and trusting what came back is where the time goes, and neither of those got faster just because the typing did. A two-week sprint hides that mismatch. You start a pile of work, generate a mountain of code, and discover at review that the verification queue is where everything is stuck.
Shrinking the cycle to a bolt forces the mismatch into the open. You cannot start twenty bolts and verify six without noticing immediately. The short loop makes the real constraint, which is trust, visible every few hours instead of every two weeks.
What a bolt is not
A bolt is not "the same sprint, but faster." Speeding up a broken loop just breaks it faster. A bolt is not autonomous either; a human still specifies the work and still owns the verification gate. And a bolt is not a license to skip design. The spec is the design, compressed into a contract an agent can build against, which is the highest-leverage part of the whole cycle.
The AIDLC framing keeps this honest by making every phase produce a file-based artifact, so the requirements, the design, and the decisions stay auditable across the lifecycle rather than living in a chat window that scrolls away. The bolt moves fast, but it leaves a trail.
Where bolts fit
AWS's AI-DLC organizes work into three phases and runs the actual building through bolts, with the larger effort decomposed into units of work. You do not need to adopt the whole framework to use the idea. The takeaway travels on its own: the unit of planning should match the speed of execution, and when agents do the execution, that unit is hours, not weeks.
If you want the full mechanics of running bolts as a team, the intake gate, the roles, the work-in-progress limits, and the metrics that keep it honest, that is the members-only team playbook in the Lab. For how bolts sit inside the broader method, see the AIDLC method page and the breakdown of what changes when agents write the code.
The sprint was a good answer to an old constraint. The bolt is the answer to the one we have now.