AI, the Great Enabler

We all know the drill by now. You paste an error message into a chat window, and out comes a fix, an explanation, and a slightly smug amount of confidence. Sometimes the fix is even correct.

These days I describe a whole tool to a machine, go refill my coffee, and come back to something that mostly works. Five years ago that sentence would have been science fiction. Today it’s just Monday.

I have spent my whole career automating things, because doing the same thing twice is against sysadmin religion. Shell scripts, Ansible playbooks, Kubernetes manifests that update themselves while I sleep. So it would be reasonable to expect that a tool which automates the automating itself fits me like a glove. And it does. But it took me a while to figure out what exactly it changed, and the answer turned out to be more interesting than “I type less now”.

What it changed is this: implementation became cheap, and judgment did not. That gap is the whole story, so let’s take it apart.

The enabler part

First, credit where it’s due, because this stuff genuinely works. Not in the demo-on-stage sense, but in the boring Monday afternoon sense.

The one-off migration script that gets run exactly once and thrown away now takes minutes instead of a few hours. The Kubernetes manifest for that one service in the homelab no longer requires me to re-derive the same boilerplate I’ve written twenty times before. An unfamiliar API no longer means seven browser tabs of documentation and a headache. And the Terraform scaffolding for yet another client environment, the kind that is almost but never quite the same as the last one, is now mostly a matter of describing it precisely.

Notice the pattern. None of these were things I couldn’t do. They were things that carried a fixed tax of assembly work, and that tax is what the machine removed. It is less “artificial intelligence” and more “friction removal at scale”.

And that is what makes it a great enabler. Ideas that used to sit in the someday pile because they weren’t worth the few hours of work now actually get built. The distance between “I know exactly what I want” and “I have a working version of it” has never been shorter. For someone who builds things for fun, this is the good timeline.

What didn’t get cheaper

Here’s the catch, though. The machine collapsed the cost of producing an answer. It did nothing for the cost of knowing whether the answer is right.

A compiler error screams at you. An LLM writes plausible, idiomatic, nicely commented code that is subtly wrong, and it does so in the same confident tone it uses when it is right. The failure isn’t loud. It is smooth. We’ve spent decades building intuition for tools that fail noisily, and now we have one that fails politely.

That means every piece of generated output arrives with an invisible attachment: a judgment call that only you can make. Is this correct? Is it appropriate for this environment? Will it bite me at 3 AM? The typing was never the expensive part of our work, even though it looked like it was. The expensive part was always knowing what to type, and that part is still fully on us.

Output got cheap. Being right didn’t.

Where judgment comes from

This is where it gets uncomfortable, because judgment is not something you can download.

My review of a generated Terraform module is worth something because I have written a lot of Terraform by hand and I know where the bodies are buried. The same goes for the homelab manifests and the shell scripts. I can smell when something is off because I’ve stepped on most of those rakes personally. Judgment is just scar tissue with a good memory.

Which raises two awkward questions. The first is what happens to my own scar tissue if the machine does all the rake-stepping from now on. Skills you don’t practice decay. Nobody who navigates exclusively by GPS can read a map anymore, and mostly that’s fine, until the battery dies somewhere interesting.

The second is where the next generation’s judgment comes from. The tasks AI absorbs best are the small, well-defined, slightly tedious ones, which happen to be exactly the tasks juniors used to cut their teeth on. A senior engineer is mostly a junior engineer plus ten thousand corrected mistakes. If the machine makes all the mistakes now, and quietly at that, someone should worry about the supply chain of experience.

The job now

So the work hasn’t disappeared. It has moved.

Where I used to spend my time producing, I now spend it specifying, reviewing, and correcting course. The role looks a lot like running a small team. You break the work into pieces the tool can handle, you mentor it when it wanders off in a wrong direction, and you review everything that comes back. Anyone who has led people will recognize the job description. The team just happens to type very fast and never gets tired of being told it’s wrong.

Reviewing, however, is the harder half of the craft, and always was. Genuinely verifying someone else’s code means simulating it in your head instead of pattern-matching “yeah, that looks right”, and that is mentally expensive. AI output is specifically optimized to look right. The plausibility that makes it useful is the same plausibility that makes it dangerous to review lazily.

And responsibility doesn’t delegate. When the generated change takes production down, “the AI wrote it” is exactly as valid an excuse as “my junior wrote it”, which is to say not valid at all if you approved it. If it merged, you own it.

One more thing

There is a concern here that has nothing to do with code quality: control. This helper of mine lives on someone else’s computer. The model, the terms, and its continued existence are all someone else’s decisions, and my newly reshaped workflow now depends on every one of them. I am not comfortable with that arrangement. Local models are the obvious answer, and whether they are actually capable and fast enough to carry this workflow is a question that deserves its own article.

Keeping the judgment sharp

I don’t think the answer is resistance. The productivity is real, the enabling effect is real, and pretending otherwise is just another form of dogma. But I do think the answer involves some deliberate discipline.

Review like you’ll be woken up by it, because you will be. Treat generated code with the same suspicion you’d give a pull request from a stranger.

Keep writing some things by hand. Not out of nostalgia, but to keep the mind sharp and the fingers warm for the day the automation does something surprising.

Understand before you approve. If you can’t explain what the code does and why, you haven’t reviewed it. You’ve just watched it scroll by.

The machine can have the assembly. The judgment stays here. Knowing what to build, whether to build it, and when it is wrong was always the actual job, and for the moment it is not up for automation.

The alternative is being a passenger, chauffeured around too fast, at the risk of being driven straight into a wall.