AI is a tool. Nothing more. Nothing less.
It is not inherently good or evil, and I think the industry is making a mistake by treating it differently from every other abstraction engineers have adopted over the last few decades. The reaction to it — the hand-wringing, the gatekeeping, the quiet suspicion that using it is cheating — says more about how we evaluate engineers than it does about the tool.
We don't shame engineers for any of the others
We don't shame engineers for:
- using IDEs instead of writing raw assembly
- reaching for Stack Overflow instead of memorizing every API surface
- using Terraform instead of clicking through a console to provision infrastructure
- using Kubernetes instead of orchestrating containers by hand
- using libraries instead of reimplementing every algorithm from scratch
Every one of those tools did the same thing: it raised the floor of what a single engineer could accomplish in a day. None of them removed the need to understand the system underneath. The engineer who reaches for Terraform still has to know what a bad plan looks like before they apply it. The one who pulls in a library still owns its failure modes in production.
AI does exactly this. It amplifies. It does not absolve.
The question was never "are people using it"
The concern shouldn't be "are people using AI?" Of course they are. They should be. Asking the question that way is a category error — it's the same energy as asking whether engineers should be allowed to use compilers.
The concern is whether someone understands the output they're shipping.
- Can they explain the architecture, or just describe it?
- Can they reason about the failure modes before they happen?
- Can they debug the generated code when it breaks at 2am?
- Can they operate the system safely under pressure?
- Can they tell when the model is confidently, fluently wrong?
That last one is the new skill, and it's the one that matters most. A model will hand you a plausible answer with the same tone whether it's right or catastrophically off. The judgment to catch that doesn't come from the tool. It comes from the engineer.
What AI actually changes about evaluation
Here's the part the industry keeps getting backwards.
Strong engineers become faster with AI. Weak engineers become more visible with AI.
The tool didn't create the gap. It surfaced one that was always there. When generating polished output was slow and expensive, a shallow understanding could hide behind the effort it took to produce anything at all. Now the output is cheap and the polish is free, so the only thing left to evaluate is the understanding behind it — and that's exactly the thing a lot of our processes never measured well in the first place.
That's not a failure of the tool. That's a failure of evaluation and hiring processes that mistake polished output for actual understanding. AI just removed the cover those processes were leaning on.
We have run this experiment before
We have a long history of tools that were supposed to ruin the discipline they touched, and didn't:
- The calculator didn't destroy mathematics. It moved the work up a level, to the part that was always the point.
- Compilers didn't destroy programming. Almost no one hand-writes assembly now, and software got more ambitious, not less.
- Cloud providers didn't destroy infrastructure engineering. They turned racking servers into designing systems.
Each one provoked the same panic, and each time the panic mistook the mechanics for the discipline. The mechanics got automated. The discipline got more important.
AI won't destroy engineering either. But it will keep raising the value of the things it can't do for you: judgment, systems thinking, and real operational experience. The market for typing code faster is collapsing. The market for knowing what's worth building, why, and what breaks when it's wrong is wide open.
The takeaway
- Treat AI as an abstraction, not an exception. It belongs in the same lineage as the compiler and the cloud — adopt it, and hold it to the same standard.
- Stop policing usage. Start measuring understanding. "Did they use AI" is the wrong question. "Can they explain, debug, and operate what they shipped" is the right one.
- Fix the evaluation, not the tool. If polished output is fooling your hiring process, the tool didn't break it — it revealed it was already broken.
- Invest in the part that doesn't automate. Judgment under uncertainty and operational experience were always the job. Now they're the whole job.
The one-line version
AI is a tool like every abstraction before it: it makes strong engineers faster and weak engineers more visible — so stop asking whether people use it and start asking whether they understand what they ship.