The four books that changed how I think about AI applied to professional work

I have a complicated relationship with reading lists. Most of them seem to be assembled the way Spotify assembles a playlist — algorithmically plausible, mostly the books everyone already mentions, occasionally one curveball thrown in to seem interesting.

This is not that. These are four books I have actually returned to over the last year. Each because it gave me a frame for a problem I was working on at the time. None of them is "about AI" in the sense that they'd appear in the AI section of a bookstore. Three of them were written before the current generative AI moment. One is much newer. All four have shaped how I think about the work I do at the intersection of regulated practice, software, and AI tools.

Listed in the order I'd recommend reading them.

1. Antifragile by Nassim Nicholas Taleb

Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb

I came back to this book three times last year and recommend it more often than any other on this list.

Taleb's central argument is that systems fall into three categories: fragile (broken by stress), robust (unchanged by stress), and antifragile (improved by stress). The argument is more interesting than it sounds, because once you have the vocabulary, you start seeing it everywhere — and you start noticing that we've spent the last twenty years building systems that present as robust and are actually fragile.

For regulated work specifically, the book is invaluable. Compliance systems are typically designed for the expected case and break catastrophically on the edge cases that real practice runs into every week. A good compliance officer is intuitively a Taleb reader. They overweight tail risk because the tail risk is what gets you sued. The book gives that intuition a vocabulary.

The application to AI tooling is direct: most AI tools are fragile in Taleb's sense. They look impressive in clean conditions and break in messy ones. The frame for evaluating them changes if you stop asking "how well does this perform on average?" and start asking "what is its behavior at the edges?"

Skip the parts where Taleb argues with other writers. Read the rest.

2. Designing Machine Learning Systems by Chip Huyen

Designing Machine Learning Systems: An Iterative Process for Production-Ready Applications by Chip Huyen

If you build, buy, or oversee anyone who builds ML systems, this is the closest thing to required reading I have on this list.

Huyen's book is the most honest treatment I've found of what production ML systems look like and how they fail. It isn't a "here's how transformers work" book — there are 200 of those — it's a "here's what it actually takes to run an ML system in production for two years without it slowly getting worse" book. There are not many of those.

The book is structured around the lifecycle: data, modeling, evaluation, deployment, monitoring, feedback loops. The most valuable chapters, in my reading, are the ones on data quality, on evaluation under data drift, and on the operational realities of model monitoring. These are the chapters where the gap between vendor demos and production reality is widest, and Huyen is rigorous about closing it.

What you get from this book, if you read it carefully, is the ability to ask the right second question. The first question — "does this model work?" — has a simple answer in any demo. The right second question — "does this model continue to work when the data changes, when the user behavior changes, when the upstream pipeline changes, when the team that built it leaves?" — is rarely asked. After this book, you ask it.

3. The Alignment Problem by Brian Christian

The Alignment Problem: Machine Learning and Human Values by Brian Christian

The most accessible book I know on why ML systems behave badly when no one explicitly tells them to behave badly.

Christian is a science writer in the best sense — he goes deep without losing the reader. The book walks through three increasingly intricate kinds of alignment failure: systems that learn the wrong proxy, systems that learn a correct proxy that becomes incorrect when deployed elsewhere, and systems that game the proxy in ways their designers didn't anticipate.

For anyone working in regulated industries, the relevance is sharper than it might appear. The legal system spends a lot of its time on alignment problems. A regulation is a proxy for a behavior; the regulated entity finds ways to comply with the proxy without complying with the intent; the regulator writes a new regulation. The dynamic is mathematically identical to the alignment failures Christian describes in ML.

After this book, you have a better intuition for why a chatbot trained to "be helpful" can give you a confidently wrong compliance answer, why a recommendation system optimized for engagement can produce content the platform didn't intend, and — closer to my own work — why a compliance AI optimized for "summarize the rule" can produce summaries that miss the part that matters. The alignment is local; the misalignment is contextual.

4. The Pragmatic Programmer by David Thomas and Andrew Hunt

The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition by David Thomas and Andrew Hunt

Twenty years old, ostensibly about software engineering, and still the best book I have read about the discipline of building things that work.

I picked it up two summers ago, when I started building real production systems for the first time. I expected to find a lot of outdated specifics — old languages, old frameworks, old tools. There are some. There is also an enormous amount of timeless craft. The chapters on tracer bullets, on "good enough" software, on knowing when to refactor, on the brittleness of premature abstraction — these aged better than I expected and apply directly to AI work in 2026 in ways the original authors couldn't have anticipated.

A particularly relevant section, given the moment we're in: Thomas and Hunt are unsparing about the dangers of relying on tools you don't understand. They're not anti-tool — they explicitly recommend learning shortcuts and automating drudgery — but they draw a clear line between using a tool and being captured by it. The application to AI-assisted development is direct. Use the tools. Don't outsource the understanding.

If you build software at all, even occasionally, this book repays its reading time many times over. If you don't build software but you supervise people who do, it gives you the vocabulary to have better conversations with them.

How I'd suggest reading these

If you're new to thinking about AI in professional contexts and have time for one: read The Alignment Problem. It gives you the conceptual frame everything else depends on.

If you build or buy AI tools: read Designing Machine Learning Systems. It will save you from at least one expensive vendor selection.

If you work in regulated industries: read Antifragile. The vocabulary alone is worth the price; the framework will change how you evaluate every system you touch.

If you write any software at all, ever, even occasionally: read The Pragmatic Programmer. Then re-read it after every major project. It says different things on a second read.