Now I’m Limited by What I Can Imagine

For a long time, I was limited by my ability to write code.

I could imagine an interaction, a small tool, or some strange feature that did not exist yet, but there was always a gap between the thing in my head and the thing I could actually make. Sometimes the gap was a framework I did not understand. Sometimes it was a database problem, an API, authentication, deployment, or some bug that seemed to have nothing to do with the product itself. A large part of building software was negotiating with my own technical limits.

This was frustrating, but it was also strangely comfortable. There was always an obvious explanation for why the product was not better yet. I had not learned enough. I could not implement the feature. The code was too complicated. The architecture needed to be rewritten. I could spend several days deep inside some technical problem and feel that I was making progress, even when the experience of using the product had barely changed.

Code gave the work resistance. It also gave me somewhere to hide.

That resistance is disappearing.

I can now describe a feature, ask an AI to implement most of it, test it, point out what feels wrong, and continue from there. Things that would previously have required a week of learning, searching through Stack Overflow, abandoning one library, installing another, and eventually accepting a compromised version can sometimes be produced in an afternoon.

It is not magic. The generated code is often messy. It misunderstands the existing system, invents abstractions, breaks things that were previously working, and confidently implements the wrong interpretation of what I asked for. But even with all of that, the distance between an idea and a functioning prototype has collapsed.

I am no longer mostly limited by whether I can write the code.

I am limited by whether I can think clearly enough about what the product should do.

This turns out to be a much more uncomfortable limitation because it is harder to blame on anything external. There is no compiler error for a weak product idea. There is no red underline under a feature that should not exist. The app can build successfully, pass all the tests, deploy without errors, and still have nothing meaningful to say.

When implementation was expensive, I naturally treated ideas as valuable. There were always more things I wanted to build than I had the ability or time to build. Now implementation is becoming cheaper, and I am beginning to notice that many ideas were only interesting because they were difficult to implement.

Once the difficulty disappears, the feature itself can look strangely empty.

I can ask AI to add a chart, a notification system, a conversational interface, a map, personalization, animations, widgets, live activities, summaries, recommendations, or some agent that performs actions in the background. But the existence of all these possibilities does not tell me which one belongs in the product. It mostly creates a larger space in which to make bad decisions.

The new bottleneck is not exactly creativity. I can generate hundreds of feature ideas. AI can generate thousands more. Feature generation might now be one of the least scarce things in software.

The bottleneck is judgment.

What is the person actually trying to do? What are they uncertain about when they open the app? What information would change their decision? What does the product know that the person does not? When should it say something, and when should it remain quiet? What should happen automatically? What should still require intention? Which piece of complexity belongs in the system so it does not have to exist in the user’s head?

These questions feel less concrete than writing code, but they are probably closer to the real work.

Take a weather app. It is easy to think in terms of adding weather features. More charts, additional data sources, radar layers, widgets, historical comparisons, weather alerts, AI summaries. All of these can be built. Some of them may even be useful.

But a person rarely opens a weather app because they want weather data. They open it because they are deciding whether to leave now, what to wear, whether the rain will stop, whether they can go running, whether the evening plan is still possible, or whether today feels cold only because yesterday was unusually warm.

The product feature is not the chart. The feature is the reduction of uncertainty.

That sounds obvious when written down, but I still regularly begin from the other direction. I see a technical capability and start searching for somewhere to put it. The model can summarize, so perhaps the app needs a summary. The system can monitor something, so perhaps it should send notifications. The phone has a new API, so perhaps the product should use it.

Previously, the implementation cost filtered out many of these impulses. Now I can follow nearly all of them, which means I need a much stronger internal filter.

This also changes what it means to be deep in the work. I used to associate depth with being inside the code. There was a physical feeling to it. Many files open, a problem slowly becoming understandable, the rest of the day disappearing. Product thinking often does not feel like that. It can look like walking around, staring at the screen, using the app repeatedly, noticing a sentence that feels wrong, or spending an hour trying to understand why a technically functional interaction still feels dead.

There is less visible proof that anything is happening.

Maybe that is why it is tempting to return to code. Code produces activity. Product judgment often produces deletion, simplification, hesitation, or the decision not to build something. It is possible to spend a day thinking and end with fewer features than before.

But perhaps this is the phase change.

Before, I needed to learn how to express my ideas through code. Now I need to learn how to form ideas precise enough to deserve code.

The skill is not imagining more things the product could do. It is noticing what is missing from the user’s experience, naming it clearly, and designing the smallest behavior that changes it. Then watching what happens and accepting that the first interpretation was probably wrong.

AI has not removed the hard part of building products. It has moved the hard part upstream.

The difficult part is increasingly deciding what should exist.

Connected reading

• The Prototype Has Become Too Cheap to Trust
• The Coding Assistant Is Becoming the Development System
• The End of the Software Request
• The Product Is No Longer the Product
• The Interface Is Now Part of the Answer

AI authorship note

This essay began with Kris Haamer reflecting that he used to be limited by his ability to write code and is now limited by his ability to think about product features. AI supported drafting, editing, and implementation. Kris supplied the central observation, redirected the argument toward product judgment rather than feature generation, and approved the article for publication.