Waterfall taught us to marathon. Agile taught us to sprint. AI is teaching us to bolt.
For more than two decades, Agile has been the dominant model for software delivery because it matched the pace of human teams. Sprint planning, backlog refinement, estimation, daily stand-ups and retrospectives were not arbitrary ceremonies; they evolved because people need time to understand problems, coordinate with one another and turn ideas into working software.
Artificial intelligence changes that rhythm. As AI compresses delivery cycles, the sprint can begin to collapse into a bolt: a high-velocity execution cycle where planning, implementation, testing and review move through a much tighter continuous flow.
A bolt is not simply a shorter sprint. The important difference is that AI can perform much more of the production work between human decisions, analyzing requirements, proposing implementation plans, generating code, creating tests and preparing infrastructure changes without requiring a person to manually perform every step.
Humans therefore spend less of the lifecycle producing each artifact themselves and more of it defining intent, reviewing decisions and validating outcomes. That shift sits at the center of the emerging AI-Driven Development Lifecycle (AI-DLC): execution accelerates, but responsibility does not disappear.
The question changes with it. Instead of asking only “How do we build software faster?”, organizations increasingly have to ask “How do we govern software that now moves faster than our delivery process?”
Agile Was Built Around Human Throughput
Agile emerged partly as a response to heavyweight sequential development models. Rather than spending months attempting to define everything before implementation began, teams could work in shorter cycles, release more frequently and incorporate feedback as the software evolved, reflecting the Agile Manifesto principles around frequent delivery and adaptation.
The familiar Agile ceremonies support that model because they help synchronize people. Sprint planning aligns the team around upcoming work, backlog refinement clarifies what may come next, daily stand-ups coordinate progress, reviews gather feedback, and retrospectives give the team a regular point at which to improve its process.
Those activities are not primarily about typing code. They reduce the communication and coordination overhead that appears whenever groups of people need to understand a problem and work on it together.
The sprint fits naturally into that environment because human work has a cadence. Engineers need time to investigate unfamiliar systems, discuss designs, implement changes, create tests, resolve problems and review one another’s work before the next iteration begins.
For years, that assumption held reasonably well: people were the limiting factor in how quickly software work could move from intention to implementation.
AI-DLC changes that constraint.
An AI system does not necessarily need a developer to spend several hours manually converting every requirement into code before the next stage can begin. It can help analyze the requirement, inspect the codebase, propose a plan, implement changes, generate tests and react to failures in a much tighter loop.
Traditional human-paced flow
Plan ─────► Design ─────► Build ─────► Test ─────► Review
hours/days hours/days hours/days
AI-compressed flow
Plan → Design → Build → Test → Review
continuous executionThe lifecycle itself still exists. What changes is the amount of human production time separating its stages.
AI-DLC Changes the Bottleneck
The first generation of AI coding assistants made the change look smaller than it really was. AI appeared beside the developer as a faster way to complete a function, explain unfamiliar code or generate boilerplate, so the obvious productivity measure was how much faster somebody could write software.
AI-DLC extends the idea beyond code generation. AI can participate in planning, ask clarifying questions, examine dependencies, propose designs, implement changes, produce tests, prepare deployment work and help interpret the results, while humans remain responsible for the decisions that determine whether the work should proceed, which is the core difference between traditional SDLC and AI-DLC.
That distinction matters because typing code has never been the only expensive part of software development. Teams also have to decide what should be built, why it should exist, how it should fit into the system and whether the result actually satisfies the intended outcome.
AI can compress much of the mechanical production between those decisions. Human judgment is much harder to compress at the same rate.
That moves the bottleneck.
Traditional SDLC
Human decision
↓
Human production
↓
Human production
↓
Human review
↓
Next stage
AI-DLC
Human intent
↓
AI-accelerated execution
↓
Human review / decision
↓
AI-accelerated execution
↓
Human validationWhen producing another implementation, test suite or deployment plan becomes cheap, the scarce resource is no longer necessarily the ability to create one. It becomes the ability to determine whether the generated work is correct, appropriate and safe to accept.
Execution becomes abundant while decision-making remains constrained.
That is the condition that begins to make the traditional sprint feel unusually large.
From the Sprint to the Bolt
A sprint is defined partly by time. A team selects work and operates within a fixed iteration, often lasting one or two weeks, before reviewing the result and beginning the next cycle.
A bolt is better understood as an objective-driven execution cycle.
Bolt: A high-velocity, AI-orchestrated execution cycle that compresses planning, implementation, testing and review around a defined outcome.
A bolt might produce a feature, security improvement, database migration, refactoring initiative or infrastructure change. Some could take thirty minutes while others take several hours, because the defining characteristic is not a specific duration but the continuity of the execution, a rhythm that depends on restartable systems when work is interrupted mid-flow.
Consider a relatively contained software change. In a conventional sprint, a requirement might be refined, estimated, assigned, implemented, tested and reviewed at different points over several days, even if the actual coding work occupies only a fraction of that period.
An AI-assisted workflow can compress those transitions. The requirement can be analyzed immediately, relevant code located, an implementation plan proposed, changes generated, tests executed and failures fed back into another implementation attempt without waiting for a person to manually perform each intermediate step.
SPRINT
Requirement
↓
Planning
↓
Waiting / coordination
↓
Implementation
↓
Testing
↓
Review
↓
Outcome
BOLT
Requirement
↓
┌───────────────────┐
│ Plan │
│ Implement │
│ Test │
│ Revise │
└───────────────────┘
↓
Human decision
↓
OutcomeThis does not mean every piece of software can suddenly be delivered in minutes. Dependencies still exist, requirements can remain ambiguous, difficult architectural decisions still require thought, and some validation inherently takes time.
The change is narrower but still significant: the mechanical transitions between stages no longer need to consume the same amount of human time.
Once that happens consistently, sprint planning can move toward continuous objective definition, backlog refinement can become more closely connected to AI-assisted analysis, and story-point estimation can become less informative when implementation effort is no longer tightly coupled to human effort.
Daily coordination changes as well. Instead of primarily asking which developer completed which task yesterday, teams may spend more time reviewing what automated execution has produced, resolving ambiguity and making decisions that the system cannot responsibly make on its own.
Agile does not necessarily disappear under this model. The assumptions that determined its cadence begin to change.
Governance Becomes the Next Constraint
Every acceleration exposes the thing immediately behind it.
If implementation takes three days, a review process that takes half a day may barely register as a bottleneck. If AI compresses implementation and testing into twenty minutes, waiting two days for an architectural, security or compliance decision becomes the dominant part of the delivery cycle.
That is why the most interesting AI-DLC problem is not raw productivity. It is governance.
Enterprise software has always existed inside a wider system of control. Security teams establish requirements, architects define constraints, compliance teams need evidence, risk owners accept certain consequences, and organizations need records showing why important decisions were made, matching the emphasis on secure process evidence in the NIST Secure Software Development Framework.
Those responsibilities do not disappear when AI produces software faster. In many cases, faster production makes them more important because the organization can now generate far more change between traditional checkpoints.
A sprint-based governance process might assume that architectural decisions are reviewed at planning, security work is checked before release, and stakeholders receive visibility during scheduled reviews. That can work when meaningful changes arrive at roughly the same pace as those checkpoints.
Bolts create a different timing problem.
Execution speed
Bolt 1 ─► Bolt 2 ─► Bolt 3 ─► Bolt 4 ─► Bolt 5
Traditional governance
Planning ───────────────────────────► ReviewSeveral meaningful implementation decisions may now occur while the governance process is still waiting for its next scheduled meeting.
This is where organizations can make the wrong response. Adding more meetings simply recreates the old cadence around faster machinery, leaving AI capable of moving quickly but forcing it to wait for humans at every traditional checkpoint.
The stronger response is to change how governance enters the workflow.
Governance Has to Move With the Work
Project Management Offices, architecture groups, security teams and compliance functions are sometimes described as obstacles to rapid development, but their underlying purpose is not to make software slow. They exist to make important organizational decisions visible, repeatable and accountable.
AI does not remove that requirement. It changes the frequency at which those decisions may need to be made.
The practical answer is to make more governance executable.
Secure coding standards can become automated checks. Architectural constraints can be expressed as policies. Testing requirements can become pipeline gates, while documentation and traceability requirements can be validated before a change is allowed to progress.
Instead of asking a committee to rediscover the same policy for every change, the delivery system can continuously check the parts of governance that can be expressed mechanically.
AI-generated change
↓
Automated tests
↓
Security policy
↓
Architecture constraints
↓
Compliance checks
↓
Human approval where required
↓
DeploymentHuman approval remains important, but it can be concentrated where judgment is genuinely required rather than used as the implementation mechanism for every rule.
This also explains why version control becomes more important in an AI-compressed lifecycle rather than less important.
Git already sits close to the point where software decisions become durable. Changes become commits, features become pull requests, reviews create an audit trail, and deployment pipelines often begin from a version-controlled state.
A pull request in an AI-DLC environment can therefore represent more than “does this code compile?” It can become the point where the organization asks whether required tests passed, architectural constraints were satisfied, compliance evidence exists, traceability has been preserved and the appropriate person has approved the decision.
The approval is attached to the change itself rather than to a meeting scheduled several days later.
That is a much better match for bolts.
Humans Shift From Production Toward Decisions
AI-DLC is sometimes framed as removing humans from software development, but the more immediate change is a redistribution of human effort.
When AI can produce more of the intermediate work, people spend proportionally more time deciding what the system should do and whether the result is acceptable. Developers define intent and inspect outcomes, architects establish constraints, security teams encode policies, and product owners decide which outcomes actually matter, because accountability in algorithmic systems still has to land somewhere human.
AI can execute within those boundaries.
This does not mean humans can stop understanding implementation. A reviewer who cannot reason about the system cannot meaningfully validate a generated change, and an organization that produces software faster than it can understand that software has created a new problem rather than solved an old one.
The important shift is from performing every step manually toward owning the decisions surrounding increasingly automated execution.
Old constraint:
How quickly can people produce the work?
New constraint:
How quickly can people make trustworthy decisions
about work that can now be produced much faster?That is also why governance cannot simply become an approval button at the end of an AI-generated workflow. Effective human oversight requires enough context to understand what changed, why it changed, what evidence supports it and what consequences follow from accepting it, much like agent transaction boundaries require knowing which side effects already happened.
The role of the human becomes more concentrated around judgment, but that judgment has to remain substantive.
AI executes.
Humans remain accountable for what is allowed to become real.
Beyond Agile Means Changing the Cadence, Not Abandoning the Lessons
Agile was one of the most important changes in software development because it recognized that software is iterative. Shorter feedback loops were more useful than pretending every requirement and implementation detail could be known before development began.
AI-DLC does not invalidate that lesson. If anything, AI makes iteration cheaper because planning, implementation, testing and revision can happen more frequently.
What changes is the unit around which those iterations are organized.
Waterfall reflected an era where large amounts of work moved through long sequential stages. Agile compressed that work into sprints that better matched human collaboration and feedback. AI-DLC can compress parts of the lifecycle again because execution no longer depends entirely on people manually producing every artifact.
That is where the bolt fits.
Waterfall
Marathon
Long planned execution
↓
Agile
Sprint
Human-paced iteration
↓
AI-DLC
Bolt
AI-accelerated execution
↓
Human judgment
Governance and accountabilityThe organizations that benefit most from this shift will not necessarily be those capable of generating the most code. Code generation is only one part of the lifecycle, and accelerating it without accelerating validation simply moves the queue somewhere else.
The more important capability is building a delivery system in which rapid execution remains observable, constrained and reviewable. AI needs enough freedom to compress the mechanical work, while humans need clear points at which intent, architecture, security, risk and business outcomes remain under deliberate control, supported by OpenTelemetry signals when production evidence has to feed the loop.
Waterfall optimized for predictability, while Agile optimized for adaptability. AI-DLC increasingly optimizes for execution, which means the scarce resource moves toward trustworthy human judgment.
That is the deeper meaning of moving from sprints to bolts. Software can move faster than the processes originally designed to govern it, so the next evolution in development is not simply making AI execute faster; it is redesigning delivery so that human intent, governance and accountability can keep pace with AI-speed execution.
