We will be at AI Engineer World’s Fair in SF (June 29 – July 2) Book a chat with us

A note from the founders · Early access

Software engineering is becoming an optimization problem


The old SDLC optimized for shipping change safely. The next SDLC will optimize for learning from every change. Coding agents have made implementation cheap enough that the bottleneck is no longer producing software. When generating another implementation is almost free, the goal shifts to running as many high-quality experiments as possible, keeping what works and discarding what doesn't.

Request early access

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:

The old software development lifecycle as a mostly straight road: code, review, test, deploy, with a
              few small speed bumps.
Fig. 1 · The old SDLC. Code, review, test, deploy, with a few small speed bumps.

Now it looks like this:

Today's lifecycle: a highway of riders galloping abreast from code to the PR, then a single-file
              dirt road through review, test, and deploy.
Fig. 2 · Today. A highway from code to the PR, then a dirt road to production.

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.

  1. 12:02 OOM alert
  2. 12:10 Cleric opens a PR
  3. 12:25 PR merged
  4. 12:45 Deploy complete Where most teams stop
  5. 2 hours later Cleric is still watching
    • Memory stable
    • Latency normal
    • Error rate normal
  6. 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.

Coding agent
writes the change
Cleric
refines · deploys · monitors · verifies
Regression found
Learns for the next change
Watch full
The verification loop, applied to every change — tap to watch the full animation.

Where this is going

Autonomous delivery is our first step toward the larger shift of treating software engineering as an optimization problem.

Where this goes: riders galloping the full highway through code, review, test, and deploy, all the
              way to production.
Fig. 3 · Where this goes. The highway extended all the way through production.

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 signature Willem Pienaar signature

Shahram Anver & Willem Pienaar

Cleric Co-founders

Early access

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.

No spam. We'll only email you about access.

What's true for your team? (Optional)

Thanks. We'll be in touch.

We'll reach out to set up your access.

Trusted by AI-native engineering teams