Using AI Without Becoming Its Intern

Everybody I watch use AI falls into one of two ditches. The first group treats it like an oracle: whatever comes out of the box gets pasted into the ticket, the document, the codebase, unexamined. The second group tried it once, got a confident wrong answer, and wrote the whole thing off. Both groups are wrong for the same reason. Neither one has figured out what the tool actually is.

I use AI every day, on real work, and I ship the results. This is what I've learned about where it belongs and where it doesn't.

What AI is not

It is not an authority. A model will give you a wrong KB number, a wrong command flag, and a wrong registry path in exactly the same calm, fluent tone it uses for the right ones. Fluency is not accuracy. The output reads like it was written by someone who knows, and that is precisely the trap, because nothing behind it knows anything in the way you mean knowing. It predicts. Sometimes it predicts the truth, because the truth is what usually comes next in text like yours. It has no way to tell the difference, and it will never warn you which kind you got.

It is not a database or a search engine. It does not look things up unless you bolt that on. It reconstructs from memory of patterns, and reconstruction drifts. Ask it for a fact and you get the shape of a fact.

It is not a worker you can leave alone. People talk about "AI agents" doing jobs end to end. What I see in practice is that unsupervised model output decays. It starts strong, then it gets lazy, then it starts agreeing with itself, then it produces something plausible-looking that falls apart the first time a human actually checks. The failure is never announced. It arrives formatted nicely.

It is not good at mechanical work. This one surprises people. Give a model a repetitive, rule-based task — scrub these logs, redact these names, parse these files — and it will do it variably. Ninety-nine files fine, one file quietly wrong, no log of what it decided or why. Mechanical work demands the same result every time, and a model is built to give you a likely result every time. Those are different things.

What AI is

It is the fastest junior collaborator you will ever have. Brilliant recall of patterns, tireless, instant, and with no judgment of its own and no stake in being right. Treat it exactly like a gifted junior engineer: let it draft, let it research, let it propose — and review everything before it ships, because reviewing is your job in the relationship.

It is a force multiplier, and it multiplies whatever you bring. If you already know the domain, AI makes you dramatically faster, because you can smell a wrong answer. If you don't know the domain, it makes you confidently wrong at industrial speed. The tool does not supply the expertise. It amplifies the operator.

It is best at judgment-shaped work. Synthesis. Drafting. Talking a problem through. Second opinions. Reviewing something you wrote and finding the hole in it. The shape of the task matters more than the size of the model.

How I use it

1. Scripts for the mechanical, models for the judgment.

When I needed logs scrubbed before analysis, I didn't ask a model to scrub them. Models are wrong for that job for all the reasons above. I had the model help me write a Python scrubber — a script, with rules, that does the same thing every run and whose misses I can enumerate and fix permanently. Then the models got the scrubbed output and did what they're actually good at: reading it and reasoning about it.

That split is the whole ballgame. Have the competent AI build the tool. Let the tool do the repetitive part forever. Spend the model on thinking.

2. If you can't explain it, don't ship it.

Every AI-assisted thing I release, I can defend line by line, because I checked it line by line. The day I ship something I don't understand is the day I became the intern — fetching output for a boss I can't evaluate, hoping it's right. Your name goes on the work. The model will not be in the meeting when it breaks. Vet the output against reality: run the command, check the link, compare the hash. Trust is earned per output, never granted to the tool.

3. Make models check each other.

One model's word is an opinion. So I run my important work past a second model with instructions to attack the first one's output, and I grade what survives. You would not ship code on one engineer's unreviewed say-so. Don't ship AI work on one model's say-so either. Disagreement between models is not a problem; it's the most useful signal in the whole process, because it shows you exactly where the soft spots are.

4. Match the model to the stakes.

There is a whole hobby now of building enormous local rigs — racks of old datacenter cards drawing 1,800 watts in a basement — to run small open models at home. I understand the appeal and I still think it's mostly a space heater with a chat window. A small local model is fine for small local tasks. For real work, use a real model. Benchmarks won't tell you which is which, by the way. Benchmarks measure how a model does on an exam written for it. Work measures whether it can hold a hard problem together for three hours without going quietly stupid. Those are not the same measurement, and the gap between them is where all the disappointment lives.

5. Say what you did, plainly.

AI tools did the building on my projects. I did the designing, the deciding, and the verifying. I say that up front, in those words, and I've never once had it held against me — because the alternative, pretending, insults everyone's intelligence and collapses the first time someone asks you a follow-up question you can't answer. Disclosure is not a confession. It's a spec sheet.

The test

Here is how you know which side of the line you're on. If the AI went down tomorrow, could you still do your job? Slower, sure. Annoyed, absolutely. But could you?

If yes, you're using it right: it's a tool in your hand, and the expertise lives in you.

If no — if the work stops when the chat window closes — then you have it backwards. You're not the engineer with an AI assistant.

You're the assistant. And the AI is not paying you enough to be its intern.


Daniel Barnes

Fort Worth, TX.

Technical Support Engineer, VMware Cloud Foundation Division at Broadcom. Customer-facing work on VMware vSAN, ESXi, and VMware Cloud Foundation — storage, HCI, and virtualization troubleshooting.

Started in 2018.

Homelab is a 3-host vSAN ESA cluster on ESXi 9.1 running self-hosted services (Nextcloud, Pi-hole DNS, Veeam). That's where the write-ups come from.