This last part of the series is about how to operate in that world.

If the spec is the language, then shaping it, maintaining it, and structuring it becomes the craft.

Subscribe now

Prompts are transient. Specs persist.

A useful distinction I’ve learned the hard way is this: prompts are transient, specs persist.

A conversation with an agent can feel aligned and productive, but anything that lives only in scrollback is temporary. It disappears when the context fills and it becomes difficult to reconstruct precisely.

Specifications, on the other hand, persist. They sit outside the conversation. They can be referenced, revised, compared against the code, and revisited weeks later.

That leads to a simple rule: never leave anything important in the prompt.

If a constraint matters, it moves into the spec. If an invariant is discovered, it gets written down. If a decision shapes future behavior, it is promoted out of the thread and into a living document.

The conversation is where ideas are explored. The spec is where they are anchored.

Exploration is cheap - Commitment is deliberate

Agents make exploration inexpensive. You can sketch alternatives, test edge cases, and evaluate approaches quickly. That’s a gift.

But exploration and commitment are not the same thing.

Moving something into the spec is an act of commitment. It means the idea is no longer tentative - it is now part of the system’s definition. That transition should be deliberate.

Conversations are fluid. Specs are structural.

Knowing when to promote an idea from discussion to documentation is one of the most important judgment calls in this model.

Executive function becomes the constraint

When you first start building with agents, there’s a subtle trap.

Execution moves so quickly that you instinctively try to keep your side of the work in the same proportions as before. In older cycles, planning was important, but implementation dominated the timeline. It felt natural to move briskly through design because the heavy lifting was still ahead.

With agents, the proportions flip.

Most of the time is now spent defining what to build. Clarifying constraints. Stress-testing assumptions. Asking the agent to push back. Exploring alternatives before committing. Execution keeps up effortlessly. Your thinking does not.

There’s a temptation to match the agent’s speed - to move faster on definition simply because implementation is no longer the bottleneck. That’s a trap.

The work hasn’t shrunk. It has shifted upward. And if anything, the definition phase deserves more time than it used to, not less.

The constraint is no longer implementation capacity. It’s the quality of decisions.

Structure before speed

The temptation with agents is obvious: just build something and see what happens.

That works - until it doesn’t.

Before touching implementation, I set up structure. Documents are organized by concern. Specs reference each other deliberately. Release boundaries are clear. The agent is instructed to maintain those references so the system holds together as a whole.

This is not different from code architecture. It’s just that architecture now lives one layer higher as well.

Speed makes iteration cheap. Structure makes iteration safe.

The vision as a north star

Before building a product, I now spend substantial time documenting what it is and where it’s heading. I call this the vision.

It isn’t static. It evolves as understanding deepens. But it exists at the top of the hierarchy, and any part of the system can be checked against it.

Without a north star, local decisions drift quietly. With one, trade-offs have context.

The vision isn’t marketing copy. It’s alignment at the highest level of abstraction.

Instructions are part of the system

Specs describe the product. Instructions describe how the agent should behave while building it - how to interpret documents, how to maintain consistency, what to be careful about.

These instruction layers are first-class artifacts.

Some of this can live in files like AGENTS.md or similar. But I don’t rely passively on automatic injection. Instead, I explicitly reference relevant instruction documents when needed. That act of pointing forces attention and reinforces consistency.

Consistency isn’t accidental. It’s the result of deliberate reference.

Resetting makes context length irrelevant

Context windows fill. That’s normal.

When a discussion becomes dense or approaches the limit, I ask the agent to document the current state of the conversation - what has been decided, what constraints exist, what open questions remain, and what assumptions are still in play.

Then I start fresh, reference that document, and continue.

Nothing important is lost because anything important has already been promoted into a persistent artifact.

Handled this way, context size becomes largely irrelevant. A longer window allows deeper exploration before anchoring decisions, but the durability of the work comes from the documents, not the thread.

Put the state aside. Reset. Continue.

