One of the major promises of AI today is clear: to enable the creation of applications and software tools without writing a single line of code yourself.

Whether we're talking about web development, PC development, or other platforms, the idea is appealing: control an AI, entrust it with code generation, and obtain a turnkey application. This is precisely what is now called AI. Vibe Coding.

So I wanted to test this promise in the field.

Especially since the subject directly concerns me. After a whole professional life spent in software development, I wanted to confront myself with a deliberately uncomfortable situation: having an application developed in an environment that I do not technically master.

I chose the web, with a concrete objective: to design a viewer capable of displaying very large images, beyond one gigapixel. This choice was not theoretical: I happened to have such an image, produced piece by piece.

My approach was simple: let AI code for me, while refusing to get my hands dirty with HTML, CSS, JavaScript and the associated ecosystem. Not out of disinterest, but because I know clearly that it is neither my world nor my area of expertise.

So I went into the experiment with a very clear division of roles.

My role:

• Analyze,
• To guide the project,
• Test,
• To validate.

The role of AI:

• Coding,
• To correct,
• Auditing your own code,
• To suggest avenues for improvement.

On paper, the scheme seems remarkably effective. In reality, the feedback from the field is much more nuanced. To date, I have far exceeded the 1,000 iterations to arrive at a viewer for very large images. I'm not talking about a basic prototype, a "Proof of Concept" or POC, obtained in a few attempts, but a truly usable tool, with user-friendly ergonomics and relatively simple operation. However, in this endeavor, one observation became clear to me: I spend approximately 80% of my time (%) dealing with bugs and coding deviations..

That's huge.

And this is even more true when coming from a development culture based on robustness, architectural consistency, and regression control.

Faced with such a high proportion of losses, it becomes essential to question several things:

• His own choices,
• His methodology,
• And, of course, the AI tool itself.

However, I doubt that a change of tool would have fundamentally altered the findings. At this stage, I tend to think that, for the most part, large AI models (LLMs) share the same strengths… and the same limitations. Differences exist, of course, but they seem to me to be more a matter of nuance than a radical upheaval of the results.

My own process probably needs some review. But it's based on years of experience as a software engineer, product architect, and application designer. I know the pitfalls of the job. I also know the importance of methodology.

That's why I've come to think that the main difficulty doesn't just come from the project, but from the gradual drifts that the AI coding tool tends to introduce.

Among them, I see at least two very concrete ones.

The first one: the erosion of instructions.
Even when AI is given a detailed role, a strict framework and precise guidelines, it is observed that over iterations these instructions become loosened, diluted, or even disappear completely.

The second: local correction at the expense of the overall vision.
When a bug is reported, the AI very often tries to fix it as closely as possible, without taking a broader view. It applies a one-off fix where it might sometimes need to re-examine a wider area of the system.

And that's probably where the real cost lies.

The problem isn't so much the time the AI takes to "think" before proposing a solution. The real problem is that it tends to pile on fixes like plasters on a wound, without any real capacity for structural self-repair.

After a while, you end up with patchwork solutions, and overall consistency starts to break down. The hardest part is that this drift isn't always immediately visible. It's often noticed too late, when the truly usable versions become rarer, more fragile, and more expensive to stabilize.

And it is at this level that the exercise becomes challenging. Because it then takes a lot of tenacity not to give up halfway through, at a moment when you clearly perceive the effort required... without always seeing the finish line clearly.

My conclusion, at this stage, is as follows:
Yes, Vibe Coding works. Yes, it's possible to develop an application without writing a single line of code yourself. But, as things stand, AI doesn't have enough self-critical ability to be autonomous in its writing process. This approach still requires a lot of dedication, perspective… and a real understanding of the developer's role.

In other words: We can delegate the code, but not yet totally the requirement for design, management and control.

Of course, I don't claim to possess a universal truth. Others certainly achieve much better results, with different approaches, tools, or disciplines.

I would therefore be very interested and curious to hear your feedback:
In your opinion, what are the best practices that allow us to get the most out of Vibe Coding today without suffering its downsides?