Today, with AI, one person can turn an idea into a working application in very little time. That opens up enormous possibilities: you can test more ideas and build prototypes much faster. But this new capability brings a confusion with it. Getting an application to do what we need is one thing; building software that is ready to be maintained, operated, grown and changed is something else entirely.
Today you can describe an application, open an AI tool and start building.
A login.
A dashboard.
An API.
An integration.
In a few hours you can have something that does what you needed.
And it works.
The problem is that in software, something working is only part of the story.
The part we see
When we think about an application, we usually think about the functional side.
The user has to be able to sign up.
They have to upload a file.
The system has to process it.
It has to show a result.
It has to send a notification.
These things are easy to describe because they are visible.
We can test them.
We click, upload the file and see whether the result shows up.
With AI and vibe coding, turning that kind of requirement into code has become incredibly fast.
You explain what you need.
The tool generates.
You test.
You fix.
You generate again.
Until it works.
But there is another part of software that almost never shows up in the first prompt.
What you don't see in a demo
What happens if a thousand users come in at the same time?
What happens if an external API takes thirty seconds to respond?
What happens if we process the same event twice?
What happens if a deploy fails?
What happens if you need to know why an operation went wrong three days ago?
What can each user see?
How do you rotate a credential?
How do you recover the data?
How easy is it to change one part of the system without breaking five others?
None of that usually shows up in the demo.
Until it does.
And when it does, the application may still do exactly what you asked for, functionally.
The problem is that it wasn't designed to operate, grow or change.
Functionality is only one part of software
In software engineering, this distinction has existed for a long time.
On one side are the functional requirements: what the system does.
On the other, everything that defines how it has to behave while doing it.
Performance.
Security.
Availability.
Scalability.
Observability.
Maintainability.
Error recovery.
They don't all matter in the same way every time.
An internal tool for five people doesn't need the same architecture as a platform that processes thousands of operations.
And that is exactly the point.
You have to know those decisions exist in order to decide which ones matter.
AI also lets us fail faster
There is something very valuable in all of this.
AI has drastically reduced the cost of testing an idea.
We can build a first version.
Put it in front of users.
Discover that we misunderstood the problem.
Throw away part of what we built.
And start again.
All much faster than before.
AI can help us fail fast.
And failing fast, when the goal is to learn, is a huge advantage.
The problem is not distinguishing between when we are experimenting and when we are building something that has to live in production.
A prototype can be full of temporary decisions.
It can repeat code.
It can have manual processes.
It can support ten users.
It can break and come back up.
That's fine.
Its goal is to answer a question.
Does this solve a real problem?
But when the answer is yes, a new question appears:
How do we build this so it can survive?
The mistake is assuming that because the prototype worked, the engineering work is already done.
Sometimes it is only just beginning.
The problem isn't vibe coding
The problem isn't building with AI.
We use AI to develop software, and it takes up more and more room in the way we work.
The problem appears when we confuse being able to generate an application with knowing how to build a system.
AI can write a retry.
It can add a cache.
It can create logs.
It can set up a queue.
It can propose an architecture.
But first someone has to understand why it needs a retry.
What it should cache.
What it needs to observe.
Where it can lose an event.
Which part of the system is going to change in six months.
You can't ask for a solution to a problem you don't know exists.
And many of the most important decisions in a system are precisely about problems that haven't happened yet.
"It works on my machine", now in the AI version
For years, developers have used this phrase almost as a joke:
"It works on my machine."
Today we may be building a new version of the same problem.
"It works in the demo."
The flow runs.
The interface looks good.
The data gets saved.
AI did in two days what used to take weeks.
Great.
Now comes the hard question:
What has to happen for this to keep working once it leaves the demo?
That is where a different kind of work begins.
Thinking about failures.
Thinking about load.
Thinking about change.
Thinking about security.
Thinking about operations.
In short, thinking about the system.
Generating code faster changes where the problem is
AI lowered the barrier to creating software.
And that is a good thing.
Today more people can turn an idea into an application.
Small teams can test solutions much faster.
A prototype can exist in days instead of months.
We can test more ideas.
Discard the bad ones sooner.
And make mistakes much more cheaply.
But lowering the barrier to writing code doesn't eliminate software engineering.
In fact, it can make it more important.
Because when generating code stops being the slow part, the bottleneck becomes judgment.
Knowing what to build.
Knowing what we are trying to learn.
Knowing when to throw away what we built.
Knowing what can fail.
And knowing when a prototype stopped being an experiment and became a system someone depends on.
AI can help you build practically any of those pieces.
It can also help you test an idea and quickly discover you were wrong.
That is part of its value.
But someone has to know which questions to ask.
Which risks to look at.
Which decisions can wait.
And which ones can't.
An application doing what you need is the first step.
Sometimes that is enough to learn from it and discard it.
Other times it is the beginning of something that has to be maintained, operated and grown for years.
Knowing how to tell one from the other is also software engineering.
And generating more code, even much faster, is no replacement for knowing how to design systems.
Marcos Reynoso
Founder – The41