It’s been 80 years since the Software Development Life Cycle (SDLC) phases, including requirements, analysis, development, testing, deployment, and maintenance, have served the world as a backbone for collaboration between all stakeholders involved in software delivery.

SDLC makes perfect sense as it follows the typical phase flow of human tasks, from A to Z, trying to correctly transform initial intent into a final working software.

Like every cycle, SDLC, as we know it, is coming to an end. SDLC does not fit the AI era; adapting it will fail, so it is better to find a model that is applicable and brings real value.

Why adapting SDLC will fail

Some organizations might be tempted and try extending the SDLC with AI. Add an AI sprint or an AI review.

The main obstacle is that SDLC is built around human work constraints like handoffs, documentation, phase gates, and sequential validation. Neglecting that AI collapses these constraints.

When intent can be translated, executed, validated, and iterated within minutes, the SDLC becomes a blocker that leads to statements like AI doesn’t fit our organisation.

Every SDLC phase translates intent into another artifact: requirements to designs to tickets to code to tests to releases. With AI, every translation layer increases ambiguity and reduces outcome quality.

From lifecycle thinking to loop thinking

The AI era does not need a “life cycle.” It operates in a loop.

A continuous loop where intent, execution, and validation are tightly coupled. This is where Request–Prompt–Delivery emerges — not as a framework, but as an operating model for every company in the AI era.

If not SDLC, then what?

The state-of-the-art technologies shorten the path between intent and execution, so we do not need typical SDLC phases. We do activities related to those phases, but performed in a completely different way, and at hyper speed. So we also need a new operating model for companies.

The great news is that the new AI-native operating model is there for you to try. It offers not only faster but also easier “phases” so companies can apply the model more conveniently, where all employees understand quickly what is happening.

Request → Prompt → Delivery (RPD) instead of SDLC

RPD minimizes translation layers between the business and execution layer and embeds AI into the core of the workflow.

The RPD operating model consists of three ingredients:

Request: The business expresses intent, not requirements. No long documents. No user stories. Clear articulation of what value we want to create.

Prompt: Human or AI translate intent into well-structured prompts, AI strategies, and orchestration patterns. This replaces: detailed requirement specs, acceptance criteria, sprint planning overhead, and endless refinement sessions

Delivery: AI systems and human teams co-execute directly, injecting the original intent into the current systems. Delivery is instantly ready for human or AI agent validation.

The entire RPD loop takes minutes or hours, not months, to correctly transform initial intent into a final working software.

Request–Prompt–Delivery (RPD) as the AI-native operating model

RPD removes the illusion that work must move through predefined phases. RPD aligns work around value movement.

Request is not a requirement phase. Prompt is not a design phase. Delivery is not a release phase.

They are capabilities that exist simultaneously and continuously. The model is intentionally simple because simplicity scales faster than governance documents.

How RPD really works in practice

Request is a declaration of intent. It answers one question only: what outcome do we want to achieve? Not how. Not when. Not which system. This forces clarity at the business level and removes the need for speculative documentation. Requests are short, explicit, and outcome-driven. And yes, we don’t need user stories any longer.

Request examples:

“Help us understand why new customers hesitate during onboarding and where we should focus first.” “Summarize the drivers behind churn in the last quarter so we can decide how to intervene.” “Ensure CRM customer records remain accurate by standardizing company names and merging clear duplicates.” “Identify inconsistencies in our lead routing rules so we can improve response time.”

A Request is direction, not detail, outcome-oriented, conversational, natural language, short, freeform. It holds intention, context, and expected impact — and it evolves as understanding improves.

Prompt is where intelligence is shaped. This is where human context, constraints, and goals are translated into machine-understandable instructions.

Prompt examples:

“Analyze the onboarding flow for new mobile users in Germany. Identify the top three friction points using the last 30 days of feedback. Return issues ranked by expected impact.”

“Generate three landing page variants for Product X. Audience: mid-sized B2B companies. Goal: increase sign-ups by 20 percent. Tone: confident and modern. Include hero text, subtext, a call to action, and a visual suggestion.”

Prompting means designing execution logic. This is where AI strategies, orchestration patterns, validation rules, and guardrails are defined.

Prompt replaces requirements engineering, detailed design, backlog grooming, and sprint planning overhead.

Delivery is a continuous execution loop where AI systems and humans co-produce results. Outputs are immediately testable in related enterprise systems, and the feedback is immediate.

What used to take months now takes hours — sometimes minutes — not because teams rush, but because translation layers disappear.

Why RPD unifies business and IT

The SDLC separated business and IT by design, even if agile frameworks tried to break it, ‘the dark force’ of phases or gates prevented companies from that. RPD removes that separation. When intent flows directly into execution, the artificial boundary between “the business” and “delivery teams” dissolves.

It is a structural change. Business no longer waits for IT. IT no longer interprets business. Both operate inside the same flow.

We need new roles for AI-ready companies

People want to understand where their responsibilities lie. In the SDLC era, business analysts, developers, testers, and Scrum Masters know their role-related responsibilities. They form scrum teams or agile squads crossing the horizontal boundaries of hierarchical organizational structures and try to deliver value as quickly as possible.

With the Request-Prompt-Delivery loops, new, clear roles emerge. More than ever, connected to business value, and there is a clear path to finally merge business with IT into an instant value delivery vehicle.

Value Creator: a business stakeholder, a worker, a technician, or anyone who defines the desired outcome (need, change, or feature) to drive value by monitoring Velocity of Value (Ve).

Story Shaper: translates the request into a structured user intent (a refined problem statement).

AI Engineer: designs precise prompts, curates outputs, and ensures quality.

Guardian: oversees compliance, ethics, and system integration. Also ensures model safety, prompt quality, reduction of ambiguity, and risk control. The role is well played by the current Scrum Masters who want to enter the AI era.

How enterprises move from SDLC to RPD

Most enterprises will not “replace” the SDLC overnight. And they don’t need to.

The shift from SDLC to Request–Prompt–Delivery starts with behavior. At first, RPD appears quietly, at the edges of the organization, where speed matters more than ceremony. Teams begin experimenting with AI to answer questions, generate insights, automate small tasks, or support decisions. These activities already bypass traditional lifecycle phases — even if nobody calls it that yet.

The first signal: value is being created outside the SDLC.

The mistake many companies make is trying to pull these experiments back into the lifecycle. Adding approval steps. Requiring documentation. Forcing backlog alignment. That instinct kills momentum.

The transition works only if organizations accept one hard truth: AI collapses phases, so governance must move inside execution, not around it.

RPD does not replace SDLC artifacts with new artifacts. It replaces translation delays with continuous intent alignment.

In practice, the transition happens in three observable shifts.

First, intent stops being frozen upfront. Requests are allowed to evolve as learning happens. Leaders stop asking for perfect specifications and start asking for clarity of outcome.

Second, planning moves from time-based to value-based. Instead of committing to scope for weeks or months, teams commit to improving an outcome continuously. Velocity of Value (Ve) becomes more important than delivery predictability.

Third, control moves closer to execution. Guardrails, validation rules, and ethical constraints are embedded directly into prompts, pipelines, and AI systems — not reviewed weeks later in steering committees.

At this point, SDLC still exists on paper, but real work flows through RPD loops. And eventually, the lifecycle becomes irrelevant.

Guidelines for enterprises entering the RPD era

Rule number one: stop asking how AI fits into your delivery model. Instead, ask how your delivery model blocks AI.

RPD requires organizations to accept that speed is no longer the main risk. This means governance must focus less on approval and more on direction. Clear intent, clear constraints, clear ownership.

Enterprises adopting RPD should start small but real. Not pilots that never touch production, but real Requests connected to business outcomes. Customer experience, operational efficiency, data quality, and decision support — areas where feedback is immediate.

Organizationally, RPD works best when ownership is explicit. Someone owns the outcome. Someone owns intent shaping. Someone owns AI execution. Someone owns safety and coherence.

Finally, enterprises must stop treating AI as an IT topic. RPD is an operating model, not a technology initiative. When AI sits only in innovation labs or IT departments, it never reaches its potential.

RPD succeeds only when business and technology operate inside the same loop.

What this means for employees

For individuals, the shift from SDLC to RPD is about learning how to think in outcomes instead of tasks.

In the SDLC world, people were rewarded for executing steps correctly. In the RPD world, people are rewarded for moving value.

This is why roles change. Value Creators are people closest to the problem, able to articulate intent clearly. Story Shapers are sense-makers who reduce ambiguity and sharpen direction. AI Engineers design intelligence flows, not just code. Guardians ensure speed does not break trust, safety, or coherence.

For many professionals, especially Scrum Masters, Product Owners, analysts, and senior engineers, this transition is an opportunity rather than a threat. The skills already exist — they simply move closer to value creation.

Those who can express what matters, why it matters, and how to validate it will thrive in the AI era.

Where to start, without breaking everything

The safest starting point is not large transformation programs or core systems. Typical entry points are customer understanding, operational insights, internal productivity, and decision support. In these areas, AI already collapses the distance between question and answer, so the SDLC quietly disappears.

What matters is permission for intent to evolve, and permission for teams to validate value continuously instead of waiting for phase gates.

If this idea resonated with you, feel free to highlight or comment — it helps me understand what topics to explore next.

For more thinking around AI + economics + enterprise transformation, you can follow me here on Medium and connect with me on LinkedIn.

How Companies Can Start Building With AI (Without Breaking Everything) was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.