Recently I was putting together a presentation and needed a few on-brand mocks to carry the story. Nothing elaborate, just a handful of branded screens that would make the idea feel real instead of described. I’ve made these before and I’ll make them again, and the work is always the same. Open Figma, lay it out, write the copy, match the system, export. It isn’t hard, really. It’s just slow, and it repeats.
So I didn’t make the mocks. I had Claude help me build a small tool that makes them: a standalone generator for simple branded screens. The presentation got what it needed, and the next one will too… without me rebuilding the same thing by hand.
A few years ago that wouldn’t have been a decision at all. Building the generator would’ve cost more than making the mocks by hand a dozen times over. You’d have had to scope it, build it, debug it, and keep it alive, and for a few screens that was never worth it. “Can I build something to do this for me” had an obvious answer, and the answer was usually no.
That answer has flipped. With AI helping, the tool took an afternoon instead of a sprint. The cost of making things collapsed. The cost of deciding what’s worth making didn’t, and that gap is where the new skill lives.
So the question you now face several times a day isn’t really whether you can build it. It’s which of the things you could build (with almost no friction, remember) are actually worth building. Not a moral brake, not hand-wringing. A practical filter, applied constantly.
I built the generator for one reason, and it had nothing to do with whether I could. The need repeats. One presentation doesn’t justify a tool; a year of presentations does. The mocks were a pattern wearing the disguise of a one-off task, and once I saw the pattern, building was the obvious move.
It wasn’t the only one. Client reviews used to mean emailing files and chasing replies across a thread; now the directions sit side by side on one page where the client leaves feedback right on them. Handoffs used to be a folder of download links that quietly rot; now the files live on a page that delivers them and sends the responses straight back to me. Neither was worth building for one project. Both were patterns wearing that same disguise.
That’s the decision rule, and it’s older than AI: solve the instance by hand, build the tool when the instance turns out to be a pattern. What AI changed is the threshold. When building took a week, a pattern had to be strong and frequent to earn the investment. Now that it takes an afternoon, far more things clear the bar.
That’s genuinely freeing, and it’s also where the trouble starts. Because building is now cheap and, honestly, fun, the failure mode has inverted. The old risk was that you couldn’t make the thing you needed. The new risk is that you make things you don’t need: a tool for a problem you have once, an over-built version of one you have often, a polished internal generator for three users while the actual work waits.
I’ve caught myself here, starting to build the review page before I knew whether the project even needed a second round. The tool is satisfying to make. It produces a working thing with a clean interface, something that looks like output… and that feeling is easy to mistake for having done the job. Sometimes the disciplined move is to skip the tool and do the boring task, because the task is small and won’t come back.
When you couldn’t build most things, capability was the constraint, and getting more capable was the whole game. Now capability is cheap and judgment is the constraint. I’ve written about what that judgment looks like once the work exists, sorting the model’s output into its kinds of wrong (Which Kind of Wrong). This is the version that comes earlier: knowing what deserves to exist at all, what’s worth your afternoon, what should stay a manual task and what should become a tool.
“Can I build this?” settled itself; the answer is usually yes. “Should I?” still costs what it always did.