Mastery doesn't autocomplete

Something has shifted in how engineers learn. We can summon any answer in seconds, paste any error into a model and get a working fix, ship features in languages we’ve never properly studied. It feels like leverage. But the more I lean on it, the more I notice the texture of knowledge thinning out: opinions arriving pre-formed, understanding arriving pre-chewed, the slow sediment of mastery never quite settling. The information is everywhere; the depth is nowhere.

Part of what’s happening is mechanical. A large language model is, by construction, the median of an enormous training set, the smoothed average of every blog post, Stack Overflow answer, and textbook it has ever seen. AI researchers have a name for this: epistemic homogenization. When you ask it a question, you’re not getting a person’s view. You’re getting the centroid of all views, rounded toward whatever sounds confident. That’s useful when you need a quick answer. It’s corrosive when you’re trying to develop one of your own.

The damage is sharpest where engineers most want to grow: mastery. You can ship a Rust service this afternoon by pasting compiler errors into Claude until the borrow checker stops yelling. I’ve done it. It works. But six months later, when something subtle breaks in production (a lifetime that was technically valid but conceptually wrong, an Arc<Mutex<T>> papering over a design that should never have shared state), you don’t have the model in your head to debug it. You have a vague memory of the AI’s last suggestion and a Slack thread that didn’t quite resolve.

The fix isn’t to abandon AI. The fix is to bring something to it.

I think we should turn back to books. Technical books, specifically. Not as a rejection of the tools we’ve built, but as a foundation underneath them. A book is one mind, sustained across hundreds of pages, defending a thesis it has to live with. Programming Rust. Designing Data-Intensive Applications. The Pragmatic Programmer. SICP, if you’re feeling ambitious. These aren’t reference material. They’re someone’s coherent worldview about how to think about a problem, and reading them slowly is how you absorb a way of seeing.

That’s what the model can’t give you. The model gives you answers. A book gives you a frame for evaluating answers. One trains your judgment by exposing you to a worldview you can agree or disagree with. The other trains your dependence by always meeting you where you are.

The asymmetry shows up in what sticks. The chapter on log-structured storage I read in DDIA years ago still shapes how I think about every database I touch. The AI explanation of the same topic I asked for last month, I couldn’t reconstruct it now if you paid me. One was an investment. The other was a transaction.

This is also why AI gets more powerful when you read, not less. AI is a force multiplier on whatever foundation you bring. Shallow foundation, you ship shallow code faster. Deep foundation, you ship work the model couldn’t have produced on its own. The book is what gives the multiplier something worth multiplying.

The Pragmatic Programmer’s old prescription was one technical book a month. That advice landed differently in 1999, when reading was simply the path. It lands harder now, because it’s no longer the default. Choosing to read in 2026 is choosing the slow path on purpose, which is exactly why it develops the thing the fast path can’t.

The engineer who reads isn’t the one who refuses tools. She’s the one who knows what the tools are for.