Vibe coding: looks great at launch, but is it reliable long-term?
An AI-generated site can look great at launch. Discover what to check to ensure you can manage, secure, and scale it effectively over the 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 so long ago, this first version would have required much more work. Today, it can arrive quickly enough to make you want to skip 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 every other path.
This is not the same as developing with the help of AI while maintaining control over the project. You can have it produce an interface, ask 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 step in.
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 getting something to stand upright. AI can speed up assembly tremendously. It doesn't remove the responsibility to check the structural integrity before building your business on top of it.
If these needs were anticipated, 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 allowed them to be managed. This isn't just a missing button: it's the way the site organises information that 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 at almost the same time, when a payment fails, or when a confirmation isn't sent, is a different job. The problem appears exactly when the site starts being used.
The challenge isn't to have anticipated everything, which would be impossible. It's to build a foundation that allows these situations to be handled without breaking what worked 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 spectacular, but they are as much a part of the product as its colours or its 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 corrected. GitHub's documentation on Copilot suggestions itself reminds us that suggested code must be reviewed and tested. A well-presented answer is not a technical validation.
On a project that no one masters, you can end up 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 bring you closer to the result, until you no longer know what you changed to solve what.
Code history, tests, 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 with the client's requests.
Then ask a less comfortable question: "If an update breaks this feature, how do we recover?" A useful answer talks about backups, previous versions, checks, and a point of contact. Not just the possibility of asking the AI again.
Also ask what another developer would inherit if you changed providers: code, documentation, data, access to hosting and the domain. 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, bespoke 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, check that someone will still be able to explain what's happening behind the screen when you need to change something more than just a button colour.
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 every other path.
The problem isn't working with AI
Vibe coding, in its common sense, consists of describing what you want to an AI and moving the project forward by focusing primarily 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 AI while maintaining control over the project. You can have it produce an interface, ask 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 step in.
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 getting something to stand upright. AI can speed up assembly tremendously. It doesn't remove the responsibility to check the structural integrity before building 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 anticipated, 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 allowed them to be managed. This isn't just a missing button: it's the way the site organises information that 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 at almost the same time, when a payment fails, or when a confirmation isn't sent, is a different job. The problem appears exactly when the site starts being used.
The challenge isn't to have anticipated everything, which would be impossible. It's to build a foundation that allows these situations to be handled without breaking what worked 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 spectacular, but they are as much a part of the product as its colours or its 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 corrected. GitHub's documentation on Copilot suggestions itself reminds us that suggested 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 could be affected.On a project that no one masters, you can end up 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 bring you closer to the result, until you no longer know what you changed to solve what.
Code history, tests, 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 with 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 modify, and how a request will be found in the admin panel.Then ask a less comfortable question: "If an update breaks this feature, how do we recover?" A useful answer talks about backups, previous versions, checks, and a point of contact. Not just the possibility of asking the AI again.
Also ask what another developer would inherit if you changed providers: code, documentation, data, access to hosting and the domain. 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, bespoke 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, check that someone will still be able to explain what's happening behind the screen when you need to change something more than just a button colour.
