The AI SDLC is really a product lifecycle: why PDLC and SDLC are merging

The AI SDLC is the software development lifecycle rebuilt around AI agents that plan, write, test and ship code alongside people. Its biggest effect is on where the bottleneck sits: when building gets cheap and fast, it moves upstream to discovery, solutioning and shared context. Product and engineering lifecycles merge into one loop.

Your agents can ship a feature before lunch. Agreeing on which feature still takes until Thursday.

Most explanations of the AI SDLC walk through engineering stages: AI helps with code, then tests, then review, then deployment. For leaders running large product and engineering organizations, the bigger change is that the expensive part of the lifecycle has moved from building to deciding.

The classic picture: two lifecycles and a handoff

For years, many organizations ran two lifecycles back to back.

The product development lifecycle (PDLC) decides what to build and why: discover a problem, define it, design a solution. The software development lifecycle (SDLC) decides how to build it: build, test, deploy, operate. For a side-by-side comparison, see PDLC vs SDLC.

The handoff in the middle was the expensive part. A product manager compressed weeks of customer conversations, trade-offs and stakeholder negotiation into a document and a backlog. Engineers rebuilt the intent from those artifacts, asked questions, and filled the gaps with assumptions. Context leaked at every step. It was tolerable because building took long enough that there was time to catch the leaks.

What the AI SDLC changes at each stage

The public frameworks use different names and stage counts. AWS's AI-Driven Development Life Cycle (AI-DLC) calls itself an AI-centric methodology with Inception, Construction and Operations phases. Atlassian's AI SDLC transformation playbook describes the shift from a traditional to an AI-native SDLC, starting with context and measurement. Claude Academy's AI-native SDLC playbook sets out plays across six stages, from Plan to Maintain. A common pattern shows up across them:

Most of the detail in that material sits in build, test, review and deploy, where AI first proved useful. Planning and requirements usually get the shortest treatment, which leaves the hardest enterprise question underexplored. Who decides what the agents build, and how does that decision reach them?

Why the lifecycles merge

Four shifts push the PDLC and SDLC into one loop.

1. Build cost falls. When an agent can produce a working version in hours, "should we build it?" is no longer a gate you pass once. You can build to learn.
2. Iteration speeds up. Cycles measured in hours mean product decisions and engineering output alternate many times a week, not once a quarter.
3. Specs become executable. An agent acts on the spec directly, so product thinking goes straight into the build. (Spec-driven development covers this stage; see our guide to spec-driven development for product teams.)
4. Feedback loops shorten. Production signals can turn into new work within the same cycle, so "learn" and "discover" stop being separate phases.

The new bottleneck: deciding what to build and keeping context intact

If agents make building fast, two other things become the constraint.

• Deciding what to build. Discovery (understanding the problem and the evidence) and solutioning (choosing an approach given trade-offs, architecture, compliance and dependencies) still run at human speed. In many organizations they run at meeting speed.
• Keeping context intact. An agent knows only what it's given. If the why behind a decision, the constraint legal raised or the dependency another team owns doesn't reach the agent, it fills the gap with a plausible guess and builds that guess quickly.

We call this the context gap, the distance between what the organization knows and what the people and agents doing the work have in front of them. In a slow lifecycle, the gap caused delays. In a fast one, it causes confident, well-tested work on the wrong thing. (For the task-level how-to, see how to give AI coding agents product context.)

A map: where product context enters agent work

Agents can read the repo, the rule files and the ticket. They can't read the customer call or the trade-off agreed in a meeting. Something has to carry that context from where it's decided to where it's used.

The AI SDLC framework as one loop: evidence → decision → spec → build → verify → learn

The table shows the lifecycle as one loop, with who leads each step.

Two things differ from the old picture. First, product and engineering both work at every step, and the split now runs between steering and executing. People choose the problem, set the boundaries and decide what counts as done; agents carry out the build inside those lines. Second, the decision step is explicit. In the relay model, decisions lived in meetings and people's heads. In the merged loop they have to be written down, because agents can't attend the meeting. (Repo-level norms belong in rule files; see AGENTS.md vs CLAUDE.md.)

An illustrative example

This example is made up to show the pattern. A bank's retail team decides to let customers dispute a card transaction from the mobile app. Discovery shows most disputes involve subscriptions, and compliance requires a specific disclosure before submission. The decision ("subscriptions first, disclosure mandatory, no auto-refunds") gets agreed in a meeting.

An agent builds the feature from a ticket that says "add dispute flow". It works, it's tested, and it ships a generic flow with no disclosure, because the decision never reached the ticket. The agent did what the ticket said. The loop broke between decision and spec.

The agent should have received a short decision brief instead:

With this brief, the same agent at the same speed gets the problem, the constraints and the definition of done along with the work.

Enterprise scale: more teams, more handoffs, more context loss

An enterprise feature can touch several teams, systems of record, a compliance review and a platform group, each with its own backlog and agents. A founder can hold the whole picture in their head. In a large organization nobody can, so the system has to carry the context people used to carry. We go deeper in the agentic SDLC and the enterprise context gap.

Where software factories fit

"Software factory" is the name for the build half of this loop done end to end: a well-formed spec goes in; tested, deployed code comes out.

Published software-factory material tends to start at the spec, or at an incoming signal, and treat the decision about what to build as already made. At enterprise scale, that decision is the hard part. A factory fed thin or contradictory intent produces thin or contradictory software faster. We cover the definitions and this discovery gap in what is a software factory?

AI SDLC failure modes

• Automating the wrong thing faster. Higher throughput on a poorly chosen problem compounds waste. Measure outcomes as well as shipped PRs.
• Specs without evidence. A crisp spec can still be wrong. If you can't trace a spec back to evidence and a recorded decision, treat it as a guess.
• Context fragmented across tools. Decisions in slide decks, constraints in chat threads, requirements in tickets, standards in a wiki. Each agent and team sees one piece.
• Review becomes the bottleneck. If agents produce more than humans can verify against intent, quality drops quietly.
• Decisions nobody wrote down. The faster you ship, the more undocumented "why" piles up, and the harder it is to change course later.

What this model doesn't claim

• It doesn't claim product managers are obsolete. The model puts more weight on product judgment. For how the PM role changes, see will AI replace product managers?
• It doesn't claim the PDLC and SDLC merger is an industry consensus. It's our reading of where the work is heading.
• It doesn't claim AI makes discovery automatic. AI can summarize evidence. It can't decide what your organization should bet on.

Where SteerFlow fits

Go back to the map above. SteerFlow is designed to be the highlighted band, the layer between what your organization decides and what your agents receive. It is designed to capture evidence and decisions as records, turn them into specs agents can act on, and keep that context attached as work moves across teams, so the people steering can hand agents a complete brief instead of a thin ticket. If this is the gap you feel, we'd like to hear from you. Get in touch.