Don’t integrate AI. Rethink your organisation.

Here is a line that stops most leaders cold: you should probably be spending more on tokens than on new hires.

Not as a provocation. As a budget line.

For a decade we measured ambition in headcount. The next company will measure it in inference. That sounds absurd until you look at what the boldest teams already do: they treat compute the way they used to treat recruiting, as the thing you scale when you want more capacity, more output, more reach.

But trading people for tokens is not the interesting part. The interesting part is what it lets you build.

Hold agents to your best hire, not the busywork. Most teams benchmark their agents against the work nobody wanted: the tickets, the copy-paste. Move the bar. Measure the agent against your best hire on the dimensions where software can genuinely win: speed, availability, consistency, breadth, the patience to redo a task a hundred times without tiring. On several of those, the honest answer is already “the agent wins.” Where it is not, you know exactly what to build next. Average was never the target. Your best person is.

Run an agent per customer, not one assistant for everyone. The old instinct is a single large system that serves the whole market. The frontier looks different. Picture a dedicated agent for each customer: its own isolated environment, its own persistent memory of that account, spun up on demand and torn down when the work is done. Not one model juggling everyone, but thousands of focused instances, even tens of thousands, working in parallel every day. No human organisation can hire at that scale. A software one can. I already run whole fleets of agents in parallel on a single problem, each in its own isolated workspace. That is the real shift: you stop asking who to assign and start asking how many instances to spin up. And what you can offer, in personalization and in scale, changes completely.

Fear the timidity, not the boldness. Betting the org on agents brings real fear: of wagering wrong, of what it means for the team, of the sheer speed. Not just how fast you have to execute, but the pace of transformation the market now forces on everyone. It also brings a justified excitement at everything that suddenly becomes possible. That mix is normal. It means you are doing the work, not talking about it. But what you should really be wary of is the opposite: not going far enough, tinkering at the edges when the whole organisation needed rethinking, and bolting AI onto the safe, incremental version instead. That is what a serious, ambitious leader should be afraid of.

Train everyone, then let them ship. This is the step companies skip, and it matters most. Do not stand up a small AI team and wall it off. Teach the whole company, from the CEO to the newest frontline hire, how to build with agents. Not a lecture series. A few intense weeks that end with something real in production. When someone in operations, someone in support, and an engineer can each put a working agent into the business, you no longer have an “AI initiative.” You have an AI company.

Which leaves the only question that really counts.

Most companies are asking how to add AI to what they already have. It is the wrong question, and you can hear it in the answers: a chatbot bolted to the side, a copilot in one tool, a pilot that never leaves the lab. The better question is harder and far more useful. If you were starting this company today, from scratch, knowing what agents can now do, what would it look like?

Answer that one honestly and most of your roadmap rewrites itself.

So before you sign off on the next headcount plan, run the other version. Same goal, same budget, but agents first, humans where they are irreplaceable, tokens where they are not.

What would you build if you started today?

Prototypes are the new specs

The best sign that a prototype worked is the first thing people say when they see it: "Wait, you already built the app?"

No. I built a prototype. It exists so we can talk.

There's a reflex I keep seeing with AI coding: people believe they have to pour everything into one enormous, detailed spec so the agent can nail it in a single shot. Plan mode, spec-driven development, the perfect document up front. And in that rush, they forget something obvious. Today, instead of planning* the thing, you can just build it. You can even code a small prototype yourself.

We learned this lesson once already. It's the whole reason software teams tried to move away from waterfall and toward more iterative, incremental ways of working: you can't anticipate everything, you're not a fortune-teller, and you can't write the spec for an application from scratch without studying how users actually work and talking with them at length. Even the users can't describe everything they need in a single pass.

I am using the words iterative and incremental deliberately. Some process terms now carry too much baggage for many people, often for good reasons. The philosophy still matters. Build something, learn from it, improve it, and keep moving.

Of course, for a small task, one-shotting works fine. But you can't design a complete application in one go, not with humans and not with agents, because we struggle to describe what we want, and the agent struggles to understand what we're asking.

So prototype instead. And not only the front-end or the UI, but the features, the flows, the back-end, the data. Because to give real feedback, you have to see the thing. To follow a process, understand it, and improve it, you need to watch it run on real data. And for an interface, you need to see it and click through it, to find out whether the agent actually understood what you meant. A document can't give you that. A running prototype can.

My loop is simple and fast:

- Build a functional prototype, quickly. Minutes to a few hours. A day for something real. A few days, never more than a week, for something genuinely complex.
- Make it realistic enough to trigger real feedback, but deliberately incomplete. You advance one feature, one screen, one workflow at a time.
- Show it to users early, and let them react. The feedback is far more useful than any spec review, because people respond to something they can feel. I also record the meeting with a tool like Granola or CircleBack, so I can stay fully focused on the exchange instead of slowing it down by taking notes that are never quite complete.
- When the workflow is complex, compare several approaches. Build three or four versions of the interface, then feed the prototype with a realistic synthetic dataset. That is what lets the user step into the situation, compare options, and project forward.

Two reactions come back almost every time. At the start: "You built the app?"* No, it's a prototype, it's here so we can talk. And at the end of the meeting: "Great, so I can start using it?" Not yet. This let us align. Now I'll fold in everything you just told me. But very soon, in two, five, or ten days depending on the complexity, you'll have the real application.

That leaves the most important point, the one most people get wrong: what happens to the prototype next?

**The prototype is throwaway.** Its job is to answer questions and reduce risk, but also to sharpen the need, test the PM's hypotheses, and create a concrete support for ideation. It helps validate whether the PM's understanding and intuition converge with the user's reality. Faced with something concrete, the user's critical thinking wakes up. They see what works, what feels wrong, and what they actually need.

It is not, however, your production codebase. Shipping the prototype as production is how you inherit accidental technical choices that every future agent then faithfully reproduces. So once it has done its job, I don't "productionize" it. I use it as the reference to build a first alpha that is clean, robust, fully tested, and reviewed end to end: code I've actually read, that sets the patterns, the tone, the spirit of the project. That alpha is the healthy foundation everything else is built on. The prototype is there to understand, compare, and decide. The alpha is built to last and to run in production.

The right sequence is not spec, then production. It is prototype, learning, clean alpha. The prototype lets you understand the need, test the assumptions, compare interface options, and watch real behaviour run on realistic data. The alpha turns those answers into a solid technical base.

So before polishing another spec, build something your users can click through, criticize, and correct. Then build the real application properly, so it lasts.

So here's my question: when did a prototype last tell you something a spec never could?