Vibe coding: looks good at launch, but is it reliable long-term?
Vibe coding speeds up site creation, but who controls security, the back-office, and maintenance? Discover the key questions to ask before choosing a developer.
Sur cette page8 sections
A well-phrased prompt, a few exchanges with an AI agent, and a website can take shape in a few hours. The page looks clean. The buttons work. The result sometimes gives the impression that a complex web project has become almost automatic.
This is a real step forward. But for a business, the right question isn't just: "Does the site work today?" It's also: "Who will still be able to understand, secure, and evolve it tomorrow?"
The problem, therefore, isn't artificial intelligence. The risk appears when generation speed is confused with mastery of the delivered product.
For a mockup, an internal prototype, or a temporary tool, this approach can be very useful. It allows for quick exploration of an idea and reduces time spent on repetitive tasks.
It can also help an experienced developer. In this case, AI acts as an accelerator: the person using it knows how to check the architecture, spot an inconsistency, write tests, protect data, and take back control when the generation goes astray.
The situation is different when no one really understands what has been built. The site may then seem finished even though the most important choices — access rights, backups, data structure, scalability — haven't been thought through.
Take an e-commerce site with about twenty products. At launch, the product pages are nice and the payment system works. Then the client asks for something very normal: to be able to change a price, replace a photo, manage stock, or add a product from an administration area.
If the project was designed as a series of frozen pages, this mundane request suddenly becomes a major undertaking. The provider discovers they haven't planned for a real data model or a back-office. They have to cobble together a new layer, redo part of the site, or explain to the client that they'll have to go through them for every single change.
This isn't a problem of age, degree, or tool. It's a problem of business anticipation.
A professional developer doesn't just think about the visible page. They also ask:
Imagine a Google Ads campaign already scheduled. At the last minute, you need to adapt a landing page, change a form, and add conversion tracking. The provider opens the project, asks the AI to modify what it had generated, then finds that the new code breaks the mobile form or another page.
The commercial deadline is real, but no one knows how to properly locate the regression. The fix becomes a series of trials. The client is no longer just paying for a modification: they are paying for the lack of mastery accumulated from the start.
This is where maintainability takes on its full meaning. A maintainable site isn't a site that never encounters a bug. It's a site where the team can understand how it works, isolate a problem, test a fix, and deploy it with controlled risk.
But a generated response does not, on its own, provide proof that:
Even studies on the productivity of AI tools suggest nuance. Results depend on context, project maturity, user experience, and the task. On existing and complex code, a tool can speed up certain steps while adding verification or rework time. The right question, therefore, isn't "is AI fast?", but "who controls the quality of what it produces?".
A trained person normally has benchmarks: separation of concerns, input control, access management, versioning, testing, logs, backups, documentation. Above all, they know there are subjects they must delve into before delivering.
Conversely, someone can quickly get an impressive visual result without perceiving what's missing. The danger isn't using AI or being self-taught. It's selling as "business-ready" a product that no one knows how to audit, explain, or maintain.
This doesn't mean all sites are identical or that no flaws can occur. It means the important foundations are known, documented, and mastered. The time saved doesn't come from ignoring architecture, but from reusing an architecture that is understood.
The goal is to offer small and medium-sized businesses a level of requirement often associated with larger projects, without imposing an over-engineered system: a real administration space, functions designed for their activity, and a contact person capable of evolving the site when a priority changes.
The choice of a provider should instead rest on three questions: do they understand what they are building, can they prove it, and will they still be able to step in when your business has changed?
A successful site isn't just beautiful on the day of delivery. It remains manageable, explainable, and scalable when the first real unforeseen request arrives.
This is a real step forward. But for a business, the right question isn't just: "Does the site work today?" It's also: "Who will still be able to understand, secure, and evolve it tomorrow?"
The problem, therefore, isn't artificial intelligence. The risk appears when generation speed is confused with mastery of the delivered product.
What exactly is vibe coding?
The term refers to a way of creating software by describing the expected result to an AI, then letting it produce a large part of the code. You test, rephrase, correct, and move forward through iterations, sometimes without reading or understanding every line generated.For a mockup, an internal prototype, or a temporary tool, this approach can be very useful. It allows for quick exploration of an idea and reduces time spent on repetitive tasks.
It can also help an experienced developer. In this case, AI acts as an accelerator: the person using it knows how to check the architecture, spot an inconsistency, write tests, protect data, and take back control when the generation goes astray.
The situation is different when no one really understands what has been built. The site may then seem finished even though the most important choices — access rights, backups, data structure, scalability — haven't been thought through.
A beautiful facade doesn't tell you how the site is built
A visitor sees an interface. A business, however, depends on everything behind it.Take an e-commerce site with about twenty products. At launch, the product pages are nice and the payment system works. Then the client asks for something very normal: to be able to change a price, replace a photo, manage stock, or add a product from an administration area.
If the project was designed as a series of frozen pages, this mundane request suddenly becomes a major undertaking. The provider discovers they haven't planned for a real data model or a back-office. They have to cobble together a new layer, redo part of the site, or explain to the client that they'll have to go through them for every single change.
This isn't a problem of age, degree, or tool. It's a problem of business anticipation.
A professional developer doesn't just think about the visible page. They also ask:
- who has the right to view, modify, or delete information;
- how content will be managed on a daily basis;
- where data is stored and how it is backed up;
- what happens if a payment, import, or email fails;
- how to fix one function without breaking another;
- how a second developer could take over the project.
The real test often comes after going live
A professional site is alive. A campaign starts, an offer changes, an employee leaves the company, a regulatory obligation evolves, or an external integration changes its operation.Imagine a Google Ads campaign already scheduled. At the last minute, you need to adapt a landing page, change a form, and add conversion tracking. The provider opens the project, asks the AI to modify what it had generated, then finds that the new code breaks the mobile form or another page.
The commercial deadline is real, but no one knows how to properly locate the regression. The fix becomes a series of trials. The client is no longer just paying for a modification: they are paying for the lack of mastery accumulated from the start.
This is where maintainability takes on its full meaning. A maintainable site isn't a site that never encounters a bug. It's a site where the team can understand how it works, isolate a problem, test a fix, and deploy it with controlled risk.
What AI does very well — and what it doesn't guarantee
AI agents are already capable of producing interfaces, explaining code, proposing tests, generating a project base, or suggesting a fix. In the right hands, they can save precious time.But a generated response does not, on its own, provide proof that:
- permissions are correctly separated between an administrator, an employee, and a client;
- sensitive data is protected;
- backups exist and can actually be restored;
- the dependencies used will be maintained;
- the project handles the expected load;
- errors are monitored;
- technical choices are documented;
- the next evolution can be added without rebuilding everything.
Even studies on the productivity of AI tools suggest nuance. Results depend on context, project maturity, user experience, and the task. On existing and complex code, a tool can speed up certain steps while adding verification or rework time. The right question, therefore, isn't "is AI fast?", but "who controls the quality of what it produces?".
Trained beginner vs. provider without mastery: they are not the same
A junior developer can make mistakes. A senior can too. The difference isn't down to supposed perfection.A trained person normally has benchmarks: separation of concerns, input control, access management, versioning, testing, logs, backups, documentation. Above all, they know there are subjects they must delve into before delivering.
Conversely, someone can quickly get an impressive visual result without perceiving what's missing. The danger isn't using AI or being self-taught. It's selling as "business-ready" a product that no one knows how to audit, explain, or maintain.
How to recognise a provider capable of maintaining what they deliver
Before choosing a provider, you don't need to become a technical expert. A few concrete questions can already distinguish a seductive demo from a truly prepared project.1. "How will I edit my content?"
Ask for a demonstration of the back-office with your real-world cases: editing a listing, adding a user, correcting a price, replacing an image, or viewing a customer request.2. "What happens if a modification breaks something?"
The provider should be able to explain their process: test environment, versioning, backup before intervention, verification, and rollback.3. "Who owns the domain name, hosting, accounts, and data?"
Important access must be identified, transferable, and protected. Your business should not depend on an inaccessible personal account.4. "How are access rights managed?"
A content editor should not automatically have the same powers as an administrator. Sensitive functions should be reserved for the correct roles.5. "Are backups tested?"
A promised backup isn't necessarily a restorable backup. Ask about frequency, storage location, retention period, and the restoration procedure.6. "How would another developer take over the project?"
Documentation, code repository, change history, conventions, and deployment procedures are good signals. The answer "we'll just ask the AI again" is not one.7. "How do you estimate an urgent evolution?"
A professional must be able to identify the affected areas, risks, necessary tests, and a realistic timeframe. They can say a request is complex; they must be able to explain why.8. "Where does artificial intelligence fit into your method?"
There's no shame in using AI. A transparent answer is preferable: initial generation, diagnostic help, writing tests, documentation, or review. Above all, ask who validates the final result.A proven stack doesn't replace custom-built: it makes it more reliable
At Cadarsir, projects don't start from an improvised blank page for every request. The stack has been built and tested for over six years, then enriched through real needs: content administration, role management, maintenance, backups, business evolutions, and long-term support.This doesn't mean all sites are identical or that no flaws can occur. It means the important foundations are known, documented, and mastered. The time saved doesn't come from ignoring architecture, but from reusing an architecture that is understood.
The goal is to offer small and medium-sized businesses a level of requirement often associated with larger projects, without imposing an over-engineered system: a real administration space, functions designed for their activity, and a contact person capable of evolving the site when a priority changes.
The right criterion isn't "with or without AI"
Pitting developers against artificial intelligence would be a mistake. Good professionals already use many tools to work faster and better. AI is one of them.The choice of a provider should instead rest on three questions: do they understand what they are building, can they prove it, and will they still be able to step in when your business has changed?
A successful site isn't just beautiful on the day of delivery. It remains manageable, explainable, and scalable when the first real unforeseen request arrives.
