DevOps Skill Ceiling: Where AI Automation Stalls for Infrastructure Engineers

Sarah Friar, CFO at OpenAI, recently published five lessons from building an “AI-native finance function.” Automated forecasting. Stronger controls. AI ROI calculations. It sounds impressive. It reads like the future of work has arrived and it’s wearing a tidy spreadsheet.

I don’t work in finance. I manage multi-cloud infrastructure. And I’ve spent the last eighteen months watching teams in my world adopt the same category of tooling — AI assistants that promise to handle the boring parts of ops. The results are not what the demo decks suggest.

Here’s what the skill ceiling actually looks like when you’re the person responsible for keeping three clouds running without burning the budget or the on-call rotation.

The Beginner Win Is Real. Don’t Dismiss It.

Let me be fair upfront. The first time you point an AI assistant at a Terraform state file or a pile of CloudWatch logs, something genuine happens. It finds the misconfigured security group. It explains why the prod cluster kept restarting at 3 AM. It drafts a remediation script that mostly works on the first run.

That part is real.

For a junior engineer or someone rotating onto a new stack, this is a massive lever. The time-to-first-understanding compresses from days to hours. I’ve seen a mid-level engineer debug a cross-account IAM issue in an afternoon using an AI assistant that would have taken them two days of documentation spelunking before.

The catch is that the beginner win curve looks like a hockey stick that flattens faster than expected. And it doesn’t plateau where you think it will.

Where the Curve Flattens: The Expert Plateau

I expected the tool to keep saving time as I got more sophisticated with my prompts. What actually happens is closer to shifting the work.

At the beginner level, the AI is doing pattern matching against well-documented problems. At the expert level, you’re asking it to reason about your specific infrastructure — the weird network topology your predecessor built, the legacy app that only runs on a specific kernel version, the cost anomaly that only appears on the third Tuesday of the month.

You know what the AI does with those situations? It produces confident-sounding guesses that require you to verify everything anyway.

The verification cost is the hidden tax. You still have to check. The output looks clean. It cites plausible AWS documentation. The logic chain seems coherent. Then you notice it suggested enabling public access on an S3 bucket to “simplify the deployment.”

That is not a simplification. That is a breach waiting to happen.

A Concrete Workflow: The Incident Response Test

Let me give you a specific scenario. You’re on call. 2:47 AM. The payment service in us-east-1 starts returning 503s. The standard runbook says check the database connection pool, verify the auto-scaling group, confirm the load balancer health checks.

Without AI assistance: You open three terminal windows. You check the metrics dashboard. You notice the connection pool is exhausted. You look at the database and see a slow query that’s been running for forty minutes. You kill it, restart the connection pool, and the service recovers. Total time: 22 minutes.

With an AI assistant: You paste the error logs into the chat. It asks clarifying questions. It suggests checking the connection pool. Then it suggests checking the network ACLs, the Kubernetes ingress, the service mesh configuration, and the database replication lag. It gives you a seven-step diagnostic plan that would take you through three different systems. The response is thorough. It’s also wrong about the priority order — it can’t know that the slow query has been a recurring issue for weeks and that you’ve already ruled out the network path.

You ignore the AI’s plan and follow your instinct. Recovery time: 19 minutes. The AI cost you four minutes of reading time during an incident. In on-call math, four minutes at 3 AM feels like forty.

Does that mean the AI is useless? No. It means the expert plateau isn’t about the AI’s ceiling. It’s about yours. The better you are at your job, the more the AI’s suggestions feel like noise against your contextual knowledge.

Comparison: What You’re Already Using

Let’s be honest about the alternatives. You already have tools that do parts of this job well.

Runbooks and documentation: Boring, static, incomplete. But they encode the hard-won lessons from the incidents that actually happened in your environment. An AI assistant generates plausible procedures. A runbook documents what worked. The runbook is never confident in the wrong direction.

Monitoring dashboards (Grafana, Datadog, CloudWatch): These don’t tell you what to do. But they show you the current state without interpretation. The AI assistant is essentially a middleman between you and the data — and every middleman introduces latency and possible distortion. Dashboards don’t hallucinate.

Infrastructure-as-code validation tools (Checkov, tfsec, Terrascan): These are narrow, rule-based, and deterministic. They don’t offer creative suggestions. They also don’t accidentally recommend exposing your database to the world. The trade-off is obvious: limited scope, but zero hallucinations.

The AI-native finance function that Friar describes works because finance is a domain with strong, well-defined patterns. Invoicing, forecasting, reconciliation — these are bounded problems. Multi-cloud infrastructure is not bounded. It’s an accumulation of decisions, some of them bad, made over years by different people with different priorities.

You cannot prompt your way through that history.

Where AI Actually Helps: The Unsexy Middle

It’s not all bad news. There is a sweet spot, and it’s not where the marketing points.

The real value shows up in the unglamorous, repetitive work that sits between the beginner tasks and the expert judgment calls. Writing boilerplate Terraform modules. Generating CloudFormation templates from a rough description. Summarizing a long sequence of CI/CD logs to identify the first failure point. Translating a legacy shell script into a maintained Python script.

That work is tedious. It doesn’t require deep contextual judgment. And the AI is good at it. I’ve seen a team cut their time on environment provisioning from two hours to thirty minutes using an assistant to scaffold the base configuration. The savings compound.

But here’s the inconvenient part: the team that saved that time still needed to review every line. The AI didn’t remove the review burden. It changed where the review happened — earlier in the process, on less critical files. The verification cost didn’t disappear. It moved.

Who Should Ignore This Entire Category

If you’re a solo engineer, a small team, or a company with a single cloud provider and a well-maintained infrastructure, skip it. The AI’s outputs will add review overhead without proportional benefit. Your context is small enough that you already know the system better than a general-purpose model ever will.

If you’re on a large team with multiple clouds, complex networking, and a deep history of undocumented decisions, you can still skip it. The model will not know your history, and you will pay for that ignorance during incidents.

The tool is for teams with enough scale that the routine work is genuinely overwhelming — and with enough process discipline to enforce verification on every AI suggestion. That is a smaller set of organizations than the hype cycle suggests.

Verdict: Pilot, With Conditions

Adopt it — narrowly. Do not let your team point an AI assistant at production infrastructure without guardrails. Do not use it during incident response. Do not use it for anything that touches security boundaries.

Use it for scaffold generation. Use it for log summarization. Use it for documentation drafting. And pair it with a mandatory human review gate that treats every AI suggestion as a junior engineer’s first draft — plausible, possibly useful, and absolutely not ready for production without a senior eye.

That part of the workflow is real. The rest is friction. The tool does not remove the judgment call — it relocates it. If your team has the process discipline to handle that relocation, you’ll see modest efficiency gains that compound over time.

If you don’t have that discipline, the AI will not give it to you. It will just make your mistakes faster.

Source

https://openai.com/index/building-an-ai-native-finance-function