AI Gets You to 80%. The Last 20% Is Where the Product Lives.

I’ve built more software in the past few months than I ever thought I realistically could.

Not because I suddenly became a software engineer.

Because AI changed the economics of building.

An idea that once would have required a developer, a designer, a project manager, a meaningful budget, and probably a few months can now become something interactive surprisingly quickly.

You can describe a workflow and watch the database appear. Ask for a new page and get one. Connect an API. Generate an email. Build authentication. Create an admin panel. Change the navigation. Fix a bug. Deploy.

It is genuinely remarkable.

It has also taught me something I didn’t expect: AI is incredibly good at getting a product to about 80%.

And the remaining 20% is where the actual product starts to emerge.

I’ve run into this over and over.

A feature gets built. I test the obvious path. No error. The database updates. Technically, it works.

Then I try to actually use it.

I invite someone to a trip. The invitation technically exists, but there’s no clear indication that anything was sent.

I send someone a quote. The link works, but the interface doesn’t tell the salesperson when it was last sent or what they should do if they need to resend it.

I build a community feature. People can comment, but opening the conversation jumps them somewhere unexpected.

I add restaurant discovery. The restaurant appears, but tapping its name doesn’t do the thing virtually every user would expect it to do.

I create a location-based feature. Then realize I never actually gave the product a sensible way to get the user’s location.

None of these are enormous engineering failures. In fact, that’s the point.

They’re product failures.

The code can be correct while the experience is wrong.

That’s both the superpower and the problem.

If I say, “Add an invite button,” AI can add an invite button.

But the real feature isn’t the button.

• A person wants someone else to join them.
• They enter an email address.
• Something visibly happens.
• They understand whether the invitation was successful.
• They can see who has been invited.
• They can cancel an accidental invite.
• The recipient gets something understandable.
• The link takes them somewhere sensible.
• If they don’t already have an account, the signup process preserves the context of why they arrived.
• When they finish signing up, they actually join the thing they were invited to.

That is the feature.

The button is maybe 5% of it.

And this is where I think AI-assisted development can fool us.

Because the speed of creation creates an enormous amount of visible progress. Pages appear. Buttons appear. Features appear. The app looks increasingly finished.

That can make it very easy to confuse surface area with product maturity.

They are not the same thing.

The remaining work is rarely: “Can AI write this function?” Usually it can.

The harder questions are:

• What happens if there’s no data?
• What happens when something fails?
• What does the user think just happened?
• What is the most obvious thing to click?
• Can they undo this?
• What happens on mobile?
• What happens if they aren’t logged in?
• What happens if they arrived through a shared link?
• Is there confirmation?
• Does this screen feel like the rest of the product?
• Does the language make sense to someone who didn’t build it?
• Would a first-time user even know this feature exists?

Those questions require context. And taste. And empathy. And an understanding of the entire journey.

AI can absolutely help answer them.

But somebody still has to realize they need to be asked.

I use the product.

Seriously.

That has become one of the most valuable parts of my development process.

Not reviewing screenshots. Not reading the implementation notes. Not asking whether the task was completed.

Actually opening the thing.

On my phone. In another browser. In incognito. With another account. With an empty account. With bad input. By clicking the thing I probably shouldn’t click.

By deliberately ignoring what I know about how the product was built.

And asking: If I had never seen this before, what would I think is happening right now?

The number of problems that appear immediately is incredible.

A hover state makes an entire section look clickable when only individual cards are clickable. A primary action is visually weaker than something unimportant. A confirmation message disappears too quickly. A blank screen technically represents “no results” but feels like the app crashed. A feature exists three taps deeper than anyone would ever look for it. A beautifully generated interface uses slightly different cards, buttons, spacing, and terminology on every screen.

None of this necessarily shows up as a software error.

But users experience all of it as friction.

This has been another recurring lesson.

AI can design a gorgeous screen. Then it can design another gorgeous screen. And another.

And somehow you end up with three gorgeous screens that look like they belong to three different startups.

Every generation introduces the possibility of another interpretation: a slightly different border radius, a new card treatment, different spacing, another shade, a different illustration style, a new way of wording the same action.

Individually, none of those decisions seem important.

Collectively, they make the product feel unfinished.

So I’ve become much more interested in creating systems before creating more screens.

Define the typography. Define the spacing. Define the buttons. Define the surfaces. Define the image style. Define the voice. Define what an empty state looks like. Define what success looks like.

Then ask AI to work inside those constraints.

The goal isn’t to stop AI from being creative.

It’s to stop every prompt from accidentally becoming a redesign.

I don’t want the takeaway here to be that AI development is overhyped.

I think the opposite.

The leverage is extraordinary.

Ideas I probably would have left sitting in a Notes app can now become functioning products. Internal business processes that never would have justified custom software suddenly might. Small organizations can build tools that previously required outside development. One person can experiment at a scale that would have been absurd a few years ago.

That is a massive shift.

But the most interesting lesson for me has been that AI doesn’t eliminate the need for product thinking.

It exposes how important product thinking actually is.

When building becomes cheap, deciding what deserves to be built becomes more important.

When implementation becomes fast, noticing the details becomes more important.

When anyone can generate an interface, taste becomes more important.

When features are easy to add, knowing when not to add another one becomes more important.

AI dramatically compresses the distance between an idea and a working prototype.

That may be its biggest advantage.

But a prototype and a product are still different things.

The final 20% is where you find out whether someone can actually use what you built.

And increasingly, that’s the part of the work I find most interesting.