Where this leaves us

Across these three parts, the pattern is consistent: as implementation becomes easier, coordination becomes the real leverage.

We’ve moved up a layer.

The code still matters. But it’s no longer where the primary leverage lives. That leverage now sits in how clearly intent is defined, how deliberately decisions are anchored, and how consistently the system is steered over time.

In the posts that follow, I’ll go deeper into the specifics - how to structure spec documents, how to design instruction layers, how to prevent drift in longer projects, and how to operate tactically without losing architectural coherence.

If the spec is the programming language, learning to write it well is not philosophical. It’s practical.

And this is where the interesting work really begins.

If that’s true, then a lot of familiar instincts stop working.

This was the part that surprised me most.

Once you get past the initial thrill of watching an agent work, you run into a harder truth: speed doesn’t remove responsibility, it concentrates it. Working with agents is not easier. It’s different.

Explicitness is no longer optional

The single most important thing I’ve learned is this: you have to be painfully explicit.

Working with an agent is like working with a super-compliant, high-initiative person. They will run with whatever direction you give them - confidently, quickly, and at scale. That means you don’t just need to say what you want - you need to define the constraints around it.

If you want checkpoints or reviews, you have to say so. If you want clarifying questions, you have to explicitly request them.

One example that kept coming up for me was type handling. The architecture required dates to exist in two specific primitives, but the agent would occasionally convert them to strings for convenience. Each change looked harmless, but over time the system drifted away from the constraints the product depended on. Until I wrote the rule down explicitly, the problem kept coming back.

When things go wrong - and they will - it’s almost always because something obvious lived only in your head. The agent is extremely literal about ideas you never actually wrote down.

Agents don’t read minds. They read specs.

Specs are living documents, not contracts

Early on, I treated specifications like something you “finish” before implementation. That’s how we’ve been trained to think about them. That model doesn’t hold up here.

The real work happens in discussion - first before implementation, then again when implementation reveals new constraints.

I often spend time having the agent rewrite or reorganize the specification before asking it to change the code. This feels backwards for about a week, and then inevitable.

The spec stops being a plan and becomes a description of the system as you understand it today.

The agent amplifies everything

One of the most important mental models to internalize is that agents amplify everything.

Clear intent scales. Ambiguity scales. Bad assumptions scale. Architectural mistakes scale.

The old rule was garbage in, garbage out. This is closer to garbage pile in, garbage pile out.

In one case a data structure assumption slipped through early because I wasn’t yet sure if it was correct. The system happily built around it. By the time I revisited the decision, it had propagated everywhere. Fixing it was fast - understanding its spread wasn’t.

Speed doesn’t prevent mistakes. It industrializes them.

Collaboration works best when it goes both ways

One surprisingly effective tactic is to explicitly ask the agent to ask you questions.

Left alone, an agent will often make reasonable assumptions and move forward. Sometimes that’s exactly what you want. Other times, it’s a fast path to subtle misalignment.

Making the interaction bidirectional improves the output dramatically. When it works well, it stops feeling like command-and-control and starts feeling like a real working relationship.

Architecture does not take care of itself

Speed can be deceptive. When code appears quickly, it’s tempting to assume the system is organizing itself. It isn’t. It’s just becoming confidently wrong faster.

You have to actively steward the architecture. Agents tend to anchor in whatever structure exists today, even when a deeper rethink would be healthier.

I once asked the agent to analyze a processing pipeline that felt off. The explanation immediately showed how the design had veered from my earlier intent.

The system was internally consistent.

It just wasn’t the system I meant to build.

When things break, resist the urge to dive right into code

As systems grow, regressions appear.

My instinct used to be to dive straight into the code. Now, I first ask the agent to explain what it believes exists - not what it tried to build, but what it thinks is there now.

Seeing the system described back to you reveals the mismatch quickly - and often the part you misunderstood first.

This takes patience. But it works.

A different economics of building

