Vibe Coding as an Experienced Developer: Lessons

Vibe coding has gotten lots of attention lately, but it has been quite polarising. One camp claims it can make anyone a millionaire by helping them build their first SaaS. The other says it is ruining the ecosystem, creating buggy, messy, and unusable code. Some time has passed, and we now have more data on the real results of this trend. So I can safely say neither camp is right. But neither is 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.

Earlier AI code generation, like the auto-completions from GitHub Copilot, showed the model your code and had it finish small pieces, such as one function. Vibe coding usually gives AI much more control. You prompt the expected output rather than the exact code.

There is one more thing that defines vibe coding, and it is rarely mentioned: vibe coding is not AI writing code, it is AI taking developer decisions, designing and 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 is very hard to see the other side of the coin. Having AI write lots of code on its own serves two groups. First, people with no developer skills who learn fast and want to build an MVP. Second, developers who face new technical challenges, need someone to validate their approach, or just want a good base to modify. But it is also tough to navigate, because it takes away some of your control.

Vibe coding, but with (some) control

I talked to lots of people about AI-generated code lately. The number of experienced developers who build side projects or improve their skills with vibe coding is quite impressive. But that does not mean they all love it. The truth is, most people feel like they are giving in to chaos.

For many of us, fully generated projects might still be hacky prototypes, full of console logs, over-engineered spaghetti code, and security holes. 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. For now at least, I feel it is easier to treat it like Adaptive Cruise Control, where we still guide it and take over when needed, rather than full self-driving, where we are just passengers.

Tips and tricks for vibe coding

In my experience, a few best practices can make your vibe-coded features or projects a lot safer. They cover everything from code quality to having fewer fears around security.

• Know what you are building — it is crucial to define the feature-set very well and have a clear idea of the final product. You can still use an AI to generate a Product Requirements Document, but do that separately, then feed it to the coding AI.
• Think more like architects — we should design the structure of the application ourselves, using concepts we already know, best practices, and architectural patterns. This gives us control, and telling the AI how you want things structured usually yields much better code, like magic.
• Be a code reviewer — even before the age of AI, we read far more code than we wrote, and generated code only amplifies that. We debugged, reviewed, and searched for how others implemented certain features. Now we have to do that even more. The result of a vibe-coded feature is not just manual testing of the outcome, but also a thorough code review.
• Divide et impera — take things slowly, even if they seem simple. Split everything into smaller prompts. First develop, then write tests, or the other way around, but rarely together. If you need a feature that does some AI processing and exposes it via API, build the logic first and the API later. Bigger prompts with less information just raise 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 Retrieval Augmented Generation (RAG) as a concept, so it seemed like a great idea. It was rather hands-off and quick, and I still learned the general architecture and paradigms for a RAG project.

I only tested it locally, and 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 far better than before. It also had to pass a more rigorous review.

After going through this process, I want 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 above, they fell into just two 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. One of the biggest things it forgot was that it created these embeddings on every single run. I picked up on this rather quickly and prompted it to save the embeddings. This was my first rodeo with this type of project, so it was easier for me to spot issues with memory, performance, and API than with actual RAG concepts. Its fix was to save the embeddings in memory, which again was not 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 far 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 a third-party integration to a new account and a new API key. We were using the SDK rather than the API, but it did not cross my mind to mention that. After it could not find the API to change the authorization, it started rewriting the initialization to use the API, which was a huge overkill.

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

Some conclusions

I think vibe coding is a great tool in the right hands. If you are building a side project or an MVP, it can be a great tool, but you must apply everything you know about coding to get the best out of it. For bigger projects, especially production-ready ones with a team that contributes, I would treat AI-generated code as a powerful tool, but a lot more like another team member who writes code. You need to review it thoroughly and behave like an architect or technical lead. If you plan to vibe code a feature, it is much better than starting from scratch, especially if you structured the project well in the first place.

At Wolfpack Digital, we specialise in AI-native development and custom web development that balance cost-efficiency with high-quality results. In our 10 years of experience, we have shipped AI features and full products where senior engineers stay firmly in the loop.

Whether you need a simple business website or a complex AI-powered platform, we will help you build a powerful online presence. Need a custom quote? Contact us today to discuss your project.