# LLMs in the terminal: a sysadmin's honest list

> The concrete, everyday ways an LLM actually earns its place in a sysadmin's workflow, and the handful of rules that keep it from causing real damage.

Source: https://rfriedmann.de/blog/llms-in-the-terminal/
Published: 2026-06-10 · Track: learn · Level: Ops

The previous post drew the [line between helpful and hazardous](/blog/llms-in-your-infrastructure/).
This one is the practical follow-up: the specific things I reach for an LLM for in
a terminal, day to day, and the rules that keep it useful instead of dangerous.

## What it's genuinely good for

None of these are glamorous. All of them save real time.

- **"What is this error actually telling me?"** Paste a cryptic stack trace or a
  kernel log line and get it in plain words. Faster than guessing the right search
  query, and a useful starting point even when it is only half right.
- **First-draft config.** A systemd unit, an nginx server block, a cron entry, an
  Ansible task. It gets the boilerplate right so you spend your attention on the
  three lines that actually matter.
- **Throwaway scripts.** The one-off `awk`/`jq`/`bash` thing you would otherwise spend
  twenty minutes remembering the syntax for. You read it, you run it, you delete it.
- **Log triage.** "Here are 4,000 lines, what changed and what looks abnormal." A
  summary to orient you, not a verdict to trust.
- **Regex and one-liners.** The kind of thing nobody memorises. Describe the input, get a
  draft, test it on real data before you believe it.

The common thread: the model produces a *draft*, and the cost of checking it is
low because you can read it before it does anything.

## The rules that keep it safe

The failure modes here are all the same shape: trusting fluent output. So the
rules are about never doing that.

The shape of every safe interaction is the same: a step in the middle where you, not the model, decide whether the command runs.

<figure class="chart"><div class="chart-title">The terminal workflow with the human-read gate</div>[diagram omitted — see the page for the chart]<figcaption class="chart-caption">The LLM suggests, but you read every command before it runs.</figcaption></figure>

<aside class="defbox"><span class="tag">The one rule</span>Read before you run. An LLM's output is a suggestion from a fast junior, never a command. If you can't read it well enough to vouch for it, you're not ready to run it.</aside>

- **Never pipe model output straight into `sudo`, `sh`, or your cluster.** "Looks
  fine" is not review. Paste it into an editor, read it, then run it yourself.
- **Keep secrets out of the prompt.** Tokens, keys, internal hostnames, customer
  data. Assume anything you paste could be logged somewhere you do not control.
  Self-hosting changes this calculus, which is its [own post](/blog/self-hosting-an-llm-for-your-team/).
- **Verify against reality, not impressions.** Test the regex on real input, run the
  script in a sandbox, diff the config against a known-good one. The model is
  confident either way; your check is the only signal that means anything.
- **Do not let it operate unattended.** Drafting is fine. Acting on production
  without a human in the loop is where the time you saved gets repaid with
  interest.

## Build the guardrails, not just the habits

Rules that depend on you being sharp every single time will fail on the day you are
tired. Guardrails do not. The stronger move is to set things up so a mistake, yours
or the model's, is cheap and reversible by default.

- **Separate credentials for anything AI-assisted.** Never point an LLM workflow at
  your personal or admin login. Give it a dedicated identity, so its blast radius
  is its own and you can revoke it in one move.
- **Least privilege, always.** Grant that identity the minimum it needs and nothing
  more. If a task genuinely needs more, hand it over temporarily and take it back
  when the task is done. "It was easier to just give it admin" is the opening line
  of the post-mortem.
- **Put everything in git.** When the config, the scripts, the infra live in
  version control, any change, including a bad one, is a diff you can review and a
  command you can undo. Reversibility turns a mistake from an incident into a
  `git revert`.
- **Build gates.** A test suite, a CI check, a linter, a dry-run, a staging
  environment. Something automatic that a wrong change has to clear before it
  reaches anything that matters. The model writes the change; the gate decides
  whether it lands.
- **Test it somewhere safe.** Run it in a sandbox or against throwaway state first.
  The whole point of the steps above is that "let us see if this works" costs you
  nothing.

This is the same principle that lets me hand an agent the keyboard to [write an
entire CUDA engine](/blog/writing-cuda-with-an-agent/): you do not trust the output,
you gate it. The habits keep you careful; the guardrails keep you safe on the days
you forget to be.

## The honest summary

<div class="compare">
<div><h4>Reach for it</h4><ul>
<li class="has">Messy input, you'll check the output</li>
<li class="has">Boilerplate and forgotten syntax</li>
<li class="has">Orienting yourself in a wall of logs</li>
</ul></div>
<div><h4>Don't</h4><ul>
<li class="no">Anything that runs without you reading it</li>
<li class="no">Prompts containing secrets</li>
<li class="no">Treating an answer as ground truth</li>
</ul></div>
</div>

Used like this, an LLM is one of the better additions to a terminal in years: it
removes the tedious lookups and drafts the boring 80%, and leaves the judgement,
the part that actually needs twenty years of hard-won experience, exactly where it
belongs. With you.