The AI SDLC Needs an Execution Layer, Not a Faster Pipeline

The AI SDLC Needs an Execution Layer, Not a Faster Pipeline

What is the AI SDLC?

The AI SDLC is the software development lifecycle rebuilt for a world where agents, not people, produce most of the code and take most of the actions. The common framing is that this breaks the lifecycle at code generation, so the platform's job is to industrialise everything downstream: review faster, test faster, deploy faster.

That framing is half right, and the half it misses is the expensive one. The break is not that more code arrives. It is that the reviewable unit stops being the diff and becomes the run.

Why "review the code faster" is the wrong answer

A human pull request is a proposal. Nothing has happened yet. Review is a gate that sits before consequence, which is what makes code review such an effective control: reject the diff and the world is unchanged.

An agent's pull request is a report. By the time it exists, the agent has already run code, already called APIs, already read data, possibly already written some. The diff is a description of what happened, not a request to let it happen.

That single change invalidates the assumption underneath most platform tooling. If your controls live around the artifact, and the artifact is produced by a process that already had access to your systems, then your controls are downstream of the risk. Reviewing ten times faster does not help, because the thing you are reviewing is no longer the thing that needed gating.

So the question stops being "how do we review more code" and becomes "what was this thing allowed to do while it was producing that code."

The three assumptions the AI SDLC breaks

Most delivery platforms were designed around three assumptions. Each is now false.

1. Code volume is bounded by human throughput. It was, and it isn't. This is the assumption everyone has noticed, and it is the least interesting of the three, because it is a scaling problem and scaling problems have known shapes.

2. Execution happens after approval. Build, test and deploy ran after a human said yes. An agent executes as part of authoring: it runs the test suite, hits a staging API, queries a database to understand a schema. Approval now sits in the middle of execution rather than before it.

3. The actor is identifiable and stable. A commit had one author with one set of credentials and a stable intent. An agent run may involve several models, several tools, a changing prompt, and credentials that belong to a service account shared by other agents. "Who did this and under what authority" stops being a lookup and becomes a reconstruction.

Assumption one is a capacity problem. Assumptions two and three are governance problems, and no amount of pipeline speed touches them.

What actually has to change: the unit of control

If execution is now part of authoring, then the environment the agent authors in has to be the control surface. Four properties, and they are all runtime properties rather than pipeline properties.

Isolation that assumes the code is hostile

Treat every agent-produced process as untrusted, because in a meaningful sense it is: nobody read it before it ran. That argues for a boundary that does not depend on the code being well-behaved.

At CreateOS each agent runs in a Firecracker/KVM micro-VM with its own guest kernel, not a shared container with namespace separation. A container escape crosses a kernel boundary that a micro-VM does not share to begin with. We say VM-isolated rather than hardware-isolated deliberately: Firecracker is KVM, and hardware-isolated implies TEE-class guarantees we have never claimed. More on that boundary in microVM isolation for AI agents.

Egress control, because the agent chooses what to call

This is the control most platforms skip, and for agents it is the one that matters most.

For a CI job, the interesting question is what can reach in. For an agent, it inverts: the agent decides what to call, so the question is what it can call out to. Credential scoping does not answer that. An agent holding a valid token and unrestricted network access can reach everything that token permits, plus anything else on the network it decides to try.

CreateOS enforces egress allowlisting in-kernel via eBPF, below the application. The constraint holds regardless of what the model decides, what a tool does, or what an injected instruction asks for.

Approval enforced by infrastructure, not requested in a prompt

A system prompt saying "never delete production data" cannot revoke a database permission. A prompt saying "ask before sending" does not create a transaction boundary around an email API. Prompting is the wrong layer for any guarantee that must survive prompt injection, tool error, or a model swap.

CreateOS runs agents in Watch, Suggest or Execute modes, so a class of action can be required to stop for a human before it crosses an external boundary. That is the control that replaces pre-merge review, because it sits where the consequence is. The full control set is in what a governed runtime actually does.

A record that survives the run

