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 have made these before, and I will make them again, and the work is always the same. Open Figma, lay it out, write the copy, match the system, export. It is not hard. It is slow, and it repeats.
So I did not make the mocks. I had Claude help me build a small tool that makes them, a standalone generator for simple branded mocks for the client. 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 would not have been a decision at all. Building a tool to generate the mocks would have cost more than making the mocks by hand a dozen times over. You would have had to scope it, build it, debug it, and keep it alive, and for a few screens that was never worth it. So you made the screens. “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 something collapsed, and once the cost of making something collapses, “can I build this” stops being an interesting question. The answer is almost always yes.
Which means the real question is no longer whether I can build it. It is whether I should. Not in the hand-wringing sense, and not as a moral brake. The question is practical, and it is one you now face several times a day: of all the things you could build with almost no friction, which ones are actually worth building?
The cost of making things fell. The cost of deciding what is worth making did not. That gap is where the new skill lives.
I built the generator for one reason, and it had nothing to do with whether I could. The need repeats. One presentation does not justify a tool, but 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 the tool was the obvious move. The instance was not worth automating. The class was.
And it was not the only one. The same thing happened with client reviews. Sharing a few directions used to mean emailing files and chasing replies across a thread. Now it is a single page where the client sees the options side by side and leaves feedback right on them.
It happened again with handoffs. Instead of a folder of download links that quietly rot, the files live on a page that delivers them and sends the responses straight back to me. None of these were worth building for one project. All of them were patterns wearing the disguise of one-off tasks.
That is the decision rule I keep coming back to, and it is 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 building takes an afternoon, the bar is far lower, so far more things clear it. That is genuinely freeing, and it is also where the trouble starts.
Because building is now cheap and, honestly, fun, the failure mode has inverted. The old risk was that you could not make the thing you needed. The new risk is that you make things you do not need. You build a tool for a problem you have once, over-build the one you have often, and polish an internal generator that three people will use while the actual work waits. I have caught myself starting to build the review page before I knew whether the project even needed a second round. Building can start to feel like progress when it is really a more sophisticated way to avoid the task in front of you.
It is easy to catch yourself here, because the tool is satisfying to make. It produces something that looks like output, a working thing with a clean interface, and that feeling is easy to mistake for having done the job. Sometimes the disciplined move is to skip the tool and just do the boring task, because the task is small and will not come back.
This is the part I keep returning to. When you could not build most things, capability was the constraint, and getting more capable was the whole game. Now that you can build almost anything, capability is cheap and judgment is the constraint. Knowing what deserves to exist, what is worth your afternoon, what should stay a manual task and what should become a tool, that is the skill that is actually scarce now.
“Can I make this?” is increasingly settled. More often than not, the answer is yes. “Should I make this?” is still hard. And that is the question worth getting good at.