Vibe Coding and AI: Working Software Is Not Always Governable Software

One of the deepest changes brought by AI is not only the speed at which developers can write code. It is who can now build something that works.

Today, a person with strong product vision, project management skills, architectural sensitivity, infrastructure knowledge or operational experience can use an AI assistant to turn an idea into a real platform. They may not know how to write code in the traditional sense. They may not know every detail of a framework. But they can describe a flow, reason about requirements, request iterations, evaluate an interface, connect APIs and imagine a product.

And with the right tools, they can obtain something that not only runs, but appears to work very well.

Working does not mean production ready

Software has always had this tension. Something can work on a laptop, in staging or during a sales demo, while still not being ready for real users, real data, real traffic, real incidents and real accountability.

AI amplifies that tension because it drastically lowers the cost of reaching the first working version. In a few hours, a person can generate a backend, a dashboard, an integration, a pipeline, an authentication system, a landing page, a payment workflow or a SaaS prototype. This is powerful. But it also makes it easier to skip the uncomfortable questions.

Where are the tests? How are secrets handled? What happens when an external service is unavailable? How do we roll back? Who monitors errors? Does logging expose sensitive data? Are dependencies up to date? Does the permission model actually hold? Can the database be migrated without losing data? Is the system understandable by someone other than the person who generated it?

Those questions do not disappear because the code was written by a model. They become more important, because the person guiding generation may not know all the failure modes a senior engineer has learned to look for.

The new software creator

The interesting figure is not only the developer who uses AI to move faster. It is also the technical product manager, the founder, the designer with system thinking, the infrastructure consultant, the architect who knows what they want to achieve but does not want to write every line of code.

These people can have a valuable quality: they see the problem. They understand the user flow, the business context, the product value, the organizational constraints and the operational impact. Until recently, they had to translate all of that into specifications for a development team. Today, they can enter the construction loop directly.

This is a massive change. It can unlock creativity, reduce friction, allow more people to prototype solutions and bring ideas to market that would previously have remained stuck. It would be short-sighted to see only the risk.

But precisely because it is powerful, it requires a new distinction: being able to guide AI toward producing software is not the same as being able to govern that software over time.

Vibe coding is changing senior developers too

The issue does not only concern people who cannot program. Many experienced developers are also changing how they work. With vibe coding, you describe the intent, let the model produce significant blocks of code, review selectively, test, correct and iterate.

In many cases, this works extremely well. A senior with good judgment can use AI to accelerate refactoring, boilerplate, tests, debugging, documentation, migrations and legacy code analysis. But there is a subtle drift: the more reliable the model appears, the less we truly inspect. The more the code "passes", the more tempting it becomes to trust it.

Senior competence may shift from knowing how to write code to knowing how to recognize when generated code is dangerous. That is a natural transition, but not a free one. If review becomes superficial, if tests are generated by the same model that wrote the code, if architecture grows by inertia, then we are not accelerating engineering. We are accelerating technical debt.

The future of software may not be shaped by people who cannot build. It may be shaped by people who can build too easily and realize too late what they have built.

What if AI is not there?

There is another point the industry tends to remove from the conversation: we are starting to build workflows assuming that AI is always available, always accessible, always affordable, always governed by the same policies and always capable enough to help us maintain the system.

But what happens if the service is unavailable for a few hours? Or for a few days? What happens if a provider changes model, policy, pricing or usage limits? What happens if an account is blocked, a feature is removed, a model becomes less permissive, or a commercial or regulatory decision suddenly changes the conditions?

We have already seen signals of this fragility in the AI ecosystem: models changing behavior, access being restricted, users suddenly losing a tool they had built part of their workflow around. The recent discussions around Claude Fable 5 are an example of how a change in availability or policy can shift habits and operational dependencies.

If a team can no longer critically read its own code without AI, cannot debug without an assistant, and cannot explain the architecture it generated, then it has not increased autonomy. It has only moved dependency elsewhere.

