Your First AI-Generated App Is Easy. Change #20 Is the Real Test.

Gökçer Altuntaş — Thu, 17 Sep 2026 14:17:02 +0000

AI app builders made starting incredibly fast. The harder question is what happens after weeks of changes.

A few years ago, getting an app from an idea to a working prototype was the hard part.

Today, that part can take an afternoon.

You describe what you want, an AI builder creates the UI, connects some logic, and suddenly you have something that looks surprisingly close to a real product.

That’s impressive.

But I’m starting to think we’re measuring these tools at the wrong moment.

The interesting question isn’t:

“What did it build from my first prompt?”

It’s:

“What does this project look like after change #20?”

The first version is almost becoming a commodity

Most modern AI builders can create a decent first version.

Give them something like:

Build a client portal with authentication, file uploads and a dashboard.

You’ll probably have something recognizable pretty quickly.

That used to feel like magic.

Now it’s almost expected.

The problems usually start later.

The customer needs another role.

You change the onboarding flow.

The database structure changes.

You add payments.

Then permissions.

Then one small request somehow breaks something that was working three prompts ago.

Suddenly the question is no longer how quickly the AI can generate code.

It’s whether the product can survive iteration.

A better test for AI app builders

If I were comparing AI builders today, I wouldn’t give each one a different demo prompt.

I’d give them the exact same small application.

Then I’d intentionally make it annoying.

Add another user role.

Change the database schema.

Replace part of the onboarding flow.

Add an external API.

Change the permissions.

Remove a feature.

Then bring it back differently.

That’s when you start seeing the actual differences between tools.

Does the project still make sense?

Does changing one thing quietly break another?

Can you understand what changed?

Can you roll back a bad decision?

And, probably most importantly:

Can you keep building without becoming afraid to touch your own app?

“It works” and “it’s maintainable” are very different things

This becomes even more important when real users arrive.

A generated app can look completely finished while still having problems underneath.

Authentication might work for the happy path but fail in edge cases.

The UI may hide another user’s data while the backend permissions don’t actually protect it.

An integration may work perfectly until the external API returns something unexpected.

None of these problems look impressive in an AI demo video.

But they’re the things that decide whether a product survives after launch.

This is something we're thinking about with built.new

Full disclosure: I’m involved with built.new.

We’re building in this space, so obviously I have a perspective here.

One thing we keep coming back to is the gap between:

“AI built my app.”

and

“I can actually keep building my app.”

Generating the first version faster is valuable.

But if every change after that adds more uncertainty, some of that initial speed disappears.

The goal shouldn’t just be reducing the time between idea → first build.

It should also reduce the friction between:

first build → feedback → change → more feedback → real product.

That second loop is where a lot of products actually get made.

Maybe the benchmark needs to change

We’ve spent a lot of time comparing AI development tools based on generation speed.

Maybe the better benchmark in 2026 is simpler:

Build something today. Change it 20 times. Is it still pleasant to work on?

If the answer is yes, that’s much more interesting to me than another app generated in 60 seconds.

I’d be curious how other people are testing this.

What usually breaks first for you when an AI-generated project starts getting more complex?

We Thought It Was a Cache Bug. It Was Actually a Stale Clone.

Gökçer Altuntaş — Wed, 09 Sep 2026 13:25:14 +0000

When a recent code change does not appear where you expect it to, cache is often the first thing that comes to mind.

And sometimes cache really is the problem.

But before clearing everything, rebuilding the application, restarting containers, or digging into deployment settings, there is a much simpler check worth doing first:

Make sure you are actually running the code you think you are running.

Start with the repository

A few basic Git commands can quickly tell you what state your local repository is in:


bash
git status
git branch --show-current
git log -1 --oneline

DEV Community: Gökçer Altuntaş

Your First AI-Generated App Is Easy. Change #20 Is the Real Test.

We Thought It Was a Cache Bug. It Was Actually a Stale Clone.

Start with the repository