AI Can Build Anything. Here's How to Build the Right Thing.

You can build almost anything now. Describe it well enough and an agent will hand you something that runs. The barrier that kept most people out of software for fifty years is mostly gone, and that is genuinely thrilling.

Here is the part nobody handed you along with the tools: knowing what's worth building. That skill has a name, product thinking, and for decades it stayed hidden behind the harder skill of writing the code. Now the code is the easy part, and product thinking is the whole job. Most people who just became builders have never been taught it, through no fault of their own.

If I could go back and give a new builder one short list before they wrote a line, this would be it.

Start with the change you want to make, not the thing you want to build

Pick one person and one problem, and get specific about what is different for them after you build. A feature list is not a plan, it is a wish dressed up as one. The tools will build whatever you point them at, so the pointing is the skill now, and the aim is the one thing AI cannot supply for you. Decide what changes for someone real, and the rest of the work has something to answer to.

Resist building the cathedral before you have a congregation

When everything is buildable, the temptation is to build all of it. Don't. The discipline now is a "not yet" list that stays longer than your "now" list. It is dangerously easy to build a cathedral before you have a congregation: an elaborate, beautiful product that no one has actually asked to stand inside yet. Find the single thing one real person will use, build only that, and earn the next room before you frame it. Constraints are not the enemy here; they are what make all this capability useful. We wrote about that in find the ceiling before you set the floor.

Get out of the editor and in front of a real user

You cannot do product thinking in a vacuum, and you cannot validate a product by admiring your own screens. The person closest to the problem should be closest to the build, and if that person is not you, go sit with them until you can think like they do. One real user touching the thing for ten minutes teaches you more than another week of features you imagined they wanted. Do it early, and keep doing it.

Name the things before you build the screens

Every domain has its own nouns and verbs: the real objects and actions of your user's world. Get those names right, and the data model that holds them, and everything you build afterward has a spine to grow on. Get them vague and no pile of features will hold the product together later. This is the cheapest decision to make at the start and the most expensive one to change once you've built on top of it.

Ship the smallest real thing, not the most impressive demo

"Real" means a person can use it end to end and walk away with something they wanted. A demo just means it looks done. The happy path always looks done, which is exactly why it fools the person who built it. This is the gap between looking finished and actually being finished that trips up almost everyone starting out. Ship the small real thing, watch someone use it, and let what breaks tell you what to build next.

Instrument it from day one, and build the smallest loop that can learn

From the very first version, record what the product did and how people reacted: the corrections, the things they abandoned, the moments they got what they came for. Keep a handful of saved real examples you can re-check whenever you change something. You don't need automation yet, you need the loop to exist, because the signal you don't capture today is gone for good. A product that can learn from its own use is a different kind of thing than one frozen at launch.

Work with the agents, don't just dispatch them

The agents building alongside you are collaborators, not a vending machine you drop a prompt into. Write your principles and your intent down once, give them the context and the memory to carry it, and your judgment travels into everything they produce. Point them carelessly and you get exactly what they're good at: fast, confident, fully-formed work in the wrong direction.

"It runs" is not "it's done"

The screens load, the demo plays, the agent says it's finished. None of that tells you the product is done. Done is the login that holds, the edge cases nobody demoed, the data model that has to change without breaking everything, the failure you would never have seen without looking for it. Closing that gap is slower than generating the happy path, on purpose, and it is most of what separates a real product from a convincing screenshot.

None of this is about slowing down. It is about aiming before you fire, because the tools fire instantly now.

The old question was "can I build this?" For most things, the answer is now yes, and it stopped being the interesting question. The new one is "is this the right thing, and is it actually done?" That question is product thinking, and getting good at it is the most valuable thing you can do as a builder right now. The capability got cheap. Judgment, taste, and knowing your people got scarce. Those were always the real work, and they are still yours.