From prompt to product: how foundation models are collapsing the SDLC
The software development lifecycle has been stable, in broad shape, for forty years. That stability is ending. Foundation models are not making each phase a little faster — they are eliminating the seams between them.
The SDLC, as it used to be
Five clean phases — requirements, design, implementation, QA, release — each with its own artefacts, its own meetings and its own specialists. A handoff tax at every boundary. A feature that might have been worth 20 points of value often lost 30% to coordination overhead before a single line of production code was written.
What the model compresses
When one reasoning system can read a vague ticket, draft a design, generate the code, write the tests, simulate edge cases and summarise the risk for a human reviewer — the phases do not go away, they merge.
The SDLC stops being a relay race between specialists. It becomes a single high-bandwidth conversation between a human director and a capable execution agent.
Requirements → design → implementation
Traditionally: a PM writes a spec, a tech lead reviews it, an engineer translates it into tasks, another engineer implements. Now: a PM describes the outcome, an agent drafts a spec, a design, a task breakdown and a first implementation — all grounded in the current codebase. A human edits, not originates.
Implementation → QA
Traditionally: devs write code, QA writes tests. Now: the same loop generates both, plus property-based tests, plus adversarial scenarios. Coverage becomes a cheap byproduct rather than an expensive second act.
QA → release
Traditionally: tickets are triaged, release notes are written, stakeholders are emailed. Now: an agent composes release notes from the trace, identifies which customers care about which changes, and drafts the comms. Humans approve.
The new bottleneck is not speed
When execution costs collapse, the bottleneck moves up the stack. The limiting factor is no longer "how fast can we build?" It is:
- How well can we specify intent?
- How confidently can we evaluate output?
- How safely can we roll back when we are wrong?
Those are cultural and organisational problems, not coding problems. Which is why some teams are shipping 10x and others are spinning their wheels with the same tools.
A reference stack for the collapsed SDLC
- Intent capture — structured outcome + success criteria, stored alongside the code.
- Context retrieval — codebase, docs, prior decisions, customer cohort data.
- Plan + code generation — one or more agents, in parallel, producing candidates.
- Evaluation — automated tests, policy checks, security scan, performance budget.
- Human review — not of every line, but of the trace: intent vs plan vs output.
- Staged release — shadow, canary, full — gated by live evals.
- Post-release learning — the outcome of the change feeds back into the golden set.
Three anti-patterns we see weekly
- Using AI only at the coding step. You save 20 minutes and lose the compounding gain.
- No eval harness. Without a golden set and regression tests, every model upgrade is a coin flip.
- Human-in-the-loop everywhere. Humans are expensive. Use them where judgement matters, not where signoff is theatre.
What this means for hiring
Engineering teams of the next decade will look more like newsroom editorial boards than like assembly lines. Fewer people. Broader scope. Tighter judgement. More writing, more reviewing, more direction. Less typing.
TL;DR
- Foundation models do not accelerate one SDLC phase — they dissolve the seams between them.
- The bottleneck moves from execution to intent, evaluation and rollback.
- Build an end-to-end stack, not a better autocompleter.
