Vibe coding: beautiful at launch, but reliable in the long run?
An AI-generated website looks great at launch, but can you manage it? Learn how to ensure your site remains secure, scalable, and easy to update long-term.
Sur cette page6 sections
You describe an idea, ask for a menu, a login page, and two or three features, and a few exchanges later you already have something to show. Not long ago, this first version would have required much more work. Today, it can arrive quickly enough to make you want to jump straight to the next steps: the domain name, going live, and your first customers.
I completely understand the appeal. Being able to test an idea without spending weeks building it is valuable. Where I draw the line is when software is considered ready just because the demo is convincing. A demo shows that the intended path works. A business will take all the others.
This is not the same as developing with the help of an AI while maintaining control over the project. You can have it produce an interface, ask it for an explanation, or prepare tests, then review its suggestions and integrate them into an architecture you understand. The difference isn't necessarily visible in a screenshot. It shows when you need to intervene.
It's a bit like assembling furniture: following instructions, checking the fasteners, and knowing why a specific part bears the weight is more than just making something that stands upright. AI can speed up assembly tremendously. It doesn't remove the responsibility of checking the structural integrity before placing your business on top of it.
If these needs were planned for, they open their admin panel and do it. If the products were hard-coded to save time, you now have to build the system that should have managed them in the first place. It's not just a missing button: the entire way the site organises information needs to be reworked.
We see the same issue with bookings. Displaying an available slot is easy to demonstrate. Knowing what happens when two people choose it almost simultaneously, when a payment fails, or when a confirmation email isn't sent, is a different job altogether. The problem appears exactly when the site starts being used.
The goal isn't to have predicted everything, which would be impossible. It's to build a foundation that allows these situations to be handled without breaking what was working the day before.
The server must verify that your account has the right to access that invoice with every request. Hiding a button in the interface isn't enough to prevent an operation either. These checks aren't flashy, but they are as much a part of the product as its colours or menu.
This isn't a weakness exclusive to generated code: a developer can also make mistakes. The question is who looks for these errors and how they are fixed. GitHub's own documentation on Copilot suggestions reminds us that proposed code must be reviewed and tested. A well-presented answer is not a technical validation.
On a project that no one masters, you might find yourself asking the AI for a fix, noticing that another screen no longer works, then asking for a fix for the fix. Each attempt seems to get you closer to the result, until you no longer know what you changed to solve what.
Code history, testing, and an environment separate from production serve precisely to avoid this situation. They allow for comparison, reproduction, and reverting to a known version. Website maintenance begins with this ability to intervene without gambling on the client's requests.
Then ask a less comfortable question: "If an update breaks this function, how do we recover?" A useful answer mentions backups, previous versions, checks, and a human contact. Not just the possibility of asking the AI again.
Also ask what another developer would inherit if you changed providers: code, documentation, data, hosting, and domain access. A project that can only be taken over by the person who remembers their conversations with the AI makes you dependent on a memory, not just a skill.
At Cadarsir, custom-built doesn't mean reinventing the foundations for every project. We rely on a known base to adapt the site to the business's operations. AI can help in this work; it doesn't decide for us what is reliable enough to be delivered.
A quick first version can be an excellent start. But before making it your primary business tool, ensure that someone will still be able to explain what is happening behind the screen when you need to change more than just the colour of a button.
I completely understand the appeal. Being able to test an idea without spending weeks building it is valuable. Where I draw the line is when software is considered ready just because the demo is convincing. A demo shows that the intended path works. A business will take all the others.
The problem isn't working with AI
In its common sense, 'vibe coding' consists of describing what you want to an AI and moving the project forward by focusing mainly on the result. You ask for a change, you test, you rephrase. Depending on the workflow, you can end up with a lot of code whose inner workings haven't really been studied.This is not the same as developing with the help of an AI while maintaining control over the project. You can have it produce an interface, ask it for an explanation, or prepare tests, then review its suggestions and integrate them into an architecture you understand. The difference isn't necessarily visible in a screenshot. It shows when you need to intervene.
It's a bit like assembling furniture: following instructions, checking the fasteners, and knowing why a specific part bears the weight is more than just making something that stands upright. AI can speed up assembly tremendously. It doesn't remove the responsibility of checking the structural integrity before placing your business on top of it.
The day after launch, someone wants to change a price
Take a small online shop. Twenty products, beautiful photos, a working cart. So far, so good. Then the shopkeeper wants to change a price, hide an out-of-stock item, and add a new reference without calling their service provider.If these needs were planned for, they open their admin panel and do it. If the products were hard-coded to save time, you now have to build the system that should have managed them in the first place. It's not just a missing button: the entire way the site organises information needs to be reworked.
We see the same issue with bookings. Displaying an available slot is easy to demonstrate. Knowing what happens when two people choose it almost simultaneously, when a payment fails, or when a confirmation email isn't sent, is a different job altogether. The problem appears exactly when the site starts being used.
The goal isn't to have predicted everything, which would be impossible. It's to build a foundation that allows these situations to be handled without breaking what was working the day before.
A login screen isn't enough to protect data
A page asking for a password easily gives an impression of security. But imagine you are viewing your invoice and its URL contains a number. If changing that number allows you to see another customer's invoice, the login page hasn't solved the real problem.The server must verify that your account has the right to access that invoice with every request. Hiding a button in the interface isn't enough to prevent an operation either. These checks aren't flashy, but they are as much a part of the product as its colours or menu.
This isn't a weakness exclusive to generated code: a developer can also make mistakes. The question is who looks for these errors and how they are fixed. GitHub's own documentation on Copilot suggestions reminds us that proposed code must be reviewed and tested. A well-presented answer is not a technical validation.
The first urgent modification tells a story
Your campaign starts tomorrow. You need to change a form and send requests to a new tool. On a project that is understood, you identify the relevant parts, prepare the modification, and check the functions that might be affected.On a project that no one masters, you might find yourself asking the AI for a fix, noticing that another screen no longer works, then asking for a fix for the fix. Each attempt seems to get you closer to the result, until you no longer know what you changed to solve what.
Code history, testing, and an environment separate from production serve precisely to avoid this situation. They allow for comparison, reproduction, and reverting to a known version. Website maintenance begins with this ability to intervene without gambling on the client's requests.
Ask to see something other than the homepage
You don't need to read code to choose a service provider. However, you can ask them to show you how you will add a product, what a team member can edit, and how a request will be found in the admin panel.Then ask a less comfortable question: "If an update breaks this function, how do we recover?" A useful answer mentions backups, previous versions, checks, and a human contact. Not just the possibility of asking the AI again.
Also ask what another developer would inherit if you changed providers: code, documentation, data, hosting, and domain access. A project that can only be taken over by the person who remembers their conversations with the AI makes you dependent on a memory, not just a skill.
Going faster, yes, but to get where?
I see no point in refusing a tool that can speed up work. What interests me is what we do with the time saved: better checking the user journey, taking the time to understand the need, or making the admin panel truly usable.At Cadarsir, custom-built doesn't mean reinventing the foundations for every project. We rely on a known base to adapt the site to the business's operations. AI can help in this work; it doesn't decide for us what is reliable enough to be delivered.
A quick first version can be an excellent start. But before making it your primary business tool, ensure that someone will still be able to explain what is happening behind the screen when you need to change more than just the colour of a button.