Because the actor is no longer stable, attribution has to be constructed at execution time rather than reconstructed later. That means joining identity, inputs, approvals, tool calls, outputs and environment state into one exportable record, which is a durable audit trail rather than a log. If answering a regulator requires assembling three systems by hand, you do not have one.

Where this leaves the internal developer platform

The IDP does not disappear. Its centre of gravity moves.

A portal that catalogues services and templates golden paths is optimising the part that agents are rapidly making cheap. The part getting more expensive is the part that decides what a running agent may do, and that is a runtime concern.

The practical consequence for platform teams: the interesting build is no longer the portal, it is the boundary. Both still matter. Only one of them is now the constraint.

Does the AI SDLC mean fewer engineers?

No, and the framing is a distraction. It means the leverage moves.

Reviewing generated diffs line by line is work with a falling ceiling. Deciding what agents may touch, designing the approval boundaries, and being able to answer what happened afterwards is work with a rising one. Those are engineering judgments, and they are harder than the review they replace, not easier.

What this looks like on CreateOS

CreateOS is an agent runtime, not an agent builder and not an integration platform. It is the layer agents deploy onto and run under, designed to sit beneath whatever you use to build them.

Shipping today, and relevant to the four properties above:

• VM-isolated execution in Firecracker/KVM micro-VMs, each with its own guest kernel, with fork, pause and resume of full agent state including memory
• eBPF kernel-level egress allowlisting
• Watch/Suggest/Execute approval modes enforced by the runtime
• Self-hosted control plane, with control plane and storage inside your own boundary
• SOC 2 Type II and ISO 27001 certified, reports available under NDA

On startup latency, which matters when an agent creates environments repeatedly across a single task: the independent ComputeSDK sandbox benchmark times a real sandbox creation through to the first successful command and publishes its methodology. CreateOS records a sub-100ms median time-to-interactive on the sequential and staggered tests with a 100% success rate, roughly 50x faster than Cloudflare on the staggered test (run of 7 August 2026). That is a workflow property, not a governance property, and it is worth being precise about which one you are buying.

Common questions

What is the AI SDLC?

The AI SDLC is the software development lifecycle adapted for agents producing most code and taking most actions. The defining change is not volume but sequence: an agent executes while authoring, so execution now happens before review rather than after approval.

How is the AI SDLC different from DevOps automation?

DevOps automation speeds up steps a human triggers. The AI SDLC changes who triggers them and when. An agent runs code as part of writing it, so controls that sat between authoring and execution no longer sit between anything.

Why is code review insufficient for AI-generated code?

Because a human pull request is a proposal and an agent's is a report. By the time the diff exists, the agent has already run code, called APIs and possibly written data. Reviewing faster does not help when the reviewed artifact is a description of what already happened.

What is an agent execution layer?

An agent execution layer is the runtime where agent code runs under enforced constraints: isolation, network egress control, approval gates and audit. It sits beneath the tools used to build agents, so agents can be brought from any framework rather than rebuilt inside one vendor's canvas.

Should AI-generated code be treated as untrusted?

Yes. Nobody read it before it ran, so the boundary around it should not depend on the code behaving well. In practice that means kernel-level isolation and default-deny egress rather than policy documents or prompt instructions.

Does an internal developer platform still matter in the AI SDLC?

Yes, but its centre of gravity moves. Cataloguing services and templating golden paths optimises work that agents are making cheap. Deciding what a running agent may do is getting more expensive, and that is a runtime concern rather than a portal concern.

Can prompt instructions enforce approval gates?

No. A system prompt cannot revoke a database permission or create a transaction boundary around an API. Approval has to be enforced by the runtime to survive prompt injection, tool errors and model changes.

About the author

Naman Kabra is the founder of CreateOS, the unified AI execution layer for the enterprise, and has been building infrastructure since 2017.

Next step

If you are redesigning delivery around agents, the useful first question is not how to review more code. It is what your agents are permitted to do while they write it. See AI agent governance in production, or CreateOS pricing.