Is AI Really Going to Build Apps From Your Thoughts? A Founder Who Actually Uses AI Every Day Thinks Not

Every few months, someone describes AI as the future of programming: "In five years, you will not write code. You will just describe what you want and AI will build it."

I use AI extensively in my work. I generate code, review code, help debug codebases, and collaborate with people building products. I have access to every major AI system, and I use them daily.

That is not my experience at all.

‍

The Logic Behind the Prediction

The thinking goes like this: If AI can generate code from natural language instructions (prompts), and AI is improving rapidly, then at some point AI will be good enough that humans will not need to write code anymore.

That assumes that programming is primarily about translating intent into code. If that were true, the prediction would make sense.

But programming is not primarily translation. Programming is decision-making under uncertainty.

‍

What You Are Actually Doing When You Code

When you sit down to write code, you are making hundreds of small decisions:

Should this function exist? Should it be on this object or that one? How should error handling work in this case? Is this interface stable or might it need to change? Should this be synchronous or asynchronous? What happens when the system is under load? What does this third-party API actually do when you give it bad data?

These decisions are not obvious. They depend on:

- How the system will be used

- What the constraints are (performance, latency, budget, compliance)

- What the team can maintain

- What will change next

The code itself is just the recording of those decisions. The value is not in the typing. The value is in knowing which decisions to make.

An AI can generate code. An AI cannot make those calls for you.

‍

Translating Intent Into Decision

Here is what I actually do when I use AI:

1. I have a clear picture of what I want to build and why

2. I describe the thing (in prompts, or sometimes in comments in code)

3. AI generates an implementation

4. I review the implementation and make decisions

- Does this approach fit with the rest of the architecture? If not, I guide the system toward a different approach.

- Does this handle the edge cases my system needs to handle? If not, I add them or ask the system to.

- Is this maintainable and understandable by my team? If not, I refactor it.

- Is this performant? If not, where is the bottleneck and what is the right approach to address it?

5. I iterate until the code reflects the decisions I have made

That is different from "describe what you want and AI builds it."

It is collaborative. AI generates options. I select and refine them.

This is faster than writing code by hand. It is not faster in the way the prediction assumes (instructions in, finished app out). It is faster because the person doing the choosing is running a tighter loop with better information.

‍

Why That Distinction Matters

The difference between "AI writes code from descriptions" and "engineers make faster decisions with AI assistance" is everything.

The first model removes the engineer from the loop. The decisions are made by whoever wrote the prompt, which might not be the person who understands the system. You end up with code that is technically correct but strategically wrong.

The second model puts the engineer in the loop. The engineer can evaluate whether the code reflects good decisions about how the system should work. If it does not, they know what to change.

Companies trying the first model are learning why it does not work. Anthropic published a case study a few months ago where a team attempted to use Claude to generate an entire system from a specification. It created something that was internally coherent but did not solve the actual problem. The person who understood the problem needed to be involved in every decision.

‍

The Timing Problem

These predictions usually come with a timeline. "In five years..."

That timeline reflects how fast the person making the prediction thinks AI capabilities will improve.

But capabilities are not the limiting factor here. Even if AI could generate a perfect implementation from a one-sentence description, that would not change the fundamental problem: the engineer still has to decide what to build.

If anything, as AI gets better at implementation, the decision-making part of the job becomes more important, not less. Because the decisions are harder to spot, and the consequences of making the wrong ones are bigger.

‍

What Is Changing About Programming

AI is changing programming. Just not in that way.

Code review is becoming collaborative between human and machine. An AI system can spot classes of bugs a human might miss. A human can evaluate whether the code makes architectural sense. Together they build more reliable systems faster.

Iteration cycles are compressing. The feedback loop from "I have an idea" to "I have code to review" is shrinking. That is powerful because it lets teams validate ideas faster and learn whether they are right.

Certain classes of work are disappearing. Boilerplate code generation, test writing, API documentation: these are becoming increasingly automated. That frees engineers to spend time on the decisions that actually matter.

The junior-to-senior gap is widening, not closing. Because the decisions require judgment, and judgment comes from experience. An AI that can write code will not replace the experienced engineer who knows what code should do. It will replace the person who just types what they are told to type.

What is not changing is that building reliable systems requires people who understand how systems fail. And building systems that matter requires people who understand what people actually need.

AI is a tool for making those people more effective. It is not a replacement for those people.