We rolled out AI coding assistants and our pull request count went up. Our lead time to production barely moved. The reason turned out to be simple: writing code was never our bottleneck. Pull requests waited in review, flaky tests blocked merges, deploys waited for someone with the right access, and incidents kept pulling the same engineers off feature work.
AI made one stage of the pipeline faster, and the queue just moved downstream. That is the problem the AI SDLC idea is trying to solve.
What is AI SDLC?
AI SDLC, short for AI software development lifecycle, means applying
AI across every stage of delivery rather than at a single step. Planning, coding, review, testing, deployment and production operations all get AI support, and they share context. An agent reviewing a pull request knows why the change was planned. An agent responding to an incident knows what was deployed an hour ago.
Without that shared context, you don't have an AI SDLC. You have a collection of disconnected AI tools.
An agentic SDLC goes a step further. Instead of suggesting code for a human to paste, agents carry out multi-step work themselves. They build a change, write and run the tests, prepare the deployment and propose a fix when something breaks in production. Engineers set the intent, approve risky actions and stay accountable for what ships.
Why coding assistants alone don't move the needle
Delivery speed is set by the slowest stage, not the fastest. If code generation gets twice as fast but review, testing and release stay the same, lead time hardly changes. Many teams see the opposite effect: more pull requests, longer review queues and test suites that can't keep up. There is also a context gap. A coding assistant sees a file or a repository, but not your deployment history, runbooks, compliance rules or the reasons a service was built the way it was.
So its output needs heavy human checking, which eats up the time it saved.
What makes an SDLC genuinely agentic
In practice, an agentic SDLC needs five things working together. Agents need deep context, grounded in your codebase, architecture decisions and production history rather than just the open file. They need safe execution in sandboxed, permissioned environments, where they can build and deploy without touching what they shouldn't. They need human-in-the-loop governance, with approval thresholds set by workflow and risk level. That way a dependency bump can ship on its own, while a schema change in a payments service waits for a senior engineer. Every action needs to be traceable, with a record of what changed, why and who approved it. Finally, agents have to work through the Git, CI/CD, cloud and observability tools you already run, instead of forcing you to rebuild your platform.
Where to start
Don't start where the demos look best. Start where your queue is longest. Measure lead time, review wait time, test flakiness and time to restore service. Then pick one bounded workflow, such as automated pull request review or incident triage for a single on-call rotation.
Define the guardrails before you scale, connect the context agents need, and expand stage by stage once the first workflow has earned trust. The principle that holds it all together is simple: agents do the work, engineers own the outcome.
Disclosure: I work at Revolte AI, where we're building an agentic platform for the full software delivery lifecycle.
Which stage of your pipeline is the real bottleneck right now: review, tests, deploys or incidents?
Top comments (0)