For years, our software delivery processes were built around the belief that: building and changing software was expensive. It took time to translate ideas into requirements, requirements into stories, stories into code, code into tests, and tested code into production. The friction was real, so we created a system optimized for knowledge transfer. Product wrote things down for engineering. Engineering handed off to QA. Design worked ahead. Architecture tried to predict. Management coordinated the gaps.
That system made sense for its time. That is no longer the world we are in.
In the AI-SDLC, the cost of producing software drops sharply. Exploration is faster. Prototyping is faster. Coding is faster. Refactoring is faster. Testing can be generated and run on demand. The old relay race starts to look less like discipline and more like drag.
The bottleneck has moved from making software to deciding what to make, how to make it, and how to keep the system coherent as the pace increases. According to many studies, in an average product development organization, developers code less than one hour per day. As execution accelerates, and coding is less of the effort, we need to spend more focused and "in-flow" energy on strategy
The intentional, focused application of logic on systems and the transmission of that energy into a high flow execution engine.
Two Tracks, One System
The right mental model for the AI-SDLC is not one process but two connected tracks.
The first track is the fast loop: build, test, iterate, launch.
This loop should move with as little friction as possible. Small teams should be able to take a mission, create a thin vertical slice, test it in isolation, ship it, observe the results, and keep going. This is where AI changes the economics most dramatically.
The second track is the intentional loop: strategy, architecture, organizational design, and mission clarity.
This loop cannot be rushed in the same way because it provides the coherence that prevents speed from turning into chaos.
If you only accelerate the build loop, you do not get a great product organization.
You get a faster feature factory.
We have all seen what that looks like. More tickets. More features. More local optimization. More things shipped that make sense in isolation but weaken the product in context. The classic example is the remote control with a hundred buttons. Every feature probably had a rationale. Every team probably had good intentions. But somewhere along the way, the system forgot what mattered.
Nobody can find the volume.
That is the real risk in the AI-SDLC. AI makes building easier. It also makes incoherence easier.
Strategy Becomes More Important, Not Less
So the question is not whether teams can build faster. They can.
The question is whether the organization can create enough alignment that speed improves the whole system instead of fragmenting it.
This is why strategy and strategy deployment become foundational.
Simon Wardley’s work is useful here because it forces us to distinguish between what should be standardized and what should remain flexible. In any evolving landscape, some capabilities are becoming industrialized. Others are still differentiating.
A lot of the mechanics of software delivery are moving down the map toward commodity. Version control, testing infrastructure, CI pipelines, ephemeral environments, security controls, deployment automation, observability, and common platform services should be boring on purpose. We should not waste strategic energy re-litigating them team by team.
At the same time, the interfaces where humans and agents collaborate are still evolving rapidly. The tools will change. The workflows will change. The best patterns are still emerging.
That means we should avoid high abstractions and one-way doors.
We should standardize the pipes and keep the surfaces flexible.
Standardize the Pipes, Keep the Surfaces Flexible
This matters more than it sounds.
If every team is working on different pipes, collaboration breaks down, traceability gets weaker, testing becomes inconsistent, and the organization starts paying coordination tax again.
But if every team is forced into a rigid front end toolchain, agent platform, or design workflow before the market has settled, the organization becomes brittle.
In a fast-moving space, optionality is a strategic asset.
That leads to a simple doctrine for the AI-SDLC:
Everything runs on the same pipes. Teams are free to choose the surfaces that help them move fastest, as long as they remain on the common system of record and within common guardrails.
Core capabilities
Version control is the center of gravity. Git is the spine. Code, configuration, prompts, evaluations, migrations, agent skills, test assets, and operational artifacts all need to live on the same rails. If it is not versioned, reviewed, reproducible, and connected to the rest of the system, it is not part of the delivery system.
Ephemeral environments and ephemeral databases are essential. Every meaningful change should be testable in isolation. Not merged into a shared swamp. Not validated by hope. Not blocked by waiting for another team’s environment to stabilize. Isolation is what makes fast teams possible.
Loose coupling must be made safe. Contract tests and integration tests are the trust layer. The point is not to eliminate coordination entirely. The point is to let teams move without constant meetings, dependency negotiation, and manual validation.
Design exploration should be fast. Tools like V0 compress the path from concept to experience. Used well, they allow teams to explore workflows quickly, compare patterns, and reduce cognitive load before they harden the wrong thing into production.
Agentic coding platforms are interchangeable surfaces. Claude, Copilot, Cursor, V0, Claude Code, Claude Workspace, and whatever comes next are surfaces. Teams can choose what works best for them. The important thing is that they all operate against the same version control system, the same testing harness, and the same platform guardrails.
Skills are organizational context for agents. Skills are a way to manage standards, architecture patterns, safety rules, domain conventions, and team-specific knowledge in a reusable way. In a sense, they are HR for the agent layer.
Testing harnesses create safe speed. In the AI-SDLC, testing is not a downstream gate. It is what makes rapid iteration safe. Most leverage still sits at the bottom of the test pyramid: fast unit tests, reliable contract tests, and integration tests that run on demand.
Design systems and platform services enable autonomy. The design system lets teams work independently without breaking the coherence of the user experience. Platform services let teams work independently without breaking security, reliability, or compliance.
Good guardrails reduce bureaucracy because they remove the need for constant permission-seeking and repeated reinvention.
The Default Workflow for a Team
Put all of this together and the default workflow for a team starts to look very different from the old SDLC.
A team is not handed a stack of stories and told to execute.
A team is given a mission. Clear outcome. Clear boundaries. Clear relevance to strategy.
From there, the team works collaboratively and in sync:
- Frame the problem together — Clarify the user problem, system constraint, and desired outcome.
- Explore quickly — Use design and coding tools to test workflows and options early.
- Build a thin vertical slice — Create the smallest meaningful end-to-end change.
- Validate in isolation — Use ephemeral infrastructure and fast tests to assess the change safely.
- Make decoupling safe — Rely on contracts and integration tests, not meetings and hope.
- Ship in small increments — Release continuously and observe what happens.
- Feed learning back into the system — Improve skills, patterns, platform capabilities, and product understanding.
This is why I say the AI-SDLC requires us to leave our business cards at the door.
Leave the Business Cards at the Door
The old system needed strong functional separation because work was expensive and information had to be transferred in batches across time. The artifacts mattered because they were the container for that transfer.
PRDs, stories, acceptance criteria, and staged handoffs were important in a world where each step took long enough that you had to freeze knowledge and pass it downstream.
In the AI-SDLC, that batching logic starts to work against us.
That does not mean documentation disappears. It means documentation changes purpose. It becomes a tool for alignment and memory, not a substitute for collaboration. It becomes lighter, more strategic, and more connected to the live system of work.
Teams should work much more collaboratively, much more synchronously, and in much smaller units. They should be explicitly mission-oriented. They should be decoupled from the larger system where possible, but tightly aligned to the larger mission through strategy, architecture, and clear interfaces.
Small Teams Are Not Enough
This last part is the most important.
Small teams are not enough. Great tools are not enough. Fast loops are not enough.
The business vision, product strategy, product architecture, and organizational design have to line up.
If incentives reward feature count over experience quality, complexity wins.
If the architecture requires cross-team negotiation for every meaningful change, coordination wins.
If the organization's platform, design, and security are weak, heroics win.
If the mission is unclear, confusion wins.
The AI-SDLC only works when the fast loop is supported by an intentional loop that makes coherence easier than chaos.
The Real Opportunity
That is the real opportunity in front of us.
AI is not just a productivity story. It is an organizational redesign story. It changes the economics of coordination. It changes the economics of capability-building. It changes what should be standardized and what should remain flexible. It changes what kind of teams are effective and what kind of management overhead is necessary.
In that world, the highest leverage move is not to push more work through the old system faster.
It is to redesign the system around small, interdisciplinary, outcome-owning teams, supported by strong platform and design guardrails, operating on common pipes, with flexible tool surfaces, and guided by strategy that is salient enough to let people move quickly without drifting apart.
AI did not remove the need for process.
It removed the need for batching.
The new discipline is not in handoffs. It is in alignment.
And the organizations that understand that will not just ship faster.
They will build better.