The SDLC is not broken. It's obsolete.
The SDLC is not broken. It's obsolete.
From two-week sprints to living software — a timeline of how the way we build things is about to change beyond recognition.
Written from the vantage point of 2030, looking back · A product leader's dispatch
Imagine reading this in 2030. Agile is taught in business schools the way Waterfall was taught in the early 2000s — with a mix of nostalgia and mild embarrassment. The two-week sprint, the story point, the backlog grooming ritual — they feel as quaint as the daily standup itself, a ceremony designed for a world where humans were the bottleneck.
They aren't anymore.
What follows is not a prediction. It is a map of a territory we are already entering — where the unit of work is an outcome, not a task; where software rewrites itself from usage data; and where the PM's most important skill is not prioritisation, but articulating why something should exist at all.
This is the story of how we got here.
The timeline
2018 — 2022 · The baseline
The Agile empire at its peak
Every company was a software company. Every software company ran sprints.
By the early 2020s, Agile had won so completely that questioning it felt like questioning democracy. Two-week sprints. Story points. Definition of done. Burndown charts. The ceremonies were everywhere, and for good reason — they worked. They had replaced the catastrophic rigidity of Waterfall with something genuinely better: tight feedback loops, working software over documentation, people over processes.
But Agile had a silent assumption at its core: humans were the execution layer. The sprint existed to pace human effort. The story existed to coordinate human understanding. The standup existed to surface human blockers. Every part of the methodology was optimised around the constraint that a developer could only write so much code in a day.
That constraint was about to disappear.
Core assumption of this era: Development velocity is bounded by human coding hours. Planning exists to manage those hours efficiently.
2023 — 2024 · First wave
The copilot years
AI arrived as a better autocomplete. Teams celebrated 30% productivity gains. Nobody changed anything.
GitHub Copilot was the harbinger. Developers started finishing sentences with it. Then paragraphs. Then functions. The headlines were euphoric — "10x developer productivity!", "AI writes 40% of your code!" — and the tools genuinely helped. But organisations made a classic mistake: they bolted the new capability onto the existing process.
Sprints stayed the same. Stories stayed the same. Standups stayed the same. Teams used AI to write code faster inside a process designed for human-speed coding. It was like installing a jet engine in a horse cart and being impressed at the speed.
"Most organisations are capturing only 5–15% of available productivity gains — because they're using AI tools on top of Agile processes that were never designed for them." — McKinsey, late 2025
The organisations that pulled ahead were not the ones with the best AI tools. They were the ones who understood that the tools were an excuse to rebuild the process entirely.
The gap that opened: AI is generating code in hours that used to take days. But planning, review, and release are still paced by human meeting cadences. The bottleneck moves upstream.
2025 · The specification turn
Spec-driven development arrives
The story is dead. Long live the spec. (And the first argument about whether it's just Waterfall with better fonts.)
2025 was the year the industry tried to name what was happening. GitHub released Spec Kit. AWS launched Kiro — an IDE built entirely around the idea that you write a specification first, and the agent builds from it. The debate exploded: was this a genuine breakthrough, or Waterfall resurrected in Markdown?
The honest answer was both. Spec-Driven Development had something the user story never did: it made the machine a first-class reader. A spec wasn't written for a developer to interpret — it was written for an agent to execute. Input-output mappings. Preconditions. Interface contracts. Acceptance gates that ran automatically, not discussed in a meeting.
The spec became "version control for your thinking." Instead of ideas living in someone's head, then in a Jira ticket, then in a code comment, they lived in a versioned document that the entire build process ran against. When the spec changed, the code changed. When the spec was wrong, the build caught it.
"At the radical end, there is an argument we can now discard code entirely and treat specs as the sole source of truth. Code becomes a byproduct — an intermediate product between requirements and compiled binaries." — Thoughtworks, Dec 2025
But SDD had a quiet limitation: it still assumed humans knew what to build. The workflow was still human → machine → output. That was not radical enough.
What SDD replaced: User stories (written for human coordination) → Executable specifications (written for agent execution). The unit of work shifted from task to contract.
2026 — 2027 · Paradigm shift
Goals over instructions
Outcome-Driven Development. You stop saying what to build. You say what to change.
The next leap was conceptual, not technical. A small number of product teams stopped writing feature specs and started writing metric targets. Not "build a progress indicator on the assessment screen." Instead: "reduce drop-off between step 10 and step 20 by 15% within this quarter."
The agent received a goal vector. It interpreted what that meant architecturally, designed experiments, measured results, and iterated. The PM didn't tell it what to build. The PM defined what success looked like, and the agent reasoned backwards from there.
This compressed discovery, design, and delivery into a single loop. It killed the concept of a feature backlog. If a feature didn't move a metric, it wasn't worth building — and the agent could run that analysis automatically before writing a line of code. What looked like product management became something closer to experiment orchestration.
"Goal Vectors are the new form of task delegation. Instead of user stories, you define specific, quantifiable, time-bound outcomes and allow the autonomous agent to determine the optimal, unconstrained path to achieve that goal." — Agentic Product Management Framework, 2026
The new atomic unit of work: Not a feature. Not a story. Not a spec. A metric target with a time bound and a verifiable acceptance state.
2027 — 2028 · Living systems
Software that rewrites itself
The closed loop closes. Production telemetry feeds directly back into code. The concept of a release starts to dissolve.
The strangest shift of the decade happened quietly, in production. Teams noticed that their AI agents — given access to both the codebase and the analytics platform — were beginning to propose changes nobody had asked for. The agent had seen that users consistently abandoned a flow at a specific point, noticed the pattern across three months of sessions, and surfaced a code change that addressed it.
This was telemetry-closed-loop development. Not a feature request. Not a sprint. Not a spec. A continuous cycle from user behaviour → gap detection → code proposal → human review → deployment → new behaviour → repeat. The SDLC didn't have phases anymore. It had a heartbeat.
"Not as something written and deployed once, but as a living system capable of both self and guided adaptation." — C3.ai Research, Dec 2025
The roadmap — the sacred quarterly artefact — became meaningless when software was changing daily based on real signals. What replaced it was something more like operating principles: what the product was optimising toward, what it would never do, and who had the authority to override the agent's judgment.
For product leaders, this was disorienting. The skills that mattered were no longer vision and prioritisation. They were governance: knowing which signals to act on, which changes required human sign-off, and what the product would refuse to do regardless of what the data said.
What disappeared in this era: The release. The sprint. The deployment ceremony. The roadmap as a planning tool. What remained: governance thresholds, ethical guardrails, and outcome targets.
2029 — 2030 · Deep structure
The product constitution
The most radical move: throw out code, specs, and stories. Maintain only the why.
By the end of the decade, the most forward-thinking product organisations had arrived at a strange conclusion. The thing that kept breaking their autonomous systems wasn't bad code — it was ambiguous intent. Agents built what they were told, but what they were told kept drifting from what the organisation actually needed. Specs were updated, but the reasoning behind the specs was never captured. Code was regenerated, but the principles that should govern it were nowhere machine-readable.
The answer was the Product Constitution: a living document encoding not what the product does, but why it exists. Business intent. User truth. Ethical constraints. Success definitions. Domain knowledge. Everything that had previously lived in the PM's head, in onboarding documents nobody read, in tribal knowledge that left with people when they left companies.
In the constitutional model, when any agent needed to make a decision — about architecture, a UX tradeoff, which metric to optimise — it read the constitution first. When the product changed direction, the constitution was updated, and everything else was regenerated from it.
"Developers working with agents won't look at code most of the time. They'll look at intent." — Guy Podjarny, founder of Tessl, 2025
The constitution wasn't a spec. It was the spec for the specs. Tessl had captured part of the idea — specifications are the new source code — but even that underestimated it. A spec still describes what to build. The constitution describes why anything should be built at all.
What the PM role became: Not story-writer. Not roadmap-owner. Not backlog-groomer. The keeper of the constitution — responsible for maintaining, with precision and depth, the organisation's articulated understanding of why the product exists.
2031 + · Horizon
Agent-native products
The user model changes. Your product's most important "user" might not be human.
The shift that few anticipated: by the early 2030s, a growing share of product interactions were agent-to-agent. An HR platform's AI agent querying a psychometric API. A procurement bot evaluating SaaS options. A personal finance agent booking services on a user's behalf without the user ever opening a browser. The human-readable UI was no longer the primary interface. The machine-readable API was.
Product teams stopped optimising for click-through rates on a beautifully designed screen. They started optimising for API discoverability, schema clarity, and trust protocols between autonomous systems. The user story — that most human of artefacts, with its "as a user, I want..." structure — had been rendered not just obsolete but conceptually misaligned with the world it was trying to describe.
A whole category of product thinking had to be invented from scratch. Not user research. Agent research. Not UX flows. API grammars. Not conversion funnels. Machine trust scores. The organisations that had spent the previous decade learning to articulate their intent precisely found this transition natural. The organisations that had never moved past story-writing found themselves designing for a user model that no longer existed.
The open question of this era: If your product's most important "user" is an AI agent, what does empathy mean? What does onboarding mean? What does product-market fit mean? Nobody had answers. Everyone had opinions.
So where does that leave us — right now, in 2026?
Somewhere uncomfortable. The old world — Agile, sprints, stories, backlogs — is still the default in most organisations. The new world is visible but patchy: some teams running Spec-Driven workflows, a handful experimenting with outcome targets, a few researchers publishing papers on self-evolving software that almost nobody is reading.
The gap between early movers and everyone else is widening faster than most people realise. McKinsey's research found that 70% of companies have not changed role definitions despite AI tools evolving rapidly. That is not a compliance failure. It is a conceptual one. The tools changed. The mental models did not.
SDD is not the final answer. It is the first legible answer — the first way the industry has found to make AI execution reliable at scale. But it is one point on a much larger map. Outcome-Driven Development, telemetry-closed loops, the product constitution — these are not distant possibilities. They are architectures that teams are building right now, in production, without waiting for the methodologies to have names.
The product leaders who will matter in this decade are not the ones who master the best tool. They are the ones who can hold a product's why with enough depth and precision to govern an autonomous system. That is not a smaller job than writing user stories. It is an infinitely harder one — and a much more important one.