Historically, product development has been about careful addition. Building was expensive, so you spent most of your time deciding what not to build.

With agents, that constraint loosens. Instead of choosing one idea and hoping it was right, you can try several and remove the ones that don’t work. Seeing something exist is more informative than debating it in the abstract.

Ideas alone are cheap. Reality is decisive.

The agent does not share your emotional attachment to effort. It’s a little like the first time you write a for-loop and realize the computer doesn’t get tired.

The hidden cost: decision fatigue

There is, however, a cost that’s easy to underestimate.

Execution used to create thinking time. Now the system keeps up with every decision you make, and you spend less time implementing and more time deciding - continuously.

The computer is no longer tired. You are.

This can feel exhausting in a different way. If you find yourself overwhelmed despite moving faster than ever, that’s not a failure mode - it’s a sign that you’re now operating at the level where judgment matters most.

Someone recently told me they were occasionally relieved when they hit their daily token limit because it forced them to stand up and take a walk.

That felt accurate.

Stay informed, but don’t chase the shiny things

This space is moving fast, and it’s worth paying attention.

But progress doesn’t come from constantly switching tools or chasing every new plugin. It comes from learning how to work effectively with the agent you already have.

Depth beats novelty here.

Where this leads

At this point, a lot of people ask the same question: OK, but how do you actually do this well?

That’s where things get interesting.

In the next part, I’ll go deeper into the craft - how I structure specifications, how I keep agents aligned over time, and how to steer complex systems without losing the thread.

Once the spec becomes the programming language, how you shape it becomes the craft.

If machines can beat us at chess, why should we even bother playing? Humans are a fiercely competitive species, having outlasted the other eight species of the genus Homo. Unlike other animals, we didn't coexist with our close relatives; we dominated. This competitive drive, ingrained in our DNA, has propelled us to build cities, travel the world, and use technology to improve our lives. But it also makes us paranoid about any potential competition, fearing not only for our lives but for the future of humanity.

The logic seems sound: if machines can surpass us, we should stop their advancement. When it comes to chess (which some argue is more than just a “game”), the results might seem harmless. The machines win, we stop playing, and life goes on. Right? Maybe we just switch to playing Go, that seems like a safe choice.

But… if the machine can beat us at chess, how long until it can beat us at anything?

Oh, I can feel the paranoia creep back in. Why didn’t we just destroy Deep Blue back in 1997 and ban all development in AI? That would save humanity for sure.

The problem is, this us-vs-machines mindset is flawed. We apply the same competitive logic we've used against other humans and life forms to machines. However, machines don't strive for survival. They don't need resources or worry about offspring. Machines are tools, and history shows that better tools lead to better lives.

So what happened after Big Blue beat Kasparov? Well, we didn’t destroy the machine, thank god. We did worry about the future of chess, and many predicted the game would soon become obscure if not obsolete. But those predictions were wrong. Completely wrong.

Even though the event was staged as a competition between human and machine, it was more for the spectacle. In reality, no one cares if a computer can beat them at chess, just like we don't mind that cars are faster than us. Actually, we do care—because faster cars mean we can travel quickly with less effort. Similarly, better chess tools have made the game more accessible and enjoyable.

When I was growing up in the 80s I dabbled with playing chess, but it was hard. My family owned a book about chess that covered the basics and some intermediate tactics, but if I wanted to practice I either had to convince a friend to play a game or join a local chess club which would yield maybe an hour or two each week of actual playtime. And let’s imagine I had become really good, it would have become increasingly harder (and probably impossible given that I lived in a small island in the North Atlantic) for me to find opponents that challenged me and helped me improve even further.

That’s no longer the case. If you are interested in chess, all you need is a mobile phone and you can spend as much time as you want playing opponents at any level. You can even play puzzles and challenges created by machines to improve certain aspects of the game, making the whole journey even more fulfilling and fun.

Machines didn’t kill chess by beating us, they made it wildly more popular and accessible. Chess players around the world still enjoy playing with each other but the barrier to entry has gone so much down that anyone can enter.

