What is the AI SDLC? Lifecycle stages for AI-native teams

The AI SDLC describes how software gets built and shipped when coding agents are part of the engineering team. This article defines the AI SDLC, explains how it differs from the traditional SDLC, and walks through each stage from agent execution to production.

The AI SDLC is the end-to-end lifecycle for building, testing, deploying, and operating software in teams where AI agents generate a significant share of the code.

It includes the familiar stages of software delivery, but adds stronger requirements around isolation, verification, and runtime control. Agents can write code, open pull requests, run commands, install dependencies, and iterate on failures. That changes the volume of changes moving through the system and the risk profile of each change.

A complete AI SDLC typically includes seven stages:

1. Sandboxed agent execution: the coding agent runs in an isolated environment where it can execute commands, install dependencies, and test its own changes.
2. Version control: agent-generated changes are committed and pushed to Git, becoming traceable like human-written code.
3. Pull request: the change enters review, the control point between agent output and team approval.
4. Preview environment: the pull request spins up a running, full-stack environment for review and QA.
5. Verification: the team tests the change against real services, databases, and jobs rather than a diff alone.
6. Staging: approved changes deploy to a production-like environment for release checks.
7. Production and operations: the release is promoted, monitored, scaled, and rolled back if needed.

The traditional SDLC was designed around assumptions that coding agents strain.

It assumes a human-paced rate of change, that developers understand most of the code they submit, and that review, CI, and staging can absorb the volume of work being produced. Agents can generate large changes quickly, and those changes can look correct in a diff while failing in a real environment through dependency issues, configuration mistakes, or infrastructure assumptions that are hard to catch in static review.

The AI SDLC responds by moving more verification into running environments and more control into the platform layer. Instead of starting on a developer's laptop, agent-generated code often starts inside an isolated sandbox. Instead of reviewing a diff, teams review a running preview of the full application.

For a deeper look at how agent-driven development changes deployment specifically, see agent-native software development, which covers what happens after coding agents produce working code.

Each stage below answers a practical question: where does the code run, how is it verified, and how does it reach production.

A coding agent needs to do more than suggest code. It needs to run commands, install dependencies, start development servers, execute tests, inspect logs, and iterate on failures.

That execution should happen in an isolated environment rather than on a developer machine, a shared CI runner, or anything production-adjacent. Northflank Sandboxes provide this layer as microVM-backed containers that combine VM-level isolation with container-like performance. A sandbox can run the coding harness, clone the repository, install dependencies, run tests, and expose services, and developers can open a shell into the running environment or connect over SSH where enabled. See the sandboxes documentation for setup details.

For background on why isolation is the starting point, read what is an AI sandbox? and how to sandbox AI agents.

Once the agent produces a useful change, the code moves back into the normal engineering workflow through Git.

Version control gives AI-generated code the same traceability as human-written code: what changed, which branch it came from, which commit was built, and which release reached production. The AI SDLC should not bypass this discipline. On Northflank, a pushed commit can trigger builds directly from the Git repository using a Dockerfile or buildpacks, and that build artifact carries through the rest of the lifecycle.

The pull request is where the change becomes reviewable and where humans stay in the loop.

For AI-generated code, a diff alone is rarely enough. A useful AI-native pull request surfaces the code diff, the build result, test output, logs from a running instance, and a link to a live environment where the reviewer can reproduce the behaviour. Engineers still decide whether the change is correct, safe, and maintainable before it moves forward.

A preview environment turns a pull request into a running application, so the team reviews the system rather than the patch.

On Northflank, preview environments can be triggered from pull requests or branches and can include the services, jobs, add-ons, secret groups, dynamic domains, and build outputs from the triggering commit. Reviewers can check whether the feature works, QA can test the application, and engineers can inspect logs and debug containers. The preview environment setup guide covers configuration.

As agents raise the volume of code moving through review, previews raise the team's capacity to verify it. Ephemeral preview environments for vibe-coded apps goes deeper on this pattern.

The goal of verification is not proving that the agent produced code. It is proving that the change behaves correctly in a realistic environment.

That typically includes build status, unit and integration tests, service startup checks, database migrations, and a review of the preview itself. Many issues with agent-generated code do not appear in the diff. They tend to appear when the service starts, the migration applies, or the frontend calls the backend. Northflank supports this stage with logs, metrics, health checks, shell access into running containers, and one-off command execution against real dependencies.

After review and merge, the change deploys to staging, a more stable, production-like environment for release checks.

In Northflank, staging is an environment with its own services, jobs, add-ons, and release workflows. Teams can deploy builds into staging, run migrations, and confirm services become healthy before going further. Staging also creates a clean promotion point: the team can verify a build in staging and deploy that same build to production instead of rebuilding, which reduces drift between environments.

The final stage is a controlled, observable, and reversible production release, followed by ongoing operations.

Northflank release workflows automate release tasks in each environment, such as backing up databases, triggering builds, running migrations, and deploying services. Each step can be conditional, so if a step fails the rest of the workflow does not continue, and teams can roll back to a previous deployment when needed. After the release lands, the same platform handles autoscaling, secrets management, role-based access control, audit logs, databases, scheduled jobs, and GPU workloads for inference and fine-tuning.

Northflank provides the execution, build, preview, release, and operations layers of the AI SDLC in one platform.

Teams can run application workloads and AI workloads together with the same deployment model, environment model, and governance, deployed on Northflank's managed cloud or inside their own cloud account and VPC. The documentation covers each layer in detail.

Kubernetes is a strong foundation for workload orchestration, but it does not provide a delivery lifecycle by itself.

Many teams choose not to expose Kubernetes directly to developers or agents. They need higher-level primitives instead: build this service, spin up this preview, deploy this release, roll back this change, run this agent-generated code safely. Northflank provides those primitives on top of Kubernetes through its internal developer platform, so developers and agents get a clear interface while platform teams keep control of infrastructure and security. Sandboxes on Kubernetes covers the execution side of this in more depth.

No. Using AI in the SDLC usually means applying AI tools to individual phases of the traditional lifecycle, such as generating tests or drafting requirements. The AI SDLC describes a lifecycle restructured around agents as code producers, with stronger isolation, verification, and release controls throughout.

Agents that execute commands, install dependencies, or run code benefit from strong isolation, since their output is untrusted until verified. MicroVM-backed sandboxes provide VM-level isolation with container-like startup and performance. See best sandboxes for coding agents for a comparison of options.

Review the running system, not just the diff. A preview environment per pull request lets reviewers test the feature, check logs, and confirm migrations and service dependencies behave correctly before merge.

Yes. Northflank supports Bring Your Own Cloud, so sandboxes, previews, and production workloads run inside your own AWS, GCP, or Azure account. Why smart enterprises are insisting on BYOC for AI tools explains the drivers behind this model.

No, it extends it. CI/CD remains the automation backbone for builds, tests, and releases, while the AI SDLC adds sandboxed execution before commit and preview-based verification before merge. See top AI tools for CI/CD pipeline automation for how the two intersect.

• Agent-native software development: what it takes to deploy the software coding agents build.
• What is an AI sandbox?: the isolation layer where the AI SDLC begins.
• Ephemeral execution environments for AI agents: short-lived runtimes for agent tasks.
• Enterprise AI coding agent deployment: running coding agents under enterprise security requirements.
• How to vibe code securely: keeping AI-generated code safe from generation to production.