Have a Working Knowledge of Everything You Throw at the AI

Industry · Working with AI

I have one rule for working with AI, and it has held up better than any other I have picked up in the last few years: never hand the machine a task you could not, at a basic level, do or check yourself. Not "do as fast," not "do as well." Just understand it well enough to know whether what came back is right.

That is a lower bar than it sounds, and a higher one than most people are clearing. You do not need to be able to hand-write the code AI wrote. You do need enough working knowledge of the language, the framework, the query, the config to look at the output and tell whether it is correct, safe, and sane. If you cannot do that, what looks like productivity is really just trust in a stranger.

I want to make the case for that rule, because the industry is quietly drifting away from it, and I think the drift is an expensive mistake: for individuals deciding what to learn, and for companies deciding who to hire.

The drift

Job postings tell the story. More and more of them lead with fluency in AI tools and treat knowledge of the actual languages the company runs on as a nice-to-have, on the theory that the AI handles that part now. The reasoning is not crazy on its face. If a model can write the Python, why screen hard for Python? Hire for the skill that directs the model and let the model supply the rest.

I understand the appeal, and I think it is a trap. A real argument does sit underneath it though, and I want to give it a fair explanation.

The strongest version of the other side

The whole history of software is a history of abstraction. We stopped writing assembly and let compilers do it. We stopped managing memory by hand and let garbage collectors do it. We stopped thinking about individual machines and let the cloud abstract them away. Every one of those shifts drew the same complaint from the generation being abstracted over, that the new school of devs don't understand what is really happening, and every time the abstraction won, and the people who clung to the lower layer spent their careers on something the field had moved past. AI, this argument goes, is simply the next layer up. Insisting that everyone still know the fundamentals is what people always say right before the abstraction makes them wrong.

That is a good argument. It is good enough that I held it myself for a while. Then I noticed where it breaks.

Why AI is not just the next compiler

The abstractions we successfully built our careers on top of share one property: they are deterministic and reliable. A compiler given the same input produces the same output every time. It does not have an off day. It does not invent a machine instruction that does not exist because it seemed plausible. It does not go down for three hours during your launch. You can trust an abstraction you cannot see inside of precisely because it is dependable. The trust is earned by consistency.

AI does not share that property, and probably will not soon. It is probabilistic. It is confidently wrong on a schedule nobody can predict. It hallucinates functions, invents APIs, writes code that runs and is subtly incorrect, and produces security holes that look exactly like working code. And it is unavailable sometimes, on someone else's schedule, not yours.

So the compiler analogy breaks at the joint that matters. We abstracted away things we could stop checking because they had earned it. AI has not earned the right to be unchecked, and it may not for a long time, if ever. Which means the layer underneath it, the actual understanding of what the code does, cannot be abstracted away yet, because you are still the error-correction layer. Remove the human who understands the fundamentals and you have removed the only thing standing between a confident wrong answer and production.

The exposure is daily

People frame this as an outage problem, and the outage problem is real, so let me put it plainly: outages happen. Constantly. Every major provider has gone down, sometimes for hours, sometimes at the worst possible moment. If your team's ability to ship depends entirely on a service you do not control, then your uptime is capped by that vendor's uptime, and you find that out the hard way the first time it goes dark mid-sprint. What happens to your product during a long outage? For a team that kept its fundamentals, the answer is "we slow down." For a team that outsourced them, the answer is "we stop." That gap is the difference between a bad day and a crisis, and you do not get to choose the day it arrives.

Framing this purely as an outage risk undersells it. The outage is just the moment a hidden dependency becomes visible. A team that never had the fundamentals is not only exposed when the AI is down, it is exposed every single day the AI is up, because it cannot evaluate what the AI produces. It cannot tell the good output from the plausible-but-wrong output. It ships the confident mistakes because it has no way to catch them. The outage does not create the vulnerability. It just reveals the one that was there all along.

That is the real cost of hollowing out the fundamentals: every day the tool is here and nobody can check its work.

This cuts both ways

If I only pointed at one failure mode, I would be making the same mistake I am warning about. There is a symmetric error, and it is just as real. The person who refuses to use AI, who insists on doing everything the slow way out of pride or suspicion, is also getting it wrong. They are giving up real leverage, and they will be out-shipped by people who use the tool well. My rule was never about distrusting the machine, and it is certainly not about refusing to use it. It is a balance, and both edges are real: know enough to check the tool, and use the tool. The engineer who can direct AI fluently and catch it when it is wrong beats both the purist who won't touch it and the vibe-coder who can't evaluate it. The goal is to keep both, the tool and the foundations.

Foundations versus interface

One framing needs to go, including in my own head, because it weakens the argument. This is not "the old way" versus "the new way." Calling fundamentals "the old way" concedes the point before the argument starts. It makes durable knowledge sound like nostalgia, like insisting on a manual transmission.

The honest framing is foundations versus interface. The interface, this month's tool, this quarter's model, the specific way you prompt, churns constantly. What you learned about the hot AI tool eighteen months ago is largely obsolete now, and what you learn today will be dated by next year. The foundations, how the language actually works, what the code is really doing, why this query is slow, where the security boundary is, barely move. They were true before this tool and they will be true after it.

So when people ask where to spend their limited learning time, the tool or the underpinnings, the churn rate answers it. Spend most of it on the thing with the long half-life. Learn the tools too, but learn them as the fast-moving surface they are, not as a replacement for the thing underneath. Investing your whole learning budget in the interface is investing it in the part guaranteed to expire.

What this means for the two decisions

For the individual deciding what to learn: use AI daily, get genuinely good at directing it, and build working knowledge of everything you throw at it. That combination, the fluent user who can still read and verify, is the most durable position in the field right now, more durable than either the pure fundamentalist or the pure prompter. When you reach for the AI to do something you do not understand, treat that as a signal to go learn the basics of it, not a reason to skip them.

For the company deciding who to hire: be careful what you are actually screening for. A candidate fluent in AI tools but unable to evaluate the output is a liability that compounds: every confident wrong answer they cannot catch ships, and you find out later. Screen for judgment, which requires fundamentals, and treat tool fluency as the easy-to-teach surface skill it is. You can teach a strong engineer your AI stack in a week. You cannot teach judgment in a week, and judgment is the thing the AI cannot supply for you.

The bottom line

Knowing how to code without the machine holding your hand should stop being treated as a quaint holdover. It is the error-correction layer, the outage insurance, and the piece that lets you tell a good answer from a confident wrong one, every day, not just on the bad ones.

Do not stake everything on a system you do not own, cannot see inside of, and did not build. Use the tool. Use it well. But keep enough of the fundamentals that when the tool is wrong, or gone, you are still an engineer, and not just someone who used to be able to ask one for help.