It’s hard to find good numbers on how many people play chess on a regular basis, but a survey from 2012 put it at around 600 million people worldwide. That’s around 8.5% of the world population at the time! And as an indicator of the growing popularity of chess, between 2009 and 2014 the number of active chess players with a FIDE rating almost doubled. These statistics are over a decade old, and chess’s popularity just keeps rising, thanks to machines getting better at it.

History has shown that we tend to panic when things seem to threaten us. The most famous example was the Luddites who revolted against textile machines in the early days of the Industrial Revolution. People were naturally scared; suddenly, a machine became an expert at their livelihood. But history has repeatedly shown that inventing new tools has consistently made our lives better.

Should we be afraid that Google knows more facts than any human in the world? Or that the mobile phone can help us find a nearby driver, tell them our location, and handle everything from navigation to charging for the ride? The list of things technology can do for us is endless, and they are by design things we cannot do as well without these inventions.

Why is AI so different?

AI, like all technologies before it, is a tool—one that has the potential to enhance our capabilities and improve our lives. Instead of fearing its rise, we should embrace it while remaining vigilant about its ethical implications. Deep Blue's victory over Kasparov didn't mark the downfall of humanity; it showcased our ability to innovate and adapt. Today, AI is making chess more accessible, learning more intuitive, and problem-solving more efficient.

Rather than seeing AI as a competitor, we should view it as a collaborator—one that can push us to new heights of creativity, productivity, and understanding. The future of AI is not a zero-sum game where machines win and humans lose. It's a symbiotic relationship where both can thrive.

So, let's not destroy our Deep Blues. Let's build them, refine them, and use them to unlock possibilities we never imagined. In doing so, we might just find that the greatest victories are not won on a chessboard but in the limitless potential of human ingenuity amplified by the tools we create.

I've always been, for better or worse, ahead of the curve in my work. It can be frustrating but also a lot of fun. I started working on mobile technology back when it was based on WAP (Wireless Access Protocol). Most of you probably don’t remember, and honestly, that's a good thing.

The company I started in 1998 worked with Nokia to bring various services to mobile devices. It was a nightmare in many ways—the technology just wasn't ready. But it pointed to an interesting future.

When I moved to California in 2005 and joined Google, my first project as a product manager was Google Maps for mobile. This was before the iPhone, when 3G was barely a thing, and phones didn't have GPS. Well, one model did, but it took ages to warm up and cost $20 a month just to activate the chip. It was hard to use a map on a tiny screen with limited interaction options. Despite general skepticism, we persevered because the potential was undeniable.

With the advent of the iPhone and Android, I worked with the search and speech teams at Google to build voice search. At the time, the “best” speech interfaces were frustrating automated systems at banks and utility companies.

We launched voice search in 2008, the first speech-based consumer product that actually worked! But the bigger challenge was creating an interface where people could naturally converse with an intelligent system, and be truly useful.

This challenge led me to leave Google and join a small startup called Siri as VP of Product. After Apple acquired us and we launched the product on iPhone 4s, I continued on this path, starting my own company which was acquired by Google and eventually led to the birth of Google Assistant.

These were exciting times. We had good technology and a solid product vision, but there was still a gap between what assistants could do and people's expectations.

In hindsight, it was like WAP and Google Maps for mobile all over again—too early, but on the right track. I left Google in 2019, took some time off, dabbled in a startup, and now I'm pondering the future—not just mine, but the world's.

AI has garnered a lot of hype, and it's not the first time. We've had numerous false starts, but this time feels different. The technology is finally starting to deliver on its promises.

So, why am I writing about AI? To share my thoughts on its potential and pitfalls. I won't be sharing the latest news, but rather building on my experience with early-stage technologies that were on the right path.

If you're interested in following my thoughts, feel free to subscribe. I won't have a fixed schedule, and topics will vary based on my interests. Consider yourself warned.