Have a Working Knowledge of Everything You Throw at the AI

Industry · Working with AI

Try to always have basic knowledge of what you are handing to an AI agent. Drifting away from this premise will almost always cost you in the long run. Don't look at it as you being able to build as fast or as well as an AI agent, just understand it well enough to know whether what came back is right.

It's honestly not as hard as it sounds, but many don't even bother thinking twice about it. You do not need to be able to hand-write the code that AI generated. You should at least have enough working knowledge of the result to tell whether it is correct, as well as, safe. If you cannot do that, what looks like productivity is really just blind trust.

The industry is seriously drifting away from that mindset, and the drift is an expensive mistake for individuals deciding what to learn, and for companies deciding who to hire.

The drift

Job postings on LinkedIn and Indeed tell you all you need to know. 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 technically understandable because if a model can write 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, but i think there's a real pitfall there. There is, however, a valid counter argument.

The strongest version of the other side

The whole history of software is an ever-moving target. 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. Then the new way of working was a success and the people who clung to the lower layer spent their careers on something the industry had moved past. AI is just the next layer up. Insisting that everyone still know the fundamentals is what people have always said right before the abstraction makes them wrong.

Why AI is not just the next compiler

All the layers we successfully built on top of are both 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 like a good idea.

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

The compiler analogy falls flat pretty quick. We abstracted away things we could stop checking because it's became a solid, repeatable pattern. 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.

This is a daily issue, not simple one-offs

People tend to only look towards AI outages being biggest the problem, but they don't really look at the bigger problems those outages expose. Every major provider has gone down, sometimes it feels like forever. 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 the service drops before a code freeze. 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 have a hard stop." That gap is the difference between a bad day and a legit crisis.

Saying this purely is an outage risk doesn't show the severity that it really exposes. The outage is just the moment a hidden dependency becomes visible. A team that never had the fundamentals 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 didn't create a vulnerability, it just reveals the one that was there all along.

That is the real cost of trimming back on the fundamentals.

It's not cut and dry in 1 direction

The person who refuses to use AI, who insists on doing everything the slow way out of pride or distrust, is also getting it wrong. They are giving up real leverage, and they will be out-shipped by people who use the tool well. 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. Understanding both the tool and the foundations is what builds confidence.

Foundations versus interface

This is not "the old way" versus "the new way." Calling fundamentals "the old way" makes years of knowledge sound like nostalgia.

The better way to look at it is foundations versus interface. The interface, this month's tool, this quarter's model, the specific way you prompt, is always changing. What you learned about the latest AI tool eighteen months ago is probably stale by 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, move significantly slower, if at all. They were true before this tool and they will be true after it.

Learn the tools, but treat them like the ever-evolving target they are, not as a replacement for what you are using them for. 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.

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 can exponentially cost you. 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. Judgment cannot be taught like that, and it is also the thing AI cannot supply for you.

The bottom line

Don't bet everything on a system you do not own. Use it to it's fullest capacity, but keep enough of the fundamentals that when the tool is wrong, or gone, you are still an engineer.