You still have to want the thing you are building

There is a strange problem with being able to build more things: every idea starts to look affordable.

An improvement that would once have stayed in a notebook can become an active task before I have decided whether the product needs it. An agent can investigate. Another can prototype. By the time I return to the original question, there is something working well enough to argue for its own existence.

I enjoy that possibility. I also have to manage it.

I build games partly because I care about the experience of making something personal. The humor, pacing, surprise, and small details matter to me. If I let a growing task list define the project, I can spend a great deal of time improving its completeness while losing the reason I wanted it to exist.

Cheap to try does not mean cheap to keep

A prototype can be inexpensive. Keeping its idea introduces other costs: explanation, maintenance, interaction with existing systems, and attention from the person using the product.

Those costs do not disappear when a model writes the first version. They may become easier to overlook because the implementation arrives before the tradeoff has been discussed.

I try to distinguish permission to experiment from a commitment to ship. A promising experiment deserves a look. It does not deserve permanent space in the product merely because it already runs.

This is harder than it sounds. Once I can see an idea on screen, I become attached to it. The useful question is whether it makes the whole experience better, including the parts I already liked.

Taste needs something to push against

I do not think taste is a mystical quality that a leader either has or lacks. A lot of it develops by making a choice, looking closely at the result, and noticing why it falls short.

AI gives me more chances to do that. I can compare different approaches, revisit an assumption, or make an awkward version concrete enough to understand. The value comes from paying attention to the differences.

If I accept the first plausible answer every time, I am not developing much judgment. I am mostly collecting output.

There are also times when the right feedback is to remove something. A quieter screen can communicate more. A smaller choice set can make a decision clearer. A simpler interaction can leave more room for the part of the product that matters.

Attention is still finite

The practical limit on my side projects is not just coding capacity. It is the time and attention I can give them alongside work and the rest of my life.

That makes selection more important as implementation gets easier. I want to spend an evening on a problem I care about, not on managing the consequences of every interesting suggestion an agent can generate.

For me, this is one of the better reasons for an engineering leader to keep building personally. It is a direct reminder that an overflowing backlog is not a strategy, and that creating options and choosing among them are different responsibilities.

I want the tools to give me more room to make the thing I care about. I do not want the availability of the tools to decide what that thing becomes.