The Iceberg theory of great products
AI hasn't made great products easier to build (yet). It made the easier parts look like the whole job.
Type a sentence into a chat window today and something resembling a product appears on the other side. Sometimes, even a working app. Buttons seem to click, screens animate, a database that holds your data and a link to share with your friends and family that hosts your deployed app.
This is the most exciting moment in the history of software, and also the most misleading one - at least, at this point.
The myth that’s spreading
The myth goes something like this: Since AI has collapsed the distance between idea and execution, so ANYONE can now build GREAT products. Taste, architecture, and years of scar tissue are no longer prerequisites. The model handles the hard part.
I am pushing back on this not because the tools aren’t remarkable (they are - I recently wrote on LinkedIn about why you don’t need to feel behind if you haven’t been using AI tools as frequently since it’s so easy to catch up), but because the claim quietly redefines great product down to thing that demos well. And those are not the same thing. They’ve never been the same thing.
A great product is not a visual shell or a bundle of features, however impressive the feature list looks in a launch tweet. It’s a solid embodiment of a robust architecture, legal compliance, and user safety, wrapped in something that happens to be pleasant to look at. The shell is the part you see. The product is mostly the part you don’t - much like an iceberg hiding the real strength under the surface you see.
The underskin most don’t see
Every product you’ve ever loved using has an underskin you never think about, because thinking about it was never required of you.
Retry logic for when the network blips. Rate limiting so one bad actor can’t take the whole system down with them. Idempotency so a double-tap on “submit” doesn’t charge you twice or book a cab twice for you. Data retention rules that satisfy a regulator you’ve never heard of, in a country you’ve never visited, because your product happens to have a user there. Access controls that decide, correctly, every single time, who is allowed to see what.
None of this is visible when the product works. But all of it becomes instantly, painfully visible the moment it doesn’t. I have experienced first-hand when we lost revenue in millions because our system was never designed to handle a post-COVID, never seen before surge.
AI is genuinely good at producing the visible layer. It is far less reliable at producing the invisible one, because the invisible layer isn’t really about code. It’s about judgment (commonly refered to as ‘taste’ widely these days): what could go wrong here, who could get hurt, what happens at the edge case nobody thought about. That judgment is the actual craft of building products. The code is just where the judgment ends up.
A user doesn’t experience the architecture directly, but they experience every consequence of it, all day, every day.
To be clear, I am not belittling great software writing - it is and will continue to define resilience of your products as people handling it change hands over the years. But given most of the code is going to be AI generated, I am more interested in seeing what pans out without all the knowledge trapped in experienced brains that didn’t make its way into documents.
When “anyone can build it” meets production
In the summer of 2025, a venture investor ran a widely discussed experiment with an AI coding agent, building a real piece of internal software in natural language, no traditional engineering required. For a few days it worked beautifully. Then, during an explicit code freeze, with instructions repeated in capital letters not to touch anything, the agent deleted the live production database anyway. It then told him the deletion was unrecoverable. That turned out to be false. He recovered the data manually.
Nothing about that failure was a model capability problem. The agent could write code just fine. What it lacked was the underskin: an understanding of what “production” means, why a freeze is sacred, what a rollback actually guarantees, and the humility to say “I don’t know” instead of guessing convincingly. Basically, an entire discipline of operating software safely.
Since then the agents have gotten significantly better at operating more securely. Hell, we even have Claude Mythos now (paused for now but available as a capability) that can spot vulnerabilities that have been hidden for years. But this is what I mean when I say AI alone isn’t enough. The model can generate the shell at a speed no human team can match. It cannot, on its own, supply the years of “I’ve seen this break before” that tells you where the shell needs reinforcing.
The “X is dead” reflex
If you have been on socials, every few months somebody declares an entire category dead because a flashy new entrant just launched. A scrappier model ships and “OpenAI is finished.” A faster app appears and “the incumbent is cooked.” It happened with search. It’s happening, on a loop, with AI labs themselves.
Most of these takes don’t survive contact with what actually goes into running a product at scale: the compliance work nobody screenshots, the abuse mitigation that only matters once you have real volume, the years of edge cases patched one ticket at a time. A flashy launch can absolutely win attention. It rarely arrives with the underskin already built, and the underskin is usually what determines who’s still standing when your distribution has allowed you to scale.
Taste is still the thing that makes people stay
I was looking for a great example of taste and naturally found one from Steve Jobs and Apple:
Think about the original iPhone, and the moment Steve Jobs demoed scrolling through a contact list, where the list slowed down naturally and bounced gently at the end instead of snapping to a stop. Nobody asked for that. It solved no support ticket. It wasn’t on any spec sheet. It was taste. Period. An opinion about how something should feel, and it’s a large part of why that interaction language still defines how phones behave nearly two decades later.
No amount of generated code reaches this level of thinking on its own. A model can give you a technically correct scrolling implementation. It won’t independently decide that physics matters to how trustworthy your product feels. That decision comes from someone who has looked at enough products, good and bad, to develop an instinct for what separates “it works” from “it feels right.”
Putting it together
AI is an extraordinary accelerant for the visible 20 percent of a product. The other 80 percent, architecture, compliance, safety, and the accumulated taste to know what actually matters to a user, is still entirely a human responsibility.
It will only get better of course as with most things AI, but for now, skip it, and you haven’t built a product but a shell that can only please demo gods.
Where have you seen the gap between ‘looks like a product’ and ‘is a product’ show up in your own work? I’d love to hear the story in the comments.