Vibe coding: beautiful at launch, reliable in the long run?

A well-formulated prompt, a few exchanges with an AI agent, and a site can take shape in a few hours. The page is clean. The buttons work. The result sometimes gives the impression that a complex web project has become almost automatic.

It is a real step forward. But for a business, the right question is not just: "Does the site work today?" It is also: "Who will still know how to understand it, secure it, and evolve it tomorrow?"

The problem, therefore, is not 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, reformulate, correct, and move forward by 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 exploring an idea quickly and reducing time spent on certain repetitive tasks.

It can also help an experienced developer. In this case, the AI acts as an accelerator: the person using it knows how to check the architecture, spot an inconsistency, write tests, protect data, and take over 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 — have not 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 twenty products. At launch, the product pages are attractive and payment works. Then the client asks for something very normal: being able to modify a price, replace a photo, manage stock, or add a product from an administration area.

If the project was designed as a series of static pages, this trivial request suddenly becomes a major undertaking. The provider discovers they haven't planned a real data model or back-office. They have to patch together a new layer, redo part of the site, or explain to the client that they will have to go through them for every change.

This is not a problem of age, degree, or tool. It is 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 daily;
• where data is stored and how it is backed up;
• what happens if a payment, an import, or an email sending fails;
• how to fix a function without breaking another;
• how a second developer will be able to take over the project.

These questions are less spectacular than a successful animation. Yet, they are what determine if the site becomes a working tool or a fragile dependency.

The real test often comes after going live

A professional site lives. A campaign starts, an offer changes, a collaborator 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 notices that the new code breaks the mobile form or another page.

The business deadline is real, but no one knows how to properly locate the regression. The fix becomes a succession of trials. The client is no longer just paying for a modification: they are paying for the lack of mastery accumulated since the start.

This is where maintainability takes its full meaning. A maintainable site is not one that never encounters a bug. It is a site where the team can understand how it works, isolate a problem, test a fix, and deploy it with controlled risk.

What AI knows how to do 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 alone does not 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;
• used dependencies 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.

Secure development frameworks, such as NIST's, describe software quality as a set of practices spread across the entire life cycle: preparation, protection, production, and handling of vulnerabilities. Generating code is only part of this work.

Even studies on the productivity of AI tools invite nuance. Results depend on the context, the maturity of the project, 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 is therefore not "is AI fast?", but "who controls the quality of what it produces?".

Trained beginner and provider without mastery: they are not the same thing

A junior developer can make mistakes. A senior one too. The difference does not lie in an alleged perfection.

A trained person normally possesses benchmarks: separation of concerns, input control, access management, versioning, testing, logs, backups, documentation. Above all, they know that there are subjects they must deepen before delivery.

Conversely, someone can quickly obtain an impressive visual result without perceiving what is missing. The danger is not using AI or being self-taught. It is selling as "enterprise-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, it is not necessary to become a technical expert. A few concrete questions already allow you to distinguish a seductive demonstration from a truly prepared project.

1. "How will I modify my content?"

Ask for a demonstration of the back-office with your real use cases: modifying 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 must 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 accesses must be identified, transferable, and protected. Your activity 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 must be reserved for the correct roles.

5. "Are backups tested?"

A claimed backup is not necessarily a restorable backup. Ask about the frequency, storage location, retention period, and 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, the risks, the 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 intervene in your method?"

There is no shame in using AI. A transparent answer is preferable: initial generation, diagnostic aid, writing tests, documentation, or review. Above all, ask who validates the final result.

A proven stack does not replace bespoke: it makes it more reliable

At Cadarsir, projects do not start from a blank page improvised for every request. The stack has been built and proven for over six years, then enriched based on real needs: content administration, role management, maintenance, backups, business evolutions, and long-term monitoring.

This does not mean that all sites are identical or that no defects can occur. It means that the important foundations are known, documented, and mastered. The time saved doesn't come from ignoring architecture, but from reusing a understood architecture.

The goal is to offer SMEs a level of standard often associated with larger projects, without imposing a bloated system: a real administration space, functions designed for their business, and a contact person capable of evolving the site when a priority changes.

The right criterion is not "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 rather rest on three questions: do they understand what they are building, can they prove it, and will they still be able to intervene when your business has changed?

A successful site is not just beautiful on the day of delivery. It remains manageable, explainable, and scalable when the first real unforeseen request arrives.