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 evolve 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 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 every other path.
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 what it suggests and integrate it into an architecture you understand. The difference isn't necessarily visible in a screenshot. It becomes visible 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 isn't just about getting something that stands upright. AI can significantly speed up the assembly. It doesn't remove the responsibility to check 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 what should have allowed them to be managed in the first place. It's not just a missing button: it's the way the site organises its 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 almost simultaneously, when a payment fails, or when a confirmation isn't sent, is a different job altogether. The problem appears exactly when the site starts being used.
The challenge 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 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 is looking for these errors and how they are corrected. GitHub's documentation on Copilot suggestions 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 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 bring you closer to the result, until the moment you no longer know what you changed to solve what.
Code history, tests, and a separate staging environment 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 mentions backups, a previous version, 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 access, 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 way the business operates. 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 work tool, ensure that someone will still be able to explain what is happening behind the screen when you need to change something other than 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 every other path.
The problem isn't working with AI
Vibe coding, in its common sense, involves 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 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 what it suggests and integrate it into an architecture you understand. The difference isn't necessarily visible in a screenshot. It becomes visible 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 isn't just about getting something that stands upright. AI can significantly speed up the assembly. It doesn't remove the responsibility to check 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 product, 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 what should have allowed them to be managed in the first place. It's not just a missing button: it's the way the site organises its 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 almost simultaneously, when a payment fails, or when a confirmation isn't sent, is a different job altogether. The problem appears exactly when the site starts being used.
The challenge 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 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 is looking for these errors and how they are corrected. GitHub's documentation on Copilot suggestions 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 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 bring you closer to the result, until the moment you no longer know what you changed to solve what.
Code history, tests, and a separate staging environment 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 mentions backups, a previous version, 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 access, 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 way the business operates. 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 work tool, ensure that someone will still be able to explain what is happening behind the screen when you need to change something other than the colour of a button.
