AI made it easier to build the first version. It did not tell us what is worth building.

Know what you want before you ask AI to help.

AI can make you faster, but it cannot decide what matters for you. If you do not know who you are building for or why the problem matters, you can just build the wrong thing faster.

That is why I find the "taste is everything" framing incomplete. Taste helps, but it comes after intention. You need enough self-knowledge to notice what actually pulls at you, what drains you, and what kind of work you want to keep doing.

Tools can accelerate execution. They cannot do that part for you.

The first version is easier now. Choosing is still hard.

A few years ago, getting from idea to working product took more people and more time. Now one person can get surprisingly far if they can use the tools well.

That changes what matters. The impressive part is no longer that something exists. The impressive part is choosing a real problem, finding the simplest shape for it, and getting it in front of people.

When I teach people how to build, I want the first session to be about finding a problem worth solving. Code comes after.

Stay close to the person using it.

The useful product decisions usually hide in conversation with the user. By the time a problem becomes a polished ticket, a lot of the meaning has already been lost.

Buenos Aires has reinforced that for me. It is a social place, not a place where technology feels like the center of everything. That has made it easier to remember that the product is never the point. The person using it is.

Good technology gets out of the way.

Fast work needs guardrails.

I like moving quickly, especially with AI, but speed only helps if the work is still safe to ship. Tests, linting, evals, automated QA, logs, and release checklists matter more when the code is moving faster.

The right guardrails depend on the stakes. A personal experiment can tolerate more risk than a shared production codebase. But I do not buy the idea that AI work has to be sloppy. It should make better verification cheaper.

Autonomy matters because context decays.

I do my best work when I can see the problem, form a view, and act on it. Every handoff between observation and implementation loses something.

That does not mean working alone. It means keeping decision-making close to the people with the clearest signal. Talk to the user, understand the constraint, make the tradeoff, ship the change.

The indie hacker path is honest.

I am drawn to builders who start at zero and earn one user at a time. You either have something people want or you do not. Brutal, but clean.

Larger organizations can soften that feedback. Sometimes that is useful. Sometimes it lets a product drift for a long time without anyone admitting it. Indie building forces the question earlier.

That is the version of this work I want to get to eventually: build something real, learn from the market, and help other people do the same.