Who Runs the Infrastructure an AI Assistant Wrote?

Your AI assistant wrote the infrastructure. Someone still has to run it. That is the specific gap this post covers — ownership of an AI-generated stack after it ships, not the broader question of whether AI replaces DevOps engineers as a role (answered separately here). The short version: AI now produces the Terraform, Helm charts, and CI pipelines competently, but state, permissions, cost, and incidents live outside the code, and that is where AI-built startups get hurt first. For a 10-person team the practical answer is that you need less routine DevOps labour than before and exactly as much DevOps judgement — which changes how you buy it, not whether you need it.

We sell DevOps services, so discount accordingly. But we’ll try to earn the click by being specific about what AI has genuinely taken off our plate.

What does AI genuinely do well for infrastructure right now?

A lot, and it would be silly to pretend otherwise. Used well, current AI assistants reliably produce first-draft Terraform modules, Kubernetes manifests, Dockerfiles, and GitHub Actions workflows that are most of the way there. They’re excellent at explaining an unfamiliar codebase, translating between clouds, and debugging from a pasted stack trace or pod log.

Concretely, the tasks that have gotten dramatically cheaper:

• Boilerplate IaC — a VPC module, an EKS/GKE/AKS cluster config, an IAM policy draft
• CI/CD scaffolding — pipelines, Dockerfiles, Helm charts
• Explanation and translation — “what does this module do,” “convert this to Azure”
• First-draft runbooks and docs — the writing nobody used to do at all

If your mental model of DevOps is “the person who writes YAML,” that job has largely been automated, and we say so plainly in our 2026 reality check on AI replacing DevOps engineers.

Where does AI still fail on infrastructure?

AI fails wherever the truth lives outside the repo. Application code is self-contained: the model can read all of it, and tests tell it when it’s wrong. Infrastructure is different — the real system is the live cloud account, and the code is only a claim about it. Five failure modes come up constantly:

State. Terraform state, drift between code and the live account, resources someone clicked into existence in 2024 — the model can’t see any of it, and a confidently generated terraform apply against drifted state is how you delete a database. This is the core problem we walk through in whether AI agents can safely run Terraform.

IAM. Generated IAM policies tend toward whatever makes the error go away, which is usually too broad. Nobody notices until an auditor or an attacker does. Least-privilege design requires knowing which humans and services exist and what they should never be able to do — organizational context, not code.

Cost. AI will happily provision resources; it has no idea what your bill looks like, whether you should be on savings plans or committed use discounts, or that the staging environment nobody uses costs four figures a month. Cloud bills are an accumulation problem, not a code problem — the pattern we dissect in the anatomy of a startup AWS bill.

Incidents. At 3 a.m., with a paying customer down, the question is rarely “write me some code.” It’s “which of these five plausible causes is real, what’s safe to try, and what makes it worse?” That’s pattern recognition from having seen a hundred outages, plus the authority to make a judgment call under uncertainty.

Judgment. Should you be on Kubernetes at all? Multi-region now or later? Which compliance framework first? AI will argue any side fluently. Someone accountable has to decide.

What does this mean for a 10-person startup?

You need fewer DevOps hours and better DevOps judgment — a senior operator, part-time, rather than a junior one full-time. AI compressed the routine work (the YAML) but not the accountable work (the system). Here’s how we’d split it for a typical seed-to-Series-A team:

Task	AI alone is fine	Needs an experienced human
Draft a Terraform module	✅	Review before apply
CI pipeline for a new service	✅	Spot-check secrets handling
IAM and network boundaries	❌	Design and own
Cost strategy and commitments	❌	Own
Production incident response	❌	Own, with AI as an accelerant
Architecture and compliance decisions	❌	Own

There’s also a newer wrinkle: AI increases shipping velocity, which increases infrastructure exposure. Teams that vibe-coded their way to product-market fit hit a wall of unowned infrastructure — we wrote a production-readiness checklist for exactly that situation. The faster AI lets your engineers ship, the sooner someone has to own the ground it all runs on.

Should you hire for this or buy it fractionally?

For most teams of 5-25 engineers, this is now clearly a fractional buy. The old case for a full-time DevOps hire was volume: enough YAML, pipelines, and toil to fill a week. AI ate the volume. What’s left — architecture decisions, IAM and cost ownership, incident leadership, compliance groundwork — is high-judgment, low-hours work, which is precisely the shape a monthly DevOps retainer is built for. A senior operator a few days a month, using the same AI tooling your engineers do, covers what used to take a full-time salary — across AWS, GCP, or Azure.

The honest caveat: if you’re running genuinely complex infrastructure — heavy data platforms, strict latency SLAs, dozens of services — you’ll outgrow fractional and should hire. Most 10-person startups are years from that point.

If you want a concrete starting point rather than a philosophy, our audit and package pricing shows what “someone owns the right column” costs in practice. So: do you still need DevOps if AI writes the code? You need it differently. The typing got cheap. The responsibility didn’t.