Why enterprises must rethink their software delivery processes for a world where agents and humans build software together.
The Process You Trust Was Built for a Different Era
Every mature software organization runs on some process. Be this Agile, SAFe, Scrum, or some homegrown hybrid, the Software Development Lifecycle exists for one reason: to coordinate human beings with potentially diverse skillsets doing knowledge work at human speeds. Sprint cadences, review gates, estimation rituals — all of it assumes that the bottleneck is human cognition, human communication, human coordination.
That assumption is no longer safe.
AI coding agents are not a future possibility. They are shipping code in production systems today. They are writing tests, generating data migrations, drafting architecture proposals, and refactoring legacy codebases. To top it all off, they are doing everything at speeds that make your two-week sprint feel like snail pace.
But here is the uncomfortable truth that most enterprises have not yet confronted: Existing SDLC processes cannot absorb this. Not because the agents are bad at coding — increasingly, they are quite good — but because your process has no concept of a non-human participant. There is no role in your RACI matrix for “autonomous agent.” Your sprint board is likely to be stuck “In Review” awaiting human judgement on AI produced results. There is no escalation path for “the agent made a reasonable architectural decision that no human reviewed.”
The question is not whether AI agents will participate in your software delivery. They already are, whether you have sanctioned it or not (can you realistically vow that your developers are not using ChatGPT on the side and copy/pasting code?). The question is whether you will redesign your process to make that participation safe, governed, and effective — or whether you will pretend your old playbook still applies and deal with the consequences.
The Spectrum of Adoption: From Copilots to Autonomous Agents
The transformation does not begin with autonomous agents writing entire features. It begins much more gently, and organizations that try to skip ahead will stumble.
Stage One: Copilots and Code Completion
Most enterprises have already taken this step, even if they haven't fully acknowledged its implications. Developers are using AI-assisted code completion in their editors. The AI suggests a line, the human accepts or rejects it. The human remains fully in control. The process does not need to change because the agent is, in effect, a very fast autocomplete.
This is the shallow end of the pool, and it is where your people should get their feet wet. Let them. Encourage it. Remove the procurement barriers and the security theater that prevents teams from experimenting. The productivity gains at this level are real but modest — typically 10 to 30 percent on raw coding speed. More importantly, this stage builds familiarity. Developers learn what AI is good at (boilerplate, pattern completion, test generation) and what it is bad at (novel architecture, subtle business logic, understanding why a decision was made three years ago).
Stage Two: Vibe Coding and Rapid Prototyping
The next stage is more interesting and more disruptive. This is where developers — or even non-developers — use AI agents to generate entire working prototypes through conversational interaction. Describe what you want. The agent builds it. Iterate through dialogue. In a single afternoon, you can explore three or four approaches to a problem that would have taken weeks to prototype by hand.
This is transformative for discovery and validation. Product teams can test ideas with real, running software instead of slide decks. Architects can generate proof-of-concept implementations to evaluate tradeoffs. The speed of learning increases dramatically.
But here is where organizations make their first critical mistake: they assume that the process that works for vibe-coded prototypes also works for production systems. It does not. A prototype built in an afternoon of conversational coding is an artifact of exploration. It has no test strategy. It has no security review. It has no consideration of operational concerns. And most importantly, no human has carefully reasoned through the design decisions — because the entire point was speed, not rigor.
Vibe coding is a superb tool for learning what to build. It is a dangerous tool for building what ships.
Stage Three: Guided Agentic Development
This is where the real transformation happens, and where your SDLC must evolve. At this stage, AI agents are not just suggesting code or generating prototypes. They are executing real development work: implementing features from specifications, writing and running tests, performing refactoring across large codebases, and making design decisions within defined boundaries.
The key word is "guided." Production-grade agentic development requires more structure, not less. The agent needs explicit guidance on architectural decisions. It needs constraints on what it can and cannot change. It needs review gates that are calibrated to the risk of what it is producing. And the humans in the loop need a process that tells them what to review, when to review it, and what authority the agent had when it made its choices.
This is the stage where your traditional SDLC breaks down completely — and where a new kind of process must take its place.
Plan, Execute, Review: The Eternal Loop, Reimagined
Strip away the methodology-specific jargon, and every SDLC in history reduces to three activities: planning what to build, executing the build, and reviewing what was built. Waterfall does it in large sequential blocks. Agile does it in small iterative cycles. But the core loop is the same.
What changes with agents in the mix is not the loop itself — it is who does what within it.
Planning: Where Human Judgment Remains Supreme
Planning is where intent is formed. What problem are we solving? What are the constraints? What tradeoffs are we willing to make? This is fundamentally a human activity, and it should remain one. An agent can assist — it can research prior art, analyze existing code, surface technical constraints, even draft proposals — but the decisions must be human. (On a side note, solidifying and capturing your intents, priorities, constraints and tradeoffs as well as how these change depending on timelines, sudden external factors, etc. in a form that agents can use to move forward with guided decisions is what "dark factories" are about and this is a substantially more difficult problem that we will not go into in this post.)
However, the form of planning must change. Traditional planning produces artifacts designed for human consumption: user stories, acceptance criteria, technical design documents. These remain valuable, but they are no longer sufficient. When an agent will be executing the plan, the plan must also be machine-legible. It must be specific enough that an agent can act on it without ambiguity, while remaining readable enough that a human can review the agent's interpretation.
This is a new skill for most teams: writing specifications that serve both human understanding and agent execution. It is harder than it sounds, and organizations that invest in developing this capability will have a significant advantage.
Execution: Where Agents Change Everything
Execution is where the transformation is most dramatic. An agent can write code, run tests, check for regressions, and iterate on feedback in minutes. A task that takes a human developer a day might take an agent fifteen minutes of wall-clock time.
But speed without governance is just fast chaos. The critical insight is that agentic execution requires a different kind of supervision than human execution. When a human developer works on a feature, you trust their professional judgment to make hundreds of small decisions: naming conventions, error handling strategies, which patterns to follow, when to refactor adjacent code. You review their output after the fact, and you catch the occasional mistake.
An agent also makes hundreds of small decisions. But the agent's judgment is different from a human's. It is broader in some ways (it has seen more code patterns than any individual developer) and narrower in others (it has no understanding of your organization's unwritten conventions, your team's preferences, or the political context of a technical decision). This means the boundaries of agent autonomy must be explicitly defined. Which decisions can the agent make independently? Which require human approval? Which are off-limits entirely?
The traditional SDLC has no mechanism for this. It assumes the executor is human and exercises human judgment. A process designed for mixed teams must make autonomy boundaries explicit and configurable.
Review: Where the Bottleneck Moves
In a traditional SDLC, review is a relatively contained activity. A human writes code over days, and then other humans review it. The review cadence matches the development cadence.
When agents execute at machine speed, review becomes the bottleneck. An agent can produce a day's worth of code in minutes. If every output requires the same depth of human review that a human-written pull request receives, you have not saved any time — you have merely shifted the work from writing to reading.
The solution is not to eliminate review. It is to make review proportional to risk. Low-risk changes — test additions, straightforward refactoring, boilerplate implementation — can be reviewed with a lighter touch or even auto-approved against defined criteria. High-risk changes — security-sensitive code, architectural shifts, public API modifications — require thorough human review regardless of who or what produced them.
This means the process in use must be able to classify the risk of agent output and route it to the appropriate level of review. This is not something most organizations have today, and building this capability is another important investment in the agentic transition.
The Autonomy Dial: One Size Does Not Fit All
Perhaps the most important concept in agentic SDLC design is that agent autonomy is not binary. It is not a choice between “fully autonomous” and “fully supervised.” It is a spectrum, and the right setting depends on context.
Consider the variables:
The task
Generating unit tests for a well-defined function is low-risk. Redesigning an authentication flow is high-risk. The agent should have more autonomy for the former and less for the latter.
The codebase maturity
A greenfield prototype can tolerate more autonomous decision-making. A regulated production system with compliance requirements cannot.
The team's experience
A team that has been working with agents for a year has calibrated their trust. A team just starting needs tighter controls until they develop intuition.
The organizational context
A startup iterating rapidly has different risk tolerance than a bank processing financial transactions.
The SDLC must be tailored against all of the needs that apply on the specific situation. It must provide a way to dial agent autonomy up or down based on the context of each piece of work. A rigid, one-size-fits-all approach will either be too restrictive (negating the productivity benefits of agents) or too permissive (creating unacceptable risk).
This is not a completely new dimension of process design. There is some limited precedent in traditional SDLC frameworks mostly around reviewing code guidelines tailored to the seniority of the code author. It requires thinking carefully about decision taxonomies: what kinds of decisions exist in software development, and for each kind, what level of agent autonomy is appropriate given the current context? In a similar way that senior engineers teach and trust their junior colleagues over time, humans must define the equivalent boundaries of “teaching and trusting” agents with tasks. Same as between seniors and juniors, those human and agent boundaries shift over time.
Starting the Transformation
If you are an engineering leader reading this and wondering where to begin, here is a practical path:
First, legitimize what is already happening. Your developers are using AI tools whether you have sanctioned it or not. Bring this into the open. Establish baseline policies. Remove unnecessary friction from copilot adoption.
Second, create safe spaces for experimentation. Let teams use agentic tools for prototyping, spike work, and non-production code. This builds organizational muscle memory and reveals your specific challenges and opportunities.
Third, audit your current process for human-only assumptions. Walk through your SDLC step by step and ask: "Does this step assume the executor is human? Does this review gate assume human-speed output? Does this approval process account for non-human decision-making?" You will find dozens of implicit assumptions that need to become explicit.
Fourth, design your autonomy model. Decide, for each category of work in your delivery process, how much independence an agent should have. Document it. Make it configurable. Expect to iterate on it and adjust as your teams build experience and as the models behind the agents get.
Fifth, invest in the new skills. Your team needs to learn how to write agent-legible specifications, how to review agent-produced code effectively, and how to calibrate agent autonomy for different contexts. These are new competencies, and they require deliberate investment.
The Teams of Tomorrow Are Already Here
The shift to mixed human-agent teams is not a five-year prediction. It is a present reality that accelerates every quarter. The agents are getting more capable. The tooling is getting more mature. The developers who learn to work effectively with agents will dramatically outperform those who do not.
But capability without process is a liability. An agent that can produce code at ten times human speed is only valuable if your organization can absorb, review, and govern that output. And that requires an SDLC that was designed — intentionally, thoughtfully — for the mixed team.
Your current process was a remarkable achievement. It coordinated complex human work and delivered real software. Honor it by recognizing what it was built for — and by building what comes next.
The enterprises that thrive in the agentic era will not be the ones with the most advanced AI models. They will be the ones that redesigned their processes first.
