A year ago, most of my software ideas died in the gap between “I want this” and the weeks I would need to learn enough code to build it.

AI coding tools compressed that gap to an afternoon. I now build scripts, automations, and small tools for specific parts of my work. Some became permanent. Others worked exactly as requested and were never opened again.

The abandoned tools taught me more. Cheap execution makes weak ideas look affordable because the first hour costs so little. The maintenance, clutter, and attention arrive later.

A prototype still has carrying costs⌗

A small internal tool can save 30 minutes every week. Over a year, that is roughly 26 hours before accounting for maintenance. Spending two hours to build it is an easy decision.

Another tool may save 30 minutes once. It still needs a name, a folder, dependencies, credentials, and enough documentation for Future Me to remember why it exists. The build was cheap. The return was worse than doing the task by hand.

AI can make both tools. It has no stake in which one earns a place in the workflow.

Taste, in this context, is expected-value judgment. How often does the problem occur? How expensive is it? What changes if the tool works? How much ongoing attention will it consume? How bad is the failure case?

Those questions used to hide behind the cost of learning to code. A mediocre idea rarely survived three months of prerequisite work. Now it can survive long enough to become a functioning distraction.

Building can become avoidance⌗

Fast prototypes feel productive. They provide visible progress, instant feedback, and a steady run of small technical wins. Thinking about whether the underlying problem deserves attention feels slower.

That creates a predictable trap: build first, search for a use case later.

I have caught myself doing it. A vague workflow annoyance turns into a tool idea, and the tool idea becomes more interesting than the annoyance. Two hours later I have a working interface for a problem that occurs twice a year.

The code may be fine. The allocation of time was bad.

Make the idea pay rent on paper⌗

Before I start a new tool, I want clear answers to a few questions:

  • How often did this problem occur in the last 30 days?
  • How much time or money did it consume?
  • What part can run deterministically, and where will judgment still be required?
  • What data or credentials will the tool touch?
  • What ongoing maintenance am I volunteering for?
  • What will I stop doing if I build this?

The last question catches a lot of weak projects. Time spent building a clever dashboard may replace time spent fixing the process the dashboard measures.

A useful answer also needs a concrete before and after. “This will streamline reporting” tells me very little. “This will turn a repeated 45-minute export and cleanup job into a five-minute review” gives me something I can test.

Easier execution raises the bar for judgment⌗

AI expanded the number of things I can build. It also increased the number of plausible ways to waste a day.

The durable advantage comes from selecting problems with enough frequency, cost, or frustration to support a tool. Clear requirements help build the right version. Tests help keep it working. Taste decides whether the project deserves either investment.

Make the idea pay rent on paper first. The model will still be ready when the math works.