Post

Having done a lot of vibe coding lately, I think I’ll move away from it exclusively. Current agents eventually fail to adhere to some prompt despite various attempts and approaches. Whenever this happens and I look in the codebase I am usually mortified by what I find.

You might argue I need to use rules better or something like that. I would say that isn’t vibe coding. I interpret vibe coding as the agent addressing whatever whim I have in the realm of the possible, figuring it out for me. Mostly, I end up with spaghetti codebases that the agent cannot untangle.

Agents love to generate code. Give one a task and it is off to the races. In a new project, this isn’t the worst thing. In a project with existing functionality, this becomes a problem due to a combination of lack of context and lack of effective planning. The two go hand in hand.

Agents use search to look around a codebase to find relevant files to pull into context. You can also use rules to define how an agent should structure the codebase. At some point, often unbeknownst to the viber, the agent fails to pull a relevant file into the context window.

Initially, this doesn’t seem like a problem. The agent does what it does best. Writes code to solve the problem. No shared states available in the React app? No problem, it’ll write some hooks for you. Viber validates the behavior in the browser. Looks good? Commit and ship. Never reads the code.

Now the codebase has fragmented state. Viber comes back to the codebase 15 commits later. The application has grown considerably. GPUs, brrr, etc. Prompts the agent to make more changes using the state and it fails. Follow up prompts, debugging, MCPs. Why isn’t it working?

Finally cracks open the code. What am I even looking at? Ever tried to grok XX thousands lines of legacy code? Not easy. Use the model to find which code to look at. State is everywhere. State in hooks. State in redux. State in zustand. I really should have written rules for conventions.

It’s too late. For every convention rule you do write there will be one you miss. The agent will invisibly write working code that makes decisions on your behalf, filling in under specified requirements, and eventually you will have spaghetti.

The code will work and meet your requirements, but if you don’t read the code, you’re not going to realize when the model deviates in its approach from what you considerable reasonable.

This becomes a problem only later when you realize but at that point the agent has made more poor decisions based on this initial one.

These problems can’t be anticipated. You can’t rule-write your way out of them because you rarely know what the X0,000 line codebase should look like when it’s only X,000 lines. You can write code that remains flexible and is refactorable but today only the human knows when there’s a problem.

The agents just do things. Yes let plan, read files, make tool calls and use MCPs. But then they just *go* and that is a problem. From experience, I don’t think I ever want an agent to even start writing code without proposing a plan for what it wants to do.

At this juncture, I could evaluate the plan and pull in more context in case the agent missed something. To be able to do a good job of that, I need to know the codebase, at least architecturally. I need to know how state is managed, what libraries are used, how the file hierarchy is organized.

I need to know this in case the model misses anything, so I can step in and make the correction. If I only find out the model has been doing weird state duplication and synchronization when the agent finally stops being to make progress, it is too late.

The agent cannot be prompted to code itself out of the hole it digs. I’ve tried. I’ve told the model to identifying duplication and refactor. I’ve read the code and identified the points of duplication then told the model where and prompted for a refactor. State of the art models and agents fail.

So where do I go from here? I’ve actually had immense success writing code using agents and models with my hands on the wheel. For production code, this has always been the only viable option. But for personal projects, I now appreciate the ceiling vibe coding placed upon them.

I can vibe code a fun game but eventually, I may not be able to add more features due to the unmaintainable sprawl the model eventually creates. There is a small cost here. I have to be a touch more thoughtful as I build something to ensure the agent is staying on the rails.

In doing so I understand how my project works, learn new things as I collaborate with the agent, and keep the code in a state where it can continue to be extended. I’ll definitely progress more slowly but I won’t fly off the rails either.