My vibe coding experience

I never expected to be the guy defending AI-assisted coding. People know me as the purist UNIX person who configures everything by hand, controls every part of my stack, and doesn’t let anything touch my code unless I understand it line by line and, honestly, that’s still true. But at the same time, I’m an engineer who wants to build things faster and spend more time on the work that actually matters: setting direction, defining strategy, designing good architecture, and writing meaningful business logic.

I am not going to lie, I was hugely skeptical about this “code writes code” tendency. I was completely opposed to it at work and, to some extent, I still am. But after using it myself, I can see the power of it, what it enables me to do, as well as the dangers of letting it run wild or misusing it.

My turning point

I was completely against using agents to write code until June 2025, when BCG, the company I was working for, organized a 4-day GenAI training focused on Software Engineers. It covered basic Cursor usage and a basic development workflow while building a software solution for an imaginary client.

I left that training feeling a lot better about using AI to generate code. It is a good practice as long as good practices are followed and the code is audited. If you prompt it, you own it and you are accountable for it.

During the training, we generated a fully working prototype of a software solution in 2 days after attending all the workshops and technical sessions. This is faster than I’ve ever built anything, but there were some flaws in the flow. As it was taught, it wasn’t suitable for building production-worthy software. The iterations were too big and the prompts too lengthy for the agents to produce accurate code. However, it had good components overall, it focused on getting the requirements crystal clear so that we could give precise instructions to the model.

What I did in the training

In the GenAI training I did with BCG, we got a list of requirements from a fictional client and we input it into ChatGPT to produce a Product Requirements Document and, from it, derive an implementation plan using ChatGPT as well. Then we used that implementation plan as an input for Cursor to start writing the code.

There were multiple problems with this:

• The input was too large, so the agent lost focus and made quite a few rookie mistakes a Junior developer wouldn’t have made.
• The output was too large to review and adjust, so instead of reviewing the code myself, as we only had ~2 days to complete the exercise, I ended up asking the agent to fix the errors as they appeared by indicating the error message.

This is not a very efficient nor ethical workflow. I was prompting the model and just accepting the output. If the output didn’t work, I just asked the agent to regenerate based on basic indications. It completely removed me from the code, so I didn’t know what the agent was writing; I only knew if it worked or failed based on my interactions with the generated application.

My workflow when working with agents

I liked the idea of using very detailed inputs for the agents. Not only detailed, but also structured inputs. I also liked the “plan first, execute later” approach. Gaining clarity in the requirements and the action plan is something I always do to some extent before writing the first line of code anyway. The agent will write the code, but it will not analyze and understand the requirements for me.

Once I have a good understanding of what needs to be done, I break the requirements into features, either by myself or using something like ChatGPT. The idea is to break the project at hand into smaller pieces that build on top of each other or constitute functional iterations.

I then focus on planning with the agent. I give a set of clear and well-defined requirements. These requirements are atomic in the sense that they will either produce one layer of a functioning feature or a small part of the application. I ask Cursor (I normally use Claude) to produce an implementation plan, which I carefully review and adjust wherever needed by asking Claude to add or remove stuff depending on what I want to achieve.

Once I’m happy with the plan, if it looks too long, I break it into phases by prompting the model to do so. The phases should build on top of each other, and I start executing each phase one by one, reviewing the code and adjusting manually wherever needed.

This way I can easily review and audit the code that is coming out of the agents, making sure it works while also making myself familiar with it in case I have to roll up my sleeves and make manual modifications or optimize certain parts, it’s easier to review a few hundred lines of code from one of the implementation phases rather than reviewing tens of thousands from the output of a full PRD.

What I’ve learned so far

There are two things to keep in mind when working with agents:

1. When the codebase is small, keep the prompts concise but very explanatory. Don’t add unnecessary fluff to the prompts; keep the content focused on the objective.
2. As the code grows, playing with the context starts being more important, so you also need to make sure to add the important files or folders into the context to make sure the agent is focused on the right parts of the code.

It’s a craft that requires practice

Every time I build something new, I discover new ways to leverage agents to produce code more efficiently.

Agents can speed you up, but they can also dig you into a hole faster than you can blink if you don’t stay accountable. I still don’t let them do the thinking for me. The engineering, the analysis, the clarity, all of that still needs to come from me. But when I guide them well, they keep me closer to what real engineering should feel like. And honestly, if this is where we are today, I can only imagine what the next wave is going to look like. I’m going to keep experimenting, and I’m sure I’ll keep being surprised.

If you like what you read or resonate with my opinions, subscribe to my mailing list, it's free!