Building got cheap. Judgement is the bottleneck now.

Building got cheap. That’s the whole story of the last two years. Work that used to take a squad a quarter now takes people a weekend, and the cost of trying something has fallen far enough that trying isn’t the expensive part anymore.

So the bottleneck moved. It isn’t capacity. It’s judgement. When anyone can produce a working screen in an afternoon, the scarce skill is knowing which screen is worth producing, and being willing to bin the four that aren’t.

The second scarce skill is holding quality while moving at that speed. Fast exposes weak taste. A team that ships ten times more will ship ten times more mediocrity unless somebody sets the bar and keeps it there in public, on real work, where people can see the difference.

The third is the one I care most about now. Individual capability is nice. Team capability compounds. An hour spent making my own workflow faster is worth less than an hour spent making the same thing repeatable for twenty other people.

The same loop, every time

Whether it’s a weekend build or a client engagement, I run the same sequence. AI runs through all of it rather than being bolted on at the build step. It isn’t a mood. It’s a sequence, and I can teach it.

Research goes in first, all of it at once: user research, analytics, support tickets, industry reporting. Claude synthesises across sources faster than I can read them, and then I argue with what it found until the pattern holds up. Two or three core problems come out of that, written as problem statements rather than features. If I can’t say who’s stuck and what it costs them, it isn’t a problem yet.

Each statement gets scored on business impact, customer impact and technical cost. Claude makes the case both ways and I make the call. The score isn’t the decision, it’s what makes the decision arguable. Then a PRD for the top three: problem, users, scope, out of scope, success measures, edge cases. Everything downstream runs on that document, so it’s the one I spend real time on.

Only then does anything get generated. The repo gets its context first, divergence happens against the brief as working screens rather than pictures of screens, the build runs to the PRD rather than to a chat prompt, and a separate agent reviews it against the principles file before I do. It catches the drift I stop seeing after the fourth hour. Then it ships small and early to real users, instrumented from day one.

Research, divergence and build are where the model does the work. Framing the problem, scoring it and writing the context are where I do. Getting that split wrong is how a team ships confident nonsense at speed.

Prompts are disposable. Context is the asset.

This is the part a team can actually share. Every build starts from the same set of files sitting in the repo: brand and voice, design principles, the design system mapped to real components, business rules, the project brief, and instructions for how the agent behaves in that repo.

Writing these is the slow part, and it’s the part that pays. The first build takes longer. Every build after it starts from a model that already knows the brand, the rules and the system, which is why the second one is fast and the tenth one is consistent.

The failure mode is real and I’ve hit it. Files go stale, the model keeps building confidently against last quarter’s rules, and nobody notices until review. So each file has an owner and gets checked at the same gate as the code.

How a tool earns a place

A tool list on its own says nothing. What matters is knowing the edge of each one, so I put every tool through the same four steps.

One sentence on the job to be done and who’s currently doing it the slow way. If I can’t write that sentence, I’m shopping, not solving. Then take a piece of work the team has already shipped the old way and do it again with the new tool, documented and timed against what the first run actually cost. A benchmark beats an opinion.

It has to beat the current path on the measure we agreed, and a second person has to reach the same result from the written instructions. One person’s magic isn’t adoption. Kill criteria and a review date are both set on day one, and if it hasn’t cleared the bar by that date it goes, and I write down why, so nobody reopens the argument in six months.

Things I’ve killed on this basis: v0, Lovable, Bolt and Windsurf, among others. Each one was worth the two weeks it took to find out.

What I got wrong

I built custom internal tools for problems thousands of other companies have too. It felt clever at the time and it was mostly ego. Off-the-shelf software wins on generic problems and it isn’t close, because someone else already paid for the edge cases, the security review, the mobile app and five years of support. Now I ask out loud which kind of problem it is before I open anything, and I say no to my own ideas fairly often.

I also blamed the model for a thin brief. The first version of Plans ran across a few models on a prompt that opened with barely a sentence of direction. No principles, no guardrails, no real account of what I actually wanted, and I got a basic site with no depth. Exactly what I’d asked for. The model didn’t do anything wrong. This is the most common lesson when a team first brings AI in, and it’s the one that makes people write the whole thing off, because they judge the tool on work they under-specified.

And I handed over a living document nobody wanted to live in. I built an end to end service blueprint for fulfilment with the team, then asked them to keep contributing to it. Two months later adoption was low and there were several copies floating around. The blueprint wasn’t the problem, its purpose was. I’d never made the case for the role it played beyond the mapping exercise, so the designers read it as one more thing to maintain, and they were right to. Nothing gets handed over now without a named owner and a reason it exists that survives me leaving the room.

Where this leaves the discipline

Design used to run like a relay with the fat part in the middle, and that middle is the part AI ate. The craft didn’t die, the volume of it did. What used to take three weeks of state-by-state polish now takes an afternoon, so the value moved to the decisions either side of it: what are we building and why at one end, and whether it actually works for the person who needs it at the other.

An engineer can design now. A product manager can build. A designer can do both. That doesn’t collapse three roles into one. Everyone gets broader, and each discipline stays deep enough to govern one thing for everybody else. UX, research and content design used to be separate specialists, they merged into product design, and the discipline came out stronger rather than thinner. The people who did well last time were the ones who got specific about what they still owned.

My AI practice was built solo, at production depth. My team-scaling practice was built at enterprise breadth. The interesting work now is the intersection.