Learn the fundamentals now, while everyone else stops

There is a quiet assumption spreading through our industry: that fundamentals are now optional. The model knows how databases work, so why should I? The model can design the system, so why read the book about it? If the AI holds the knowledge, learning it yourself starts to feel like memorizing phone numbers in the age of the smartphone. Quaint. A waste of time.

I think this is one of the most expensive mistakes an engineer can make right now. Not because the old advice "always be learning" is a nice thing to say. Because the economics of knowledge just flipped, and most people are reading the flip backwards.

The model raises the floor and the ceiling at the same time

Here is what actually happened. AI made it trivial to produce a plausible answer to almost any technical question. Plausible is the key word. The floor went up: a junior can now generate a working CRUD service, a passable schema, a deployment script. That is real, and it is good.

But the ceiling went up too, and almost nobody is talking about that part.

When everyone can generate a plausible system, the bottleneck moves. It moves from "can you build it" to "can you tell whether what got built is any good." That second question is not easier in the AI era. It is harder, because now you are reviewing decisions you did not make, in volume, faster than before. The person who can look at a generated design and say "this will fall over the moment we have concurrent writes" is worth more than they have ever been. The person who can only say "it ran" is worth less.

The fundamentals did not become optional. They became the thing that separates the two.

You cannot steer what you do not understand

The whole promise of AI as a tool is that you direct it. You are the one with intent, the model is the one with throughput. But direction requires a destination, and a destination requires knowing the terrain.

Ask a model to design a system and it will give you something. Ask it to design a system when you understand consistency models, partitioning, the real cost of a join, what a queue does to your failure modes, what an index actually is underneath, and the conversation changes completely. Now you are not accepting output. You are pushing back. "Why a relational store here and not an append-only log." "This caching layer hides a correctness bug, walk me through invalidation." "We will outgrow this partitioning key in a year, show me the alternative."

That is what steering looks like. It is not prompting harder. It is knowing enough to interrogate the answer. The engineer who skipped the fundamentals can only ask the model to try again, and hope the next version is better. The engineer who learned them can tell the model exactly what is wrong and why. One of these people is in control. The other is gambling.

How do you even know if a design is good

This is the question underneath all of it, and it is the one AI cannot answer for you, because answering it is the job.

A design is good or bad relative to constraints. How much data, growing how fast. How many reads versus writes. What happens when this dependency is down. What you are willing to lose in a crash and what you are not. Latency budget. Team size. The cost of being wrong. A model does not know your constraints unless you know them well enough to state them, and even then it will happily hand you something that looks clean and fails under exactly the load you forgot to mention.

You develop the taste to judge a design the old way: by understanding the trade-offs deeply enough that the failure modes are visible to you before they happen. There is no shortcut to that, and there has never been a better time to build it, because the cost of producing systems to study has gone to zero. You can generate ten designs in an afternoon now. The constraint was never producing them. It was being able to tell which one is right.

Read the hard books, on purpose

So here is the concrete version, because I do not like advice that stays abstract.

Read Designing Data-Intensive Applications by Martin Kleppmann. Slowly. It is the single best book I know for building the mental model of how real systems store, move, and reason about data. Replication, partitioning, consistency, the actual guarantees behind the words people throw around. After it, "eventually consistent" stops being a phrase and becomes a thing you can reason about.

Read about system design properly, not as interview trivia but as the discipline of making trade-offs under constraints. Whatever resource you use, the goal is the same: to stop seeing a system as a diagram and start seeing it as a set of decisions, each with a cost.

These are not the fun, fast wins. They are slow, and they will not make next week's sprint faster. That is precisely why they are worth it. Everyone is optimizing for the fast win the model can hand them. The slow, compounding knowledge is getting abandoned by the crowd at the exact moment it became the differentiator. When everyone zigs toward speed, the durable edge is in the thing they stopped doing.

Learn the concepts, let the model handle the keystrokes

I want to be clear that this is not a back-to-basics, suffer-for-its-own-sake argument. I use AI every day. I am not asking you to hand-write a B-tree to prove your worth.

The split I have settled on is this: let the model own the mechanical, own the concepts yourself. I am happy to let AI generate the migration, write the boilerplate, scaffold the service. I am not willing to let it own my understanding of why the migration is safe, what the boilerplate is hiding, or whether the service will hold. The keystrokes are cheap now. The concepts are the entire value I bring.

And the concepts are durable in a way that frameworks never were. The JavaScript library you learned in 2018 is gone. How a distributed system behaves under partition is the same as it was twenty years ago and will be the same in twenty more. Time spent learning the syntax of the month was always going to depreciate. Time spent learning how systems actually work compounds for your whole career. AI did not change that. It just made the cheap knowledge cheaper and the deep knowledge rarer.

Where this leaves you

The engineers who win the next decade are not the ones who learned to prompt the fastest. They are the ones who kept learning the hard things while the tools made it feel unnecessary.

Intelligence on tap is here. It will write your code, draft your designs, and sound confident doing it. The only way to use that well is to be the person in the room who actually understands what is being proposed, who can tell good from plausible, who can steer.

That person is built by reading, slowly, the things everyone else is deciding to skip. Now is not the time to learn less. It is the best time there has ever been to learn more.