Yes. Sort of.

"Can AI build my whole app?"

Yes.

Depending on what you mean by whole.

And depending on what you mean by app.

If you mean: can it generate a convincing interface, connect a database, add authentication, produce an API route and get something running surprisingly quickly?

Absolutely.

That part has changed enormously.

If you mean: can you now build a durable software business without understanding what any of it is doing?

That is where I become less enthusiastic.

Visible progress is extremely seductive

AI is very good at visible progress.

Ask for a dashboard and a dashboard appears.

Ask for a login screen and there it is.

Ask for a pricing table and seconds later you are choosing between three versions.

This is intoxicating if you have never built software before.

You can go from idea to something that looks real in an afternoon.

The danger is assuming that because the visible bit arrived quickly, the underlying system is equally solved.

It often is not.

The wall is usually somewhere behind the interface

Software becomes more interesting once real things are attached to it.

Money.

Personal data.

Permissions.

Emails.

Uploads.

Third-party APIs.

Different user roles.

Edge cases.

People doing things in the wrong order.

People doing things you were certain nobody would ever do.

At that point, the problem is no longer whether the button has a rounded corner.

The problem is whether clicking it creates the correct state without exposing something, duplicating something, charging somebody twice or quietly losing the information altogether.

That is architecture.

A figure constructs a paper interface on scaffolding.
A promising front end still needs sound foundations. Editorial image.

AI can generate the bug as confidently as the feature

This is one of the most important things to understand.

The model can produce code that looks completely plausible and is completely wrong.

Sometimes obviously wrong.

Sometimes more dangerously, wrong only under a condition you have not tested yet.

It can misunderstand an API.

Invent a method.

Use an outdated pattern.

Create a permission rule that seems reasonable until you think about it from the other user's side.

That does not make AI useless.

It means output is not evidence.

The fact that code exists is not proof that the job is done.

You do not need to become a computer scientist

This is where discussions about vibe coding can become unhelpfully elitist.

I do not think the answer is that everybody now needs a formal computer science education before they are allowed near a code editor.

That would be absurd.

You can learn as you build.

AI is extremely useful for that.

Ask it what a function is doing.

Ask it why a database relation exists.

Ask it to explain a request flow.

Ask it what could fail.

Ask it to compare two approaches.

Use the speed to learn the system rather than using the speed to avoid learning the system.

There is an important difference.

Learn the joins

You do not need to know every language.

You do need to understand how the pieces connect.

Where does the data live?

Who can read it?

Who can change it?

What happens when somebody is not logged in?

What happens when payment succeeds but your webhook fails?

What happens if the external service is unavailable?

What happens when a user presses the button twice?

What is logged?

What can be recovered?

Where are the secrets?

If you can answer those questions, you are beginning to understand the product.

If you cannot, you are operating something you do not yet control.

Build with a critic, not only a builder

One of the ways I use AI is to separate making from checking.

The thing that writes the code should not be the only thing deciding whether the code is correct.

Have another pass challenge it.

Ask for failure modes.

Check the implementation against the actual requirement.

Run the tests.

Look at the database.

Verify the production result.

Do not accept:

Done. Everything is working.

as evidence that everything is working.

This sounds obvious.

It is apparently not obvious.

Vibe coding is useful. Vibe ownership is not.

I actually like the phrase vibe coding because it describes something real.

You can express what you want at a higher level and let the machine handle a lot of the implementation detail.

That is powerful.

But the further you move away from the implementation, the more important it becomes that somebody still owns the logic.

Otherwise you have a product assembled from decisions nobody remembers making.

That is fine for an experiment.

It is less fine when customers are paying.

The founder still has to understand the system

This is the part I think gets lost in both the hype and the backlash.

AI does not mean you should stop building.

For the prototyping work I am describing, it can make the first experiment quicker to build.

That should make more people experiment.

More people can test ideas.

More people can get to a working prototype without spending months learning syntax before discovering the idea was rubbish.

That is excellent.

But a prototype and a product are not the same thing.

A product has to survive users.

And users are magnificently creative at finding the one path you did not think about.

Build quickly. Learn quickly. Verify everything.

That is my view of it.

Use AI aggressively.

Let it write boilerplate.

Let it explain code.

Let it refactor.

Let it generate tests.

Let it help you debug.

Let it accelerate you.

But do not confuse speed with understanding.

The useful founder is not the person who can type every line manually.

It is the person who knows what the system is supposed to do, knows enough to recognise when it is not doing it, and takes responsibility for the result.

AI can write code.

You still have to build the thing.

Keep exploring