The Cleric Class: FinOps, DevOps, SRE

The Cleric Class: FinOps, DevOps, SRE
The Cleric Class: FinOps, DevOps, SRE

The Cleric class is also the people on your development teams who are constantly after you with questions like: do we really need to have a planning meeting? Do we really need to have approval for a change? I don't even know what the model is trying to do to production, and you're going to ask me to justify it? Some of these practices are there for a reason, and the Cleric class is there to maintain standards. But in an age of AI and automation and generative agentic systems, there are valid conversations happening about whether or not some of these roles should still exist. Do you need a team of FinOps specialists when you can ask an inference engine to review everything, identify savings opportunities, and then execute to achieve them? Do you need to employ four or five people to do those calculations independently? Maybe, maybe not — that's not the point of this book.

The point of this book is to point out that there are various people in your IT department who are being affected by AI and who have opinions and anti-patterns related to it. The Cleric class captures the people who are focused on the various rituals that keep your systems safe, secure, and cost-effective. We're talking FinOps. We're talking InfoSec. People who follow a process — DevOps, SRE, platform engineering, the ones who make sure the build pipeline exists, the documentation gets written, the retro actually happens.

Some of them are adapting to AI very, very well. FinOps is an example of that — cost monitoring, anomaly detection, automated reporting, a lot of the FinOps toolkit maps cleanly onto AI-assisted workflows. Others are not. DevOps may or may not be adapting to AI well — it depends. Some of the things AI is doing threaten the very jobs these people have, so there are a lot of skeptics in this group. Others are eager to embrace the tools, maybe too eager.

But there are anti-patterns that Clerics exhibit, and they're very often people rededicating themselves to the rules, the rituals, or using AI to double down on existing practices. The practices they spent years refining were built for a world where code came from people, where review meant a human reading a diff, where documentation was written by someone who understood the system. AI tools don't just add new capabilities — they change what "done" looks like, what "reviewed" means, and what "tested" actually proves.

The first anti-pattern is Ritual Without Belief: the team maintains every step of the old process — the ticket templates, the approval gates, the mandatory documentation — but nobody remembers why each step exists. They go through the motions because stopping feels riskier than continuing, even when the steps no longer catch anything. The ritual becomes organizational superstition. You do it because the last time you skipped it, something broke, even though the thing that broke had nothing to do with the step you skipped.

The second is Governance Theater: the Cleric builds elaborate review processes for AI-generated code that mirror the processes used for human-authored code, but the volume makes meaningful review impossible. Every pull request gets a ticket, every ticket gets a reviewer, every reviewer approves in under two minutes because there are forty more in the queue. The process exists on paper, but in practice it's a rubber stamp with extra steps, and the Cleric knows it — but stopping the process would require admitting that the review standard has changed, and nobody is ready to have that conversation.

The third is Sanctimony as Shield: the Cleric uses process compliance as a defense against the anxiety of not understanding what AI is doing. If the documentation is complete, the checklist is filled out, and the approval chain is followed, then the system is "governed" regardless of whether anyone actually understands the output. Process becomes a way to feel responsible without actually being responsible.

The counter-move is not to abandon process. It's to audit which steps are still catching real problems and which are theater. If a step hasn't prevented a failure in six months, it's not a safeguard — it's a habit. The Cleric's value was never the ritual; it was the judgment behind it. When the judgment goes, the ritual is just noise, and noise is what AI is best at producing.


HQ 7 — Guided. Human led the creation, AI filled gaps and expanded points.


The Cleric Class is one of the developer classes in The AI Developer's Field Guide, a field guide to the anti-patterns AI brings to software engineering.