Most companies approach DevOps capacity the same way they have for a decade: the backlog grows, the on call rotation gets thinner, and eventually someone approves a new headcount line. That process worked when the only lever available was people. It is no longer the only lever, and treating it as if it were is now the more expensive mistake.
The AI DevOps question that actually matters is not "should we adopt AI in engineering." Most engineering leaders have already answered that one, at least in principle. The question that gets skipped is narrower and more useful: of the work sitting in front of your infrastructure team this week, how much of it is a candidate for automation, and how much genuinely requires a senior engineer's judgment? Almost nobody measures that split before making a hiring or contracting decision. This article is about how to measure it.
The hiring instinct is understandable, and usually premature
A DevOps or platform engineering backlog rarely announces itself as a capacity problem. It shows up as symptoms: pull requests waiting longer for infrastructure review, an incident response that leans on the same two or three people who know where things are actually configured, a Terraform module nobody wants to touch because the person who wrote it left eight months ago. The natural response is to add a person who can absorb some of that work.
The trouble is that a lot of what sits in a DevOps backlog is not judgment work. It is pattern work: routine Terraform changes that follow an established shape, log triage that starts the same way every time, runbook execution that a human currently does by reading a document and typing commands in order, cost anomalies that get investigated the same way each quarter. None of that requires a new person to learn your architecture from scratch. It requires someone, or something, that already has.
That is the case for measuring before hiring. Not because AI replaces a DevOps team's judgment, but because a meaningful share of what currently consumes that judgment does not need it.
What "AI-assisted" actually means here
It is worth being precise about what this does and does not mean, because the phrase "AI in DevOps" has accumulated a lot of vague marketing weight. The approach that holds up in practice is AI-assisted work with human oversight, not autonomous infrastructure changes. Every practical version of this we have seen keeps a human in the approval path.
Concretely, that looks like an AI layer working against your actual repositories, your actual Terraform state, your actual CloudWatch data and your actual runbooks, producing draft pull requests, root cause hypotheses, and documentation updates that a senior engineer reviews before anything merges or executes. The work that plausibly fits this model includes:
- Terraform and infrastructure-as-code development and cleanup
- EKS and Kubernetes troubleshooting
- CI/CD pipeline creation and maintenance
- Incident investigation and root cause analysis drafts
- CloudWatch and observability log analysis
- IAM and security configuration reviews
- Infrastructure documentation that would otherwise never get written
- Cost optimization analysis
- Routine, well-defined operational tickets
None of that list replaces the person who decides whether a production change is safe to ship. All of it removes the multi-hour version of "read logs, form a hypothesis, draft the fix, write it up" that currently eats a disproportionate share of a senior engineer's week.
What a real engagement looks like, and why it starts small
The mistake we see most often is a company trying to buy the end state on day one: a full AI-assisted DevOps operating layer, built before anyone has measured what percentage of the current backlog it would actually touch. That is backwards, and it is also how AI initiatives end up shelved after the first budget review.
The sequence that works starts with a short, bounded assessment, typically two weeks, built around three questions:
- What does the current ticket and workflow volume actually look like, categorized by whether it is pattern work or judgment work?
- Of the pattern-work category, what percentage of engineering hours does it represent today?
- What would the human-approval and security model need to look like for that percentage to be safely automated, and what does that imply for a 90-day roadmap?
Because this is a read-only assessment against real infrastructure rather than a slide deck built from a discovery call, the numbers are specific to the company, not industry averages borrowed from an analyst report. In our experience, that assessment can typically be completed and returned within 24 hours of read-only access being granted, and the strongest version of it includes one working automation implemented against a real workflow, not just a written estimate, so the customer leaves with evidence rather than a hypothesis.
What the numbers can actually look like
We are careful about which outcomes we cite publicly, and we do not attach anonymized results to a named customer. Two that we can speak to plainly: one AWS infrastructure engagement produced a 44 percent reduction in EKS costs, delivered in a single weekend as merged pull requests, with zero measured performance regression over the following 48 hours. A separate observability-focused engagement produced a 66 percent improvement in mean time to resolution alongside a 50 percent reduction in logging costs.
Neither of those numbers came from a roadmap. Both came from an assessment that found a specific, measurable inefficiency, fixed it with a human reviewing every change, and re-measured afterward. That is the model: find, fix, measure, and only then decide what else belongs on the list. For context, comparable infrastructure assessments through IBM or the AWS Marketplace commonly run in the range of $30,000 for two weeks of work, without any operating layer attached.
A short checklist before you write the next requisition
If you are staring at a DevOps or platform engineering backlog and reaching for a job posting, it is worth running through this first:
- Categorize the backlog. Split open tickets and recurring toil into pattern work versus judgment work. Most teams have never done this explicitly.
- Count the open requisitions. If you have more than one open DevOps, SRE, platform engineer or cloud infrastructure engineer requisition right now, that is itself a signal worth treating as data, not just a staffing plan.
- Ask what a new hire would spend their first quarter doing. If the honest answer is "learning our Terraform and reading old runbooks," that ramp time is itself a cost worth comparing against an assessment.
- Separate the tool question from the workflow question. The choice of which AI platform or vendor to use matters far less than which specific workflow you point it at first.
- Decide who approves what, before you automate anything. The human-approval and security model is not a detail to work out later. It is the actual product of the first phase of work.
- Measure before and after. Without a real before number, "we adopted AI in DevOps" is a claim nobody can evaluate, including you.
Why a general coding assistant does not solve this
A common objection at this point is that the engineering team already has an AI coding assistant, so the problem is presumably already being addressed. It usually is not, and the reason is worth spelling out.
A general-purpose coding assistant is trained on public code and generic patterns. It has no knowledge of your specific Terraform modules, your naming conventions, your approval workflow, or the reason a particular security group rule exists that looks wrong to an outsider but is load-bearing. Pointed at infrastructure work without that context, it produces plausible-looking suggestions that a senior engineer still has to fully re-derive and verify, which frequently costs more time than it saves.
The difference in the approach described here is that the AI layer is built around the client's own repositories, runbooks, and prior incident history from the start, not layered on top as a generic assistant. It is closer to onboarding a new engineer with full read access to your systems than to installing a plugin. That distinction is also why the assessment phase matters: it is the process of building that specific context and proving it produces a usable result before anyone commits to more.
Who owns this decision
In most organizations we work with, this sits with the CTO, VP of Engineering, or Head of Platform Engineering, often in direct conversation with whoever owns the infrastructure budget line. It rarely needs board-level sign-off to start, because the entry point is an assessment, not a transformation program. That is deliberate. The engagement ladder exists specifically so that the decision to go further is made with evidence in hand rather than a vendor's projection.
The actual question to ask this week
Before the next DevOps, SRE, or platform engineering requisition goes out, it is worth pausing on one question: has anyone actually measured how much of the current backlog is pattern work rather than judgment work? Most organizations have not, because until recently there was no practical way to act on the answer even if they had one.
That has changed. The team that can answer this question with real numbers, rather than intuition, is the team that gets to make a hiring decision instead of just an availability decision.
GMS builds AI-assisted DevOps capacity around a client's actual repositories, Terraform, AWS architecture, and approval processes, with a senior cloud engineer reviewing every change. Learn more at gmobility.com.