AI Didn't Make Expertise Optional. It Made It More Valuable

There’s a narrative going around that AI makes expertise optional. That you don’t need to understand the fundamentals anymore because the AI understands them for you. That depth of knowledge is a relic of a time when you had to do everything yourself.

This narrative is backwards.

AI doesn’t replace expertise. It amplifies whatever you already have. If you have deep understanding of what you’re building, AI makes you dramatically more productive. If you have shallow understanding, AI makes you faster at producing things you can’t evaluate. That’s a polite way of saying you’re building problems faster.

The Amplifier

Think about what AI coding tools actually do. They generate code based on your instructions, suggest approaches based on your context, and debug based on the information you provide.

In every case, the quality of the output depends on the quality of the input. And the quality of the input depends on your understanding of the problem.

If you deeply understand the domain, you give better context, ask sharper questions, and spot when the AI’s suggestion is wrong even when it looks correct to someone with less experience. You know which trade-offs matter and which don’t.

If you don’t understand the domain, you can’t do any of that. You accept code that looks right, miss trade-offs you don’t know exist, and build features that work in the narrow test case but break in production.

The AI didn’t cause this gap. It made it wider.

Speed Without Understanding

Here’s a pattern I’ve seen play out more times than I can count.

Someone picks up an AI coding tool and is amazed at how fast they can produce code. Features that used to take days now take hours. They ship more, move faster, feel productive, and everything seems great.

Then something breaks. Not a simple bug. A structural problem. The code works but it’s built wrong. The database schema doesn’t support the query patterns the application needs. The authentication system has a subtle flaw that isn’t exposed by any of the test cases.

Fixing these problems requires understanding why the code was built the way it was. And if you didn’t understand it when it was written, because you accepted the AI’s output without deeply evaluating it, you’re in trouble. You can’t fix what you don’t understand.

This is the trap of speed without understanding: the code comes fast and the consequences come later.

What Fundamentals Actually Mean Now

When I say fundamentals matter, I don’t mean memorizing syntax or implementing data structures from scratch. Those are the parts AI handles well. Memorization is cheap now.

The fundamentals that matter are the ones that help you think about problems correctly.

Understanding systems. How different parts of a software system interact, what happens when you change one piece, and where the failure modes are. A model can write a function that’s correct in isolation. Whether that function works when it’s called by three different services under load is a different question, and one only you can answer.

Understanding trade-offs. Every technical decision involves trade-offs. Speed versus complexity. Flexibility versus simplicity. These trade-offs don’t go away because AI is writing the code. If anything, they become more important because the code is being produced faster, which means the consequences of bad decisions arrive sooner.

Understanding the problem domain. The AI doesn’t know your users, your business constraints, or the history of your codebase and why things are the way they are. All of that context lives in your head, and it determines whether the code AI produces is solving the right problem.

Understanding what “good” looks like. You need a standard to evaluate against. If you don’t have a clear picture of “good,” you can’t tell whether the AI’s output meets the bar. You’ll accept whatever it gives you. And “whatever it gives you” is not a quality standard.

The Compounding Effect

This is what makes it urgent, not just important.

The advantage of depth compounds. If you understand systems deeply and you use AI well, you make better decisions faster, catch problems earlier, and build on solid foundations.

If you lack depth, the problems compound too. Each piece of code you ship without understanding, each architectural decision you accept without evaluating, these accumulate. The codebase gets harder to maintain and the bugs get harder to fix.

Over time, the gap between these two paths widens, even though the tools are the same.

The Path Forward

The antidote is simple: understand what you ship. This doesn’t mean writing every line by hand. It means that when AI generates code, you review it with the same rigor you’d review code from a colleague. You understand the approach, the trade-offs, and the implications. If you can’t explain the code to someone else, you don’t understand it well enough to ship it.

Build things that push you into unfamiliar territory. Use AI to build faster, but pay attention to what it produces. When the AI generates a solution, don’t just check that it works. Understand why it works and whether there were better alternatives. This turns every AI interaction into a learning opportunity.

AI frees you from the mechanical parts of coding. That gives you more time and attention for the parts that require taste, judgment, and care. But only if you choose to invest that time in depth instead of just shipping more.

The craft still matters. What’s changed is that you have more room for it.

---

This post is adapted from Get Insanely Good at AI, which covers the full picture: how AI works, how to use it well, and why expertise is your biggest advantage.