We use AI tooling heavily in our own engineering work. It is a significant part of how a small senior team covers the scope it does. It is also routinely oversold, in ways that would be actively dangerous if taken literally in an infrastructure context.
Both things are true, so it is worth being specific about which is which.
Where it genuinely helps
Investigation across scattered evidence. A production question usually means reading across log streams, metrics, Terraform, Kubernetes manifests and provider configuration at the same time. Assembling that context is a large part of the work, and it is work AI tooling does well — pulling together what is relevant, summarizing what a config actually does, surfacing the inconsistency between two files nobody thought to compare. It compresses the slowest part of diagnosis, which is orientation.
Drafting infrastructure code. A first pass at a Terraform module, a Kubernetes manifest, a pipeline definition. The draft is usually structurally reasonable and specifically wrong — plausible resource arguments that do not exist, defaults that are unsafe for production, a security group rule wider than intended. Reviewing and correcting a draft is faster than writing from scratch, provided you actually review it. That proviso is the entire risk.
Documentation, which otherwise does not get written. Runbooks, architecture notes, the description of why a subnet layout is the way it is. This is the clearest win, because the realistic alternative is not better documentation — it is none. Generated from the actual code and corrected by the engineer who did the work, it is genuinely useful, and it stays current at a fraction of the effort.
Repetitive change across many places. Applying the same mechanical edit across forty repositories, normalizing tagging, updating a deprecated API version everywhere it appears. Tedious, error-prone by hand, and well suited to automation with review.
Where it does not belong
Autonomous changes to production. Not because a model cannot generate a correct change — often it can — but because the failure mode is unbounded. An infrastructure change that looks reasonable and is wrong can delete a stateful resource or open a network path. The value of a human approving the change is not that humans are better at generating it. It is that someone with context is accountable for the consequence, and can recognize the specific case where the reasonable-looking change is catastrophic here.
Security decisions. A model will produce IAM policies that work. Working and least-privilege are different properties, and the gap between them is exactly the thing an attacker uses. Access decisions need someone who understands the trust boundary and who is responsible for it.
Architecture. Architecture decisions are trades against constraints that are mostly not in the code: cost, team capability, growth expectations, regulatory position, what the organization can operate. A tool without that context will produce a defensible-sounding answer to the wrong question.
Incident response, past the first few minutes. Early on, help assembling context is useful. Once you are deciding what to change under time pressure with partial information, that is judgment, and it should stay with the engineer who will answer for the outcome.
The pattern
The distinction is not about difficulty. It is about whether the output can be verified before it matters.
A drafted Terraform module can be read, planned and reviewed before anything happens. A log analysis can be checked against the logs. Those are safe places for AI leverage, because a wrong answer is caught by a step that already exists.
An autonomous production change cannot be verified before it matters — verification is the thing that was skipped. Same for a security posture nobody examined and an architecture nobody argued about. In those cases the error surfaces after it has already cost something.
What this means for how we work
Concretely: AI tooling is part of normal delivery here. It reads and writes code, drafts documentation, assists investigation, automates routine operations. Nothing reaches a production environment without an engineer having reviewed it and being accountable for it, and change controls agreed with the customer apply regardless of how the change was drafted.
That is the whole claim, and it is deliberately unexciting. AI increases our engineers' leverage. Experienced engineers remain responsible for architecture, judgment, validation and production outcomes. If a provider tells you differently about your infrastructure, the interesting question is who is accountable when the automation is confidently wrong.