Blog > My experience with Vibe-coding

I've been vibe-coding for a few months now, testing it on personal projects and small maintenance tasks for third-party clients. I mainly wrote projects in Next.js using databases like MySQL or Mongo, and I also took the opportunity to quickly finish some games I had set out to develop using HTML5 Canvas.  

Now, I need to evaluate vibe-coding based on my own knowledge. Since I am an old‑school programmer (if the term "old" can already be used), I certainly had less difficulty putting together a reliable project. But let's look at the limitations I noticed and had to pay enormous attention to.

I start from the assumption that first of all I took the trouble to assign a good set of rules, complete with linter and type-checking errors, and I also forced the agent to evaluate and potentially reuse shared elements (to componentize) to avoid redundancies. This is because, otherwise, the system wouldn't do it, and you would end up with a sea of redundancies and exceptions. Just imagine that if you're not already aware of certain optimization practices, you're already condemning the project to a mess since the very beginning.

Security is another major blind spot. For example, while developing a simple blog, the agent inserted API keys directly into the frontend code, without using any server-side middleware, essentially exposing them to the whole world. That's something I had to catch and fix myself — but a less experienced person wouldn't even know they should look for it.

In general, I got along quite well with vibe-coding because it significantly sped up the writing of traditionally boring and mathematical algorithms — things that would have taken me much longer to code manually. That part was a real time-saver. The caveat, however, is that this holds true except for architecture and security, where the agent is completely unreliable. I had to pay a lot of attention to the code design, because the agent tends to operate in the 'here and now' and has no vision of the possible future, which in reality exists only in your head and in the client's head (maybe). I also noticed that the process is extremely heavy, and I often found myself with completely exhausted memory.

In video game development, vibe-coding gave me a great hand, but since I work with HTML5 to develop mobile games, I necessarily have to pay attention to things that might seem obvious. The performance of HTML5 on a mobile device is not that of a project written in the optimal language specifically for that device; instead, it's a solution that requires very tight attention, especially oriented toward performance.

What do I mean by that? I mean that if I'm developing a game in HTML5, there's a high chance that it might suffer from lagging on a mobile device. And if I simply ask the agent to develop a certain behavior for me, it has absolutely no idea what the purpose of your game is, nor would it bother to manage potential bottlenecks. There have been cases where I had to specify very precisely the optimal culling technique for that specific purpose or environment, or to use a state manager instead of the string of if-else statements it kept giving me throughout the game code.

In this sense, video game development — which is very sensitive to performance-related issues — gave me a better insight into the limitations and possibilities of vibe-coding.

What are the things that worry me the most? Certainly the fact of losing sight of the code and completely abandoning oneself to the machine's responsibility — not due to the programmer's irresponsibility, but because of a logic that is slowly infiltrating companies, pushing for increasingly faster development (obviously, due to competition) and preventing the programmer from keeping a live eye on the written code. We risk ending up with a sea of working code (or not working code) that we have absolutely no understanding of.

So to sum up, I got along well with vibe-coding, but the bottleneck often appears in performance and foresight, because the techniques for solving one or the other depend on numerous factors that may be unknown or unspecified, and must be chosen based on the product's potential. And that's where the professional's clinical eye comes into play.

What I ask myself is: will theoretical knowledge alone be enough? Or will the machine ask us the right questions?

To be clear: I would never entrust a real project to vibe coding alone. And companies — all companies — should understand that it's still worth taking the time. Cutting corners on architecture, security, and maintainability might look faster in the short term, but in the long run, it's a debt that always comes due.