Introduction: The Work Moved

This book began as a series of public notes and essays, written while I was trying to understand what changed when AI stopped being a distant technology trend and became part of the way I actually work. I was not writing from a lab, a forecast deck, or a tidy theory of the future. I was writing from inside the work itself: building small tools, testing coding agents, helping product ideas become prototypes, watching teams struggle with adoption, and noticing where speed created new responsibilities instead of removing old ones.

The central lesson is simple: AI does not make judgment less important. It moves more of the work toward judgment.

When a model can draft the first version, generate the first interface, summarize the first body of evidence, or produce the first working prototype, the bottleneck changes. The hard part is no longer getting something to exist. The hard part is knowing whether the thing that now exists is worth trusting, improving, shipping, or killing. That shift sounds small until you feel it in the day-to-day rhythm of product work. The visible artifact arrives faster, but the responsibility around it gets larger.

That is why so many of these chapters return to building. Building is not only an engineering activity. It is a way to learn what the tool can and cannot do. It reveals the difference between impressive output and useful output. It exposes where context matters, where the model fabricates confidence, where the workflow breaks, where the human needs to slow down, and where the team needs a better operating loop. You do not learn that by reading feature announcements. You learn it by trying to move a real piece of work through the system.

The early chapters are deliberately practical because the early lessons were practical. What happens when a product manager can move from PRD to prototype? What happens when a coding agent can generate software, but still needs stronger taste, better tests, and clearer direction? What happens when the user intent behind the work becomes as important as the source code that resulted from it? These are not abstract questions. They show up the moment an AI-assisted builder has to decide whether a generated artifact actually expresses the original intent.

The same pattern appears in discovery and search. Search is no longer only a box that matches keywords to documents or titles. Increasingly, it is a conversation with context, constraints, uncertainty, and judgment inside it. As agents begin to explore, compare, and act on our behalf, product teams will need to design for intent rather than only interaction. That creates new opportunities, but also new failure modes. A discovery system that speaks with confidence needs evaluation beyond accuracy. It needs taste, trust, truth, and product accountability.

AI adoption inside teams has a similar trap. Access to tools is not the same as changed work. A company can have demos, pilot groups, prompt libraries, and a flood of enthusiasm while the actual operating model remains unchanged. The adoption only becomes real when a recurring workflow is redesigned: when the team defines the intent more clearly, gives the model better source material, makes uncertainty visible, verifies the output, and keeps a human accountable for the decision. The goal is not to sprinkle AI on top of the old process. The goal is to create a better loop.

That is why I keep coming back to the 20/70/10 shape of the work. AI may help create the first 70 percent faster than before, but the human still needs to frame the work before it begins and own the final 10 percent where judgment, quality, and trust live. In many cases, that final 10 percent becomes more important, not less, because the artifact can look polished before it is actually right.

There is also a leadership lesson running through these pieces. The most useful question is not "How can we do the same work with fewer people?" It is "How much better can we make the work with the same people?" If AI gives a team more cycles, the best use of those cycles is not only output. It is more exploration, better evidence, faster learning, sharper review, and more room for human judgment where it matters.

This book is a snapshot through June 8, 2026. The tools will keep changing. Some product names, limits, and workflows described here will age quickly. That is fine. The deeper pattern is more durable: frontier tools reward people and teams who can turn intent into artifacts, inspect the evidence, design better loops, and stay accountable for the outcome.

The work moved. These are the lessons I learned while trying to move with it.