Master Vibe Coding: AI-Powered Workflow

Recently, I've taken a lot of time to actually experience vibe coding, and I've come up with a few tips.

TL;DR

1. The used agent must support differential mode modification instead of overwriting the entire file.
2. Commit continuously.
3. The commands should be clear and simple, and context-sensitive.

Before describing the experience I'd like to briefly introduce the toolset I use.

• IDE is VS Code.
• Agent is a plugin from RooCode.
• Model uses several free models provided by OpenRouter.
  • The main one is deepseek-v3-0324
  • Occasionally llama-4-scout

As you can see I use free tools, which I believe is the best setup for the common developer. But it also creates a lot of headaches, which I'll talk about in a bit more detail.

Next, I'll provide you with the complete project I made using vibe coding.
https://github.com/wirelessr/alice

This is a command line tool that converts the natural language into the actual terminal command to be executed and gets the result.

In fact, many tools have similar functions, as follows.

1. Warp (AI-powered terminal tool)
2. iTerm2 AI
3. ShellGPT
4. ai-shell
5. etc.

There are many more, but they all have their own problems.

The main one is they don't support customized models like OpenRouter or Anthropic, and the second one is that the results are not very good, either the results are not on point or they aren't easy to use.

So I wrote a tool for my own needs, and I won't dive into the details of the tool.

The whole development process is I wrote a basic working script first, which is main.py and then I rely on vibe coding to start refactoring and adding new features step by step.

This development process should fit the scenario of most developers practicing vibe coding. Instead of using vibe coding to create a project from scratch, we use vibe coding to iterate on an existing project.

Let's start by explaining the three points mentioned at the beginning of the article.

Diff mode patching

I think this is one of the most important things, why?

When the model is not smart enough, it is easy to overwrite the whole file and change something that is not a problem. Here is an example of deepseek-v3-0324 muddying the water.

The project I developed uses AutoGen to implement the communication between agents, here is the import I used.

from autogen_ext.models.openai import OpenAIChatCompletionClient from autogen_core.models import ModelInfo from autogen_agentchat.agents import AssistantAgent 

But when RooCode wanted to make some changes to the code, he would often overwrite my entire file. Then the code breaks. This is the most common “unauthorized” change he does.

He changes models to model and agents to agent for some reason.

from autogen_ext.model.openai import OpenAIChatCompletionClient from autogen_core.model import ModelInfo from autogen_agentchat.agent import AssistantAgent 

Therefore, I've added a couple of absolute rules to my RooCode.

.roo/rules/rules.md

1. Do not overwrite the whole file easily. 2. Just modify parts that is asked. 3. Do not change any no bug part. 

Commit continuously

In vibe coding, agent behavior is largely unpredictable, especially with dummy agents like the example above.

So when you make a command, and you get an acceptable result, you have to make a git commit right away. Even if the command is only partially complete, at least the result is acceptable, so save it.

In the beginning, I often let the agent do what he wants and I ask him to do what I want, and then I have no idea what he's changed, or even what he's changed that's broken.

Therefore, please remember, as long as you see the result is acceptable, then just commit.

With commit, you will be able to compare what you have changed in subsequent commands, and you will also be able to know what needs to be fixed in this prompt.

Prompt should be clear and contextualized

Don't expect the agent to know what you want to change.

If you want to change something, tell the agent exactly what you want, which file, which function or even which lines you want to change. The clearer you are, the more you can get the expected result, not the free-for-all of a creative person.

When I first came across vibe coding, I always thought that agent can see all the code and structure, so agent should know what to change. But I was wrong, and very wrong.

There is a limit to the context that Agent can see. Of course, you can make that context huge, but there are a couple of problems.

1. Huge contexts cost money.
2. Huge contexts are easier to hallucinate.
3. Huge contexts are not always acceptable in terms of agent capability.

So you have to tell the agent clearly what to look at and where to change.

Will developers be eliminated?

There is often a dream that agent can replace the developer, I can only say, this is really a dream.

The project structure this time is quite simple, and the functions are not complicated.

To put it frankly, it is actually three agents communicate with each other to accomplish one thing.

1. Planning agent converts the natural language into a command line to be executed.
2. Execution agent executes the command line and reports the result.
3. Verification agent checks whether the result is correct or not, if not, it will start again.

Along the way, I added some new features.

1. Use PyInstaller to generate the executable.
2. Automatically release with Github Action.
3. Support both environment variables and configuration files.
4. Model setting.
5. Choose the language of the response.
6. Hide agent interactions and only get the final result.

I've also done some refactoring, such as splitting main.py into corresponding modules or turning the config module into a singleton pattern.

But with vibe coding, I feel a bit exhausted, agent's development efficiency is not as good as my own code, sometimes, I am really angry to see him playing idiot, but after all, I am practicing vibe coding, so I can only continue to see him playing idiot.

This kind of playing idiots with the stronger the model will be less and less, that is to say, it can be easier to write down the prompt.

Back to the above conclusion, vibe coding can not replace the developer, but for the skilled developers can improve development efficiency.

For example, if I tell the agent to turn my load_config() into a singleton pattern, he will make a standard singleton class as he imagines, but his context is not enough to change all the callers to load_config and then break the program.

But if I tell him to turn load_config into a singleton while keeping the load_config interface the same, he'll be able to make something similar to what I imagined.

So the role of the developer has become more important.

Nowadays, more and more agents have orchestractor (dispatcher) mode, which means he will break down complex tasks and assign them to other agents. Honestly, what he does is really not good, it's better to break down the requirements myself and then use prompt to tell the agent what to do.

Wrap Up

Vibe coding is already a trend among developers, but just like we practice writing programs, vibe coding requires continuous practice.

The more we use an agent, the easier to know where the agent's limits are, and the easier to make the agent meet the expectations.

Vibe coding is just a tool, a tool to make things easier for the user, not to replace the user. I hope everyone can become a sophisticated user of vibe coding, I am practicing too.