The bottleneck moved
The old SDLC was built around the assumption that code is expensive. Planning, review, QA, release gates, dashboards, and incident response all exist to protect every change, because generating the next one was costly.
Coding agents broke that assumption. You can now build thirty implementations of the same idea almost as easily as one, which means the hard part is no longer producing options, but knowing which version is worth keeping.
The best engineering teams will shift their focus from getting the code right the first time to learning fastest from production and customers.
The AI SDLC is incomplete
The SDLC used to look like this:
Now it looks like this:
Coding agents are extremely productive code generators because they have a tight feedback loop. Linters, tests, and CI tell them when they are wrong within seconds, so they can self-correct.
The stretch from PR to production is still slow. Ironically, it feels EVEN slower because the preceding stage is so breathtakingly fast now. Production is slower, messier, and higher stakes and requires manual attention. Engineers still have to refine the change, deploy it, monitor it, and decide whether it actually worked.
This is the immediate bottleneck: coding agents can generate changes faster than teams can safely get them to customers.
The first missing piece is autonomous delivery
The immediate goal is to remove the manual work between merge and customer impact. Coding agents write the code, but engineers still babysit changes all the way to production because they have context their agents do not.
We designed Cleric around two fundamentals: continuously maintaining an independent model of the production environment to provide this missing context, and using verification agents to track each production change over days or even weeks until there is a verdict. Together, these let Cleric take ownership after merge: flagging production risk, carrying the change as far as confidence allows, asking for your call when needed, and keeping at it until production proves the change worked.
Merge the PR. Cleric owns everything until there is a verdict.
Example: From PR to production verdict
Claude Code opens a PR to add Stripe billing. Cleric reviews the change for production risk, watches the deploy, tracks checkout errors, payment success, latency, and conversion, then keeps monitoring until the change has a verdict. If something regresses, Cleric investigates and fixes it where confidence is high, or asks before acting.
AI SRE taught us verification
Cleric started with incident response and freeing engineers from on-call. Over time, the agentic layer became the easy part and the focus shifted to production context and verification.
Let's say we receive an OOM alert on your payments service and Cleric needs to investigate it and create a PR to address it. Connecting an agent to your code, infra, and observability to reason about why the OOM happened is straightforward. The accuracy comes from understanding the payments service before the alert investigation: what it connects to, how it has failed before, what normal looks like, and where it is fragile.
You also need to close the loop after the fix. Even if the agent assumes the OOM was caused by a new dependency, it is not enough to push a PR with a different dependency. Verification means checking production to understand: did the system actually recover, did the defect disappear, and did the prescribed fix land?
We built that loop already for Cleric's own fixes. A separate verifier trails each issue for hours or days and checks production evidence instead of trusting the agent's answer, which also helps us build rich context for your production environment.
- 12:02 OOM alert
- 12:10 Cleric opens a PR
- 12:25 PR merged
- 12:45 Deploy complete Where most teams stop
- 2 hours later Cleric is still watching
- Memory stable
- Latency normal
- Error rate normal
- Verified
Merging the fix is not the finish line
Cleric follows the change for hours after deploy, and calls it done only when production agrees.
Now we are applying the same verification loop to every agent-generated change.
Where this is going
Autonomous delivery is our first step toward the larger shift of treating software engineering as an optimization problem.
We think this becomes outcome engineering: every change connected back to the production, product, and business outcome it was meant to create.
If code is cheap, engineering should behave more like an optimization loop: generate more ideas, ship them safely, verify what happened, keep what works, and learn from the rest.
We are starting with the part that is breaking first: everything after the PR.
Shahram Anver & Willem Pienaar
Cleric Co-founders
Try it on your own production
We're onboarding a small number of teams running coding agents in production. Leave your work email and we'll reach out.
Thanks. We'll be in touch.
We'll reach out to set up your access.
Trusted by AI-native engineering teams