Vibe Coding as an Experienced Developer - Lessons and Case Study

Vibe coding has gotten lots of attention lately, but it has been quite polarising. One camp of people is claiming to make anyone a millionaire by helping them build their first SaaS, while the other is saying that it’s ruining the ecosystem, creating buggy, messy, and unusable code. And because some time has passed and we have more information on the actual results of this trend, I can safely say neither of them is right. But neither are they wrong.

What is vibe coding?

Google Cloud documentation defines vibe coding like this:

Vibe coding is an emerging software development practice that uses artificial intelligence (AI) to generate functional code from natural language prompts.

Compared to previous forms of AI-generated code (like auto-completions from tools like Github Copilot), vibe coding usually refers to letting AI have lots more control, prompting the expected output, rather than showing it code and having it complete smaller elements (like one small function).

There is one more thing I think defines vibe coding and is never considered: vibe coding isn’t AI writing code, it’s AI taking developer decisions, designing/architecting implementations, connecting dots, and understanding requirements. It is coding guided by natural language, flow, and core concepts rather than strict mastery of the framework.

I think this is such a polarizing topic because it serves different purposes for different people, and it’s very hard to see the other side of the coin. Having AI write (lots of) code independently serves both people with no developer skills, who are fast learners and want to develop an MVP, but also developers who are navigating new technical challenges, need someone to validate their approach, or just want a good base that they can modify, in order to be more efficient. However, it also proves to be a tough thing to navigate, because it takes away some of the control you have.

Vibe coding, but with (some) control

I talked to lots of people about AI-generated code lately, and the amount of experienced developers who build side projects or improve their versatility using vibe-coding is quite impressive. But that doesn’t mean they all love it, and the truth is, most people feel like they are giving into chaos.

For many of us, projects with fully generated code might still be hacky prototypes, full of console logs, over-engineered spaghetti code, and security vulnerabilities. But with a bit of research and some coding knowledge, it can become something closer to structured improvisation. There are nuances to the way we vibe code, just like there are to autopilot. And for now at least, I feel like it’s easier for us to consider it more like Adaptive Cruise Control, where we are still needed to guide it and eventually take over, rather than full self-driving, where we are just passengers.

Tips & Tricks for vibe coding

In my experience, there are a few best practices that we can use that can make your vibe-coded features or projects a lot safer. These cover areas from the quality of code to having less fears regarding security.

• know what you’re building - it’s crucial to define the feature-set very well, and have a good idea about the final product; you can still use an AI to generate a Product Requirements Document, but make sure you do that separately, and then feed it to the coding AI
• think more like architects - we should be designing the structure of the application ourselves, using concepts we already know, best practices, architectural patterns; this will give us control, and you’ll see that telling the AI how you’d want things structured will also usually yield much better code, like magic 🪄
• be a code reviewer - even before the age of AI, we used to read a lot more code than we were writing, and generated code only amplifies that; we were debugging, reviewing, searching for how other people implemented certain features, and so on; now, we have to do that even more, and the result of a vibe-coded features isn’t just manually testing the outcome, but also reviewing the code thoroughly
• divide et impera - take things slowly, even if they seem very straight forward to you; try to split everything into smaller prompts, first developing, then writing tests (or the other way around, but rarely together), if you need a feature that does some AI processing and exposing it via API, try to build the logic first and the API later, and so on; bigger prompts, with less information, just increase the chance of hallucinations

Case Study - Coming back months later

A few months ago, I vibe-coded a side project. I wanted to learn how to implement a Retrieval Augmented Generation as a concept, so it seemed like a great idea. It was rather hands-off, quick, and I still learnt the general architecture and paradigms for a RAG project.

I only tested it locally; it went fine, but a few months later, we wanted to promote the project and use it internally, at Wolfpack Digital. Suddenly, it needed to be maintainable, deployable, and work a lot better than it used to. Besides that, it had to go through a more rigorous review.

After going through this process, I wanted to share some learnings with you.

What the AI got wrong

The project definitely worked overall, but it still had some misses. Luckily for me, because I applied most of the tips mentioned above, they were only part of 2 categories: either complete over-engineering or extreme over-simplifying.

For an over-simplification example, my project needed to create embeddings from a dataset of multiple CSV files that we made available. One of the biggest things it forgot to do was that it created these embeddings every single run. I picked up on this rather quickly, prompting it to find a way to save the embeddings. Mind you, this was my first rodeo with this type of project, so it was easier for me to find issues with memory, performance, API, instead of actual RAG concepts. Its fix was to save the embeddings in memory, which again wasn’t the best way. It worked locally, but we had to add a vector database as soon as possible.

For over-engineering examples, these are less specific, but can be found a lot more often. I noticed that whenever you ask for a simple fix for a failing test or a weird bug, it has a small meltdown and starts refactoring. For example, I needed to migrate the implementation of a 3rd party integration to a new account, new API key, and so on. We were using the SDK rather than the API, but it didn’t cross my mind to mention that. After not finding the API to change the authorization, it started rewriting the initialization through the SDK to use the API, which was a huge overkill.

But my overall experience was very good. I took things step by step, helped it structurally, and the overall quality of the code was good, the outcome worked well, and the actual refactoring or review was minimal.

Some conclusions

I think that vibe-coding is a great tool when in the right hands. If you’re building a side-project or an MVP, it can be a great tool, but it’s important to apply everything you know coding-wise to make the best out of it. For bigger projects, especially production-ready, where there is a team that contributes, I’d consider AI-generated code a powerful tool, but a lot more similar to just another team member who writes code, and you need to thoroughly review it and behave like an architect/technical lead with it. If you plan to vibe code a feature, it is much better than starting from scratch, especially if you did a great job structuring the project in the first place.

At Wolfpack Digital, we specialize in custom web development that balances cost-efficiency with high-quality results. Here, you can see the web development projects we delivered in our 10 years of experience.

Whether you need a simple business website or a complex platform, we’ll help you build a powerful online presence.

Need a custom quote? Contact us today to discuss your web development needs!