# What an LLM can and can't do in your infrastructure > After twenty years of keeping systems running and a couple of years deep in LLMs, an honest split: where AI genuinely helps an ops team, and where it's a liability waiting to happen. Source: https://rfriedmann.de/blog/llms-in-your-infrastructure/ Published: 2026-06-08 · Track: learn · Level: Ops Every infrastructure team is being sold AI right now, hard. After two decades of keeping real systems running, and a couple of years deep in how LLMs actually [work](/blog/what-is-an-llm/), I have landed on a split that has served me well. It is not "AI good" or "AI bad". It is "AI in the right seat". ## The one mental model that matters An LLM is a fast, fluent, confidently wrong junior. That is the whole thing. It will produce a plausible answer to almost anything, instantly, in your exact format, and it has no idea when it is wrong. It [predicts likely text](/blog/what-is-an-llm/), not true text. That single property decides everything. It makes the LLM a force multiplier for a senior who verifies, and a hazard for a team that trusts. Same tool, opposite outcomes, and the difference is entirely in how you hold it. ## But the model matters, enormously "Confidently wrong" is the failure mode, not a fixed error rate, and the rate varies considerably with which model you actually point at the problem. A small local model is a genuinely unreliable intern. A frontier model like Claude Opus is a different proposition: it gets things right most of the time, often strikingly so, and the serious errors are rare. The gap between the two is large, and it is widening with every release. That spread should certainly change how hard you lean on the thing. It should not change whether you check it. The discipline is identical at both ends, read it, question it, test it; the better model just means your check passes more often. The day you stop verifying because "Opus is basically always right" is the day the one rare, fluent, confident mistake walks straight into production. Calibrate your trust to the model; never calibrate it to zero. ## Where it earns its keep

Genuinely useful

A liability

The pattern in the left column: the input is messy or in natural language, and a human checks the output before it touches anything. The pattern on the right: the model is trusted to be correct, or allowed to act on its own. Cross that line and you have handed production to a confident junior with no supervisor. ## The hallucination tax Here is the part the demos skip. A wrong config that *looks* right is worse than no config at all, because no config fails loudly and a plausible-but-wrong one fails at 3 a.m. in a way nobody predicted. The model's fluency is the danger: the output is always well-formed, so "looks correct" tells you nothing. A great deal of this is a context problem. A model invents most when the relevant facts are not actually in front of it, so the more of the real situation you can fit in its window, the less it has to guess. It is the other place the bigger models pull ahead: a 200k-token context sounds enormous until you hand it a real codebase or a pile of configs and logs, where it is frequently not enough. The million-token windows on the larger frontier models are genuinely pleasant in practice, you give them the whole picture instead of a curated slice, and they stop filling the gaps you left with confident fiction. It helps, but it does not get you off the hook. So verification is not an optional extra, it is the price of admission. The honest question for any AI workflow in ops is never "can the model do this?". It is "can I check its work faster than I could have done the work myself?". When the answer is yes (reading a draft script, sanity-checking a log summary), you win. When it is no (trusting a one-shot answer about something you cannot easily verify), you have just moved the risk somewhere you cannot see it. ## Where I actually let it near my infra In practice it comes down to two dials: how good the model is, and how good my guardrails are. For a quick one-off, a systemd unit, an nginx block, a throwaway script, I read it like a junior's pull request and run it myself. At that size, reading every line is the right move, and it works. What I will not pretend is that "read every line" scales. It does not, and acting as though it did would flatly contradict the fact that I [hand an agent the keyboard to build a whole CUDA engine](/blog/writing-cuda-with-an-agent/), far more code than anyone could review by hand. Past a certain size you change the approach: instead of reading everything, you make a mistake cheap and reversible, then give the model real room to work. [Scoped credentials, least privilege, everything in git, actual gates](/blog/llms-in-the-terminal/), that is the room. Inside a room like that, a capable model can be left to get on with it, because the room keeps it safe, not your constant attention. So it is not "never give it the keys", I give these models a great deal of latitude every day. It is "never give it keys to a room you cannot undo". Trust is still earned per change, still calibrated to the model and the stakes, but *how* you grant it scales: from reading every line of a throwaway script, to trusting the guardrails around an agent writing a hundred thousand. The discipline twenty years of ops instils in you was never "trust nothing". It is "build the room before you hand over the keys". Underneath all of it sits one shape worth keeping in view: AI proposes, a human disposes. The model drafts, a person approves, and only then does the system act.
AI proposes, a human disposes
[diagram omitted — see the page for the chart]
AI earns its place by drafting for a human to approve, not by acting on its own.