The internet analogy

We have already experienced a similar dynamic with the internet. At first it was an extension. Then it became invisible infrastructure. Today, many everyday objects assume that the network is available: smart homes, security systems, cameras, thermostats, locks, voice assistants, lights and appliances.

In many setups, when the internet goes down, the home becomes less smart or stops working as expected. And yet we keep buying cloud-dependent devices. Sometimes we even remove physical switches because "everything is smart now". We get used to convenience so quickly that the fallback plan starts to feel like a relic.

The question is whether we are doing the same thing with AI. First electricity. Then internet. Now assisted intelligence. Every new infrastructure becomes so natural that we stop seeing it. And when we stop seeing it, we also stop asking what happens if it is missing.

The fallback plan as maturity

In infrastructure, a fallback plan is not pessimism. It is engineering. Backups, disaster recovery, multi-region setups, rollback procedures, manual runbooks, monitoring and recovery tests all come from the awareness that systems fail.

We should reason the same way with AI. It is not enough to ask "how much time does it save today?". We also need to ask "what happens if it is not available tomorrow?". Can we maintain the product? Can we respond to an incident? Can we fix a vulnerability? Can we migrate? Can we explain to a customer why something happened?

An AI-generated platform should still have human-readable documentation, independent tests, clear ownership, understandable architecture, logging, security, dependency management and operational procedures. Not because AI is not useful. But because AI is so useful that it can make us forget discipline.

Three years to understand what really happened

We probably cannot answer the biggest question today. We will need a few years. Maybe three, maybe more. Enough time for developers, founders, companies and the whole industry to become used to AI as a natural part of daily work.

Only then will we see the real effects. We will see how many AI-born products are still maintainable. How many survive growth, incidents, audits, provider changes and team changes. We will see whether assisted generation created more sustainable software or more fragile software that simply looked convincing.

Today we are still in the phase of productive enthusiasm. Things are being built. Demos work. Founders ship faster. Senior developers accelerate. But software quality is not measured only at birth. It is measured when the system has to survive.

The luck of millennials

As a millennial, I often feel part of a strange and lucky generation. We lived enough of the analog world to remember what waiting meant, what boredom meant, what going out into the street meant, what calling from home meant, what missed calls meant, what SMS bundles meant, what buying videogame magazines meant. We saw 3D games become normal, then internet, smartphones, cloud and now AI.

In a little more than thirty years, we crossed an enormous number of technological transitions. We may be one of the last generations that can remember the before while building the after. That does not make us better. But it gives us a particular responsibility: we know that technology can be wonderful and invasive at the same time.

We have seen enough technological good and technological harm to avoid naivety. We know that every convenience has a cost, every automation changes habits, and every dependency feels harmless until it becomes infrastructure.

The question for our children

I often think about what awaits my daughter, my nephews, and the children growing up in a world where talking to a machine will feel as normal as turning on a television felt to us. What will happen to their critical thinking? Will they know how to say no? Will they distinguish between a solution and a shortcut? Will they demand a fallback plan?

The responsibility does not belong only to schools, governments or companies. It is also ours. Parents, engineers, founders, educators, adults building the world they will enter. We cannot simply give them more powerful tools. We also have to teach doubt, maintenance, limits, verification and patience.

Maybe the problem will not be that AI does everything for us. Maybe the problem will be that we become so used to being helped that we no longer understand when help becomes dependency.

Conclusion

The future ahead can be extraordinary. More people will be able to build, experiment, solve problems, create products, automate boring work and transform intuition into real tools. That is a huge form of progress.

But there is another possibility: a future in which many people believe they have solved a problem because the software starts, the interface looks good and the demo is convincing. Only years later will we discover whether that software was solid or whether we were preparing the ground for the next disaster.

The question remains open: are we moving toward a world where anyone can solve real problems, or toward a world where anyone can generate systems convincing enough to hide problems they can no longer see?