← Back to Blog
April 12, 2026 Ben Ong

SDLC of the Past vs SDLC of the Future

The software development lifecycle was designed for a world where writing code was the bottleneck. AI changed that. Here's what the new SDLC looks like.

The traditional software development lifecycle has a problem. It was designed for a world that no longer exists.

The old SDLC assumed that writing code was the bottleneck. Every process, every handoff, every ceremony was designed to make sure engineers spent their limited time on the right things. Specs, tickets, sprint planning, backlog grooming, QA, staging. All of it exists because engineering time was scarce and expensive.

AI changed the equation. Writing code is no longer the bottleneck. But we're still using processes designed for when it was.

The old SDLC

Here's the traditional flow most teams still follow:

Idea > Write PRD > Ticket in Jira > Sprint planning > Assign to engineer > Engineer builds > Code review > QA > Staging > Ship

Every arrow is a handoff. Every handoff is a delay. Every delay is a place where context gets lost.

The total cycle time for a small feature: 2-4 weeks. Most of that time is waiting, not working.

Who does what:

    1. PM: writes specs, manages backlog, attends standups
    2. Engineer: translates specs into code, reviews PRs
    3. Designer: creates mockups, hands off to engineering
    4. QA: tests after engineering is done
    5. Ops: deploys after QA signs off
Everyone is in their lane. Work flows sequentially through lanes. If any lane is blocked, everything downstream waits.

What broke

AI coding agents made the engineering lane 10x faster. But the lanes on either side didn't speed up:

    1. PMs still write specs the same way
    2. The backlog still sits there until sprint planning
    3. Handoffs between PM and engineering still lose context
    4. QA still happens after the code is written
    5. Deployment is still a separate step
Making one lane 10x faster in a sequential process doesn't make the process 10x faster. It makes the other lanes the bottleneck.

This is Goldratt's Theory of Constraints applied to software. You optimized the wrong constraint.

The new SDLC

The new SDLC collapses the lanes. Instead of sequential handoffs between specialists, the whole team works on the same surface:

Describe > Plan visually > Preview live > Ship

That's it. Four steps, not ten. Here's what each looks like:

Describe: Anyone on the team describes what they want in plain English. Not a formal spec. Not a Jira ticket. Just "add a pricing page with a monthly/annual toggle."

Plan visually: The system reads the codebase, understands the architecture, and presents visual options. Not wireframes. Actual UI components styled to the existing app. The team picks the approach they want.

Preview live: An agent builds the feature and deploys it to a preview environment. The team clicks through a live URL and sees the actual feature working. Not a staging environment that's 3 weeks behind production. A live preview of this specific change.

Ship: The team reviews the PR, approves it, and merges. Done.

Who does what:

    1. PM: describes what to build, picks from visual options, reviews the preview
    2. Engineer: reviews the PR, ensures code quality, approves the merge
    3. Designer: sees their design decisions reflected in real code, previews live
    4. QA: tests the live preview, not a description of what changed
    5. Ops: deployment is automatic. Preview environments per PR.
The lanes didn't just speed up. They collapsed into one shared workflow.

What changes

Cycle time: 2-4 weeks becomes 2-4 hours. Not because anyone works faster, but because the handoffs and waiting time are eliminated.

Context loss: Zero. The person who had the idea is the same person who picks the visual option and reviews the preview. No translation through a spec, a ticket, a standup, and a Slack thread.

Engineering leverage: Engineers stop translating PM requests into code. They focus on architecture, system design, and code review. Their time is spent on decisions, not implementation.

Scarce resource shift: The old SDLC protected scarce engineering time. The new SDLC protects scarce attention. The question isn't "do we have engineering capacity?" It's "is this change worth the team's attention?"

The transition

You don't switch SDLCs overnight. The transition happens feature by feature:

  1. Start with small changes that don't need engineering: copy updates, form fields, landing page tweaks
  2. Let PMs and designers ship these directly, with engineering reviewing the PRs
  3. Gradually expand to larger features as the team builds trust in the process
  4. Eventually, the old process is only used for the most complex architectural work
The teams that make this transition first will ship 10x more product. Not because they have better engineers. Because they eliminated the 90% of cycle time that was waiting, not working.

Start the transition on your repo