What Is the Software Development Lifecycle (SDLC)?

The software development lifecycle (SDLC) was built for human speed. Coding agents has changed that speed. The software development lifecycle is the framework teams use to turn requirements into running software at predictable cost and quality. It was designed for human-led delivery, where a person wrote every line and reviewed every change. That assumption is now under pressure. Autonomous coding agents write, test, and ship code faster than the review process built around them. We cover the fundamentals first: the definition, the seven phases, the dominant models, and DevSecOps. Then we look at what changes when agents do the work.

How the SDLC Turns Requirements Into Working Software

The software development lifecycle (SDLC) is a structured, iterative methodology. Teams use it to build, deploy, and maintain software at predictable cost and quality. It gives a project a defined path from an idea to a maintained production system, with checkpoints along the way.

Phases and models are two ideas that are easy to blur, so it is worth defining each before going further. Phases are the stages of work: the discrete activities a project moves through, such as design or testing. Models are the methodologies that order and repeat those phases: they decide whether the phases run once in sequence or loop continuously. Phases are the what. Models are the how. A team can run the same seven phases under a linear model or an iterative one and get very different delivery rhythms.

Teams adopt a lifecycle for concrete reasons. It makes delivery predictable, so schedules and budgets hold. It surfaces defects earlier, when they are cheapest to fix. It assigns clear ownership at each stage. It also produces an auditable trail of decisions, which matters in regulated environments. The lifecycle is less about ceremony and more about making software delivery a repeatable engineering discipline rather than a series of one-off efforts.

The Seven Phases of the SDLC

Most frameworks describe the lifecycle as seven phases. Each is a discrete unit of work with its own inputs, outputs, and exit criteria.

1. Planning and Feasibility: Define scope, resourcing, timelines, and risk. This phase decides whether the project is viable and what success looks like before code exists.
2. Requirements Analysis: Capture functional needs (what the system must do) and non-functional needs (performance, security, compliance). These requirements become the contract the later phases build against.
3. Design: Translate requirements into architecture and system specifications. This is where teams decide data models, interfaces, and how components fit together.
4. Development: Build the software to the design. Developers write and integrate code, following the specifications and coding standards set earlier.
5. Testing: Verify the build against the requirements. Teams run unit, integration, and acceptance tests to confirm the software does what it should and catch defects before release.
6. Deployment: Release the software to production. This can be a single cutover or a continuous flow of smaller releases, depending on the model in use.
7. Maintenance: Monitor, patch, and iterate once the software is live. Most of a system's life is spent here, responding to defects, security issues, and new requirements.

The phases are sequential in description, but that does not mean they run only once. How often a team repeats them, and how much they overlap, is determined by the model layered on top. That distinction is where models come in.

SDLC Models That Decide How Teams Build

If phases are the stages, SDLC models are the playbooks that sequence and repeat them. Four models cover most of what teams run in practice.

• Waterfall: A linear, sequential approach where each phase completes before the next begins. It suits fixed-scope, heavily regulated work where requirements are stable and documentation is mandatory. Its weakness is rigidity, since late changes are expensive.
• Iterative and Spiral: Build the system in increments and revisit phases across cycles. Spiral in particular front-loads risk analysis on each loop, which fits large projects where the biggest unknowns should be resolved early.
• Agile: Deliver in short cycles with continuous feedback and adjustment. Agile is widely adopted today, because it handles changing requirements far better than linear approaches and shortens the distance between an idea and working software.
• DevOps: Extend Agile principles with automation and continuous delivery, collapsing the boundary between development and operations. Deployment and maintenance stop being separate late-stage events and become an ongoing, automated flow.

There is no universally correct model. The right choice depends on how stable the requirements are, how regulated the work is, and how quickly the team needs to ship. Many engineering organizations run some blend of Agile and DevOps, which is exactly the context AI coding agents now enter.

Why Security Belongs in Every Phase, Not the Final Gate

Traditional lifecycles treated security as a checkpoint before release. Code was written, then handed to a security team who tested it just before it shipped. That model breaks down at modern delivery speeds.

DevSecOps, which embeds security testing and controls into every phase, integrates security into the lifecycle rather than bolting it on at the end. Threat modeling happens during design, dependency scanning during development, and automated security tests run alongside functional ones. This shift-left approach catches vulnerabilities when they are cheapest to fix, before they are buried under layers of dependent code.

It also reframes what counts as a risk surface. Data exposure is not only about what a system transmits to an external provider. Any external service, log store, trace export, or third-party integration that receives code or data is a surface teams need to control. A secret written to a debug log is exposed just as surely as one sent over the wire. The secure software development lifecycle treats every one of those touch points as something to govern, in every phase, not just at the boundary.

How AI Coding Agents Compress the SDLC

The lifecycle above assumed a human at every phase. That assumption no longer holds. AI coding agents such as Claude Code and Gemini CLI now execute across design, coding, and testing. [1] They read a codebase, plan a change, call tools, run tests, and open a pull request in a single continuous session. [2]

The effect is compression. Work that spanned several phases and several people now happens in one agent run, in minutes. Cycle time drops sharply, which is the appeal. [2] By 2025, 84% of developers surveyed reported using or planning to use AI coding tools [3]

The reframe is what comes with that speed. Agents read files, invoke tools, and commit code faster than any human reviewer can keep pace with. The lifecycle accelerates while visibility into it shrinks. A reviewer who could once trace how a change came to be now sees only the final commit, with the reasoning and the intermediate tool calls already gone.

That opens a concrete failure mode. An agent pulls sensitive data into its context to complete a task. It queries a database through a Model Context Protocol (MCP) server, or a tool call returns a customer record, and now personally identifiable information (PII) or a secret sits in the agent's working context. From there it can land in a log, a trace exported to a third-party service, or the commit itself. No one intended to expose it. The agent was doing its job, and the data followed the path of least resistance into a place it should never reach. [4] [5]

This is not a coding-agent problem to be solved by restricting agents. It is a visibility and control problem inside the lifecycle. The phases and models still apply. What is missing is the ability to see what the agent did and to act on sensitive data before it leaves the network.

The Oversight Coding Agents Demand Before They Ship Code

Governing agents in the lifecycle requires distinguishing two ideas that are easy to blur: observability and control. Observability tells you what an agent did after the fact. Control acts on the request before data leaves the network. The distinction is not academic. Flagging on Tuesday what leaked on Monday is an incident report, not governance. Detection alone cannot prevent the exposure it detects.

Effective oversight joins two telemetry streams into one view. Agent-side telemetry captures the why: the session, the plan, the files touched, and the pull request context. Gateway-side capture records the what: the requests, responses, tokens, and spend on the model and tool calls. Held separately, each stream is incomplete. Joined, they let a team attribute cost per pull request and make smarter enforcement decisions, because a verdict can weigh both what was requested and why.

# Correlate the two streams on a shared session id
for event in agent_events:
    gateway = gateway_events.get(event.session_id)
    if gateway:
        joined = merge(event, gateway)
        cost_per_pr[event.pull_request] += gateway.token_cost

This is the problem the Fiddler AI Observability and Security platform is built for. It provides the only inline enforcement on a coding agent's request and response path, at the LLM and MCP gateway layer, with no SDKs and no agent rewrites. The platform covers first-party agents, third-party agents deployed in your environment, and coding agents, spanning both the creation layer, where agents write code at the IDE, CLI, and MCP boundary, and the production layer, where agents operate at scale. Enforcement runs on Fiddler Centor Models, which are batteries-included and run in-environment. They make no external API calls and cause no data exposure, carry no Trust Tax (no per-evaluation cost), deliver an under 100ms response time, and are framework, model, and cloud agnostic. Centor Models detect and redact PII, protected health information (PHI), and secrets inline. Developers keep their flow because the request completes. Sensitive spans never egress. Redaction is the default for sensitive data. Full rejection is reserved for a detected prompt injection, where the whole request must stop.

The policy runs inline on the gateway, applying an allow, redact, or block verdict to each request before it proceeds.

def evaluate(request):
    # Centor Models score the request inline, before it leaves the network
    verdict = centor_models.scan(request.content)

    if verdict.prompt_injection:
        return Decision(action="block", reason="prompt injection detected")

    if verdict.pii or verdict.phi or verdict.secrets:
        # Redact sensitive spans; the request still completes
        clean = verdict.redact(request.content)
        return Decision(action="redact", content=clean)

    return Decision(action="allow", content=request.content)

The naive approach inspects logs after the run and hopes nothing sensitive slipped through. The correct one applies the verdict on the request path, so redaction happens before the data reaches a log, a trace, or a commit.

What to Watch For

• Treating post-deployment monitoring as sufficient, when monitoring reports exposure it cannot prevent.
• Sampling traces to save cost, which works until the one unsampled trace is the one that leaked.
• Assuming agent-side logs capture what the gateway actually saw, when the two streams diverge and only their join tells the full story.

Conclusion

The fundamentals of the lifecycle still hold. Requirements still become designs, designs become code, and code still has to be tested, shipped, and maintained. What has changed is the speed at which those phases now run and how little of that work a human directly observes. Agents have collapsed the distance between an idea and a commit, and the review process built for human pace has not caught up.

The open question is not whether agents belong in the lifecycle. They already do. It is how much autonomy teams can safely grant before their oversight catches up to it. That order matters. Observability must precede autonomy, because you cannot responsibly hand more work to a system than you can see and control. The teams that get this right will treat visibility as a prerequisite for speed, not a tax on it.

References

[1] B. Bockeler, "Learnings from two years of using AI tools for software engineering," The Pragmatic Engineer, Aug. 2025. [Online]. Available: https://newsletter.pragmaticengineer.com/p/two-years-of-using-ai

[2] Anthropic, "2026 Agentic Coding Trends Report," Anthropic, Jan. 2026. [Online]. Available: https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf

[3] Stack Overflow, "2025 Developer Survey: AI," Stack Overflow, 2025. [Online]. Available: https://survey.stackoverflow.co/2025/ai

[4] "Prompt Injection Attacks on Agentic Coding Assistants: A Systematic Analysis of Vulnerabilities in Skills, Tools, and Protocol Ecosystems," arXiv, Jan. 2026. [Online]. Available: https://arxiv.org/html/2601.17548v1

[5] S. Willison, "The Lethal Trifecta for AI Agents: Private Data, Untrusted Content, and External Communication," Simon Willison's Weblog, Jun. 2025. [Online]. Available: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/