How do you keep up quality when you vibe-code?
I'm having a really hard time working with claude. In the past when I wrote all the code manually, it was always carefully reviewed and architected, with all possible flows carefully mapped out. Now, my code is mostly AI written which has led to things going out of control. Since it's easy to add new features and support many user flows, we went ahead and implemented flows that support a lot of cases our users run into. But now, I feel like things are getting too complex with no central notion of behaviour definitions, which causes every bug-fixing session to feel like a game of whack-a-mole, and results in missing edge cases and UI bugs that are becoming impossible to review and keep track of.
Every time I build anything new, it adds more complexity and the agent only seems to focus on the surrounding code within that session without keeping track of how it fits into the rest of the code base/product.
How do you all deal with this? Any suggestions for improving?
(
9 comments
| on HN
)
I wonder if there are people around who have stories to share about de-AI-Slopifying a codebase.
1. Experiment and solidify architecture before adding features. I think this is the hardest step for top-down thinkers.
2. Heavy testing and benchmarking. Prefer to TDD as much as possible. The actual lines for my agent-written codebases are generally ~70+% tests, benchmarks, and experiments.
3. Full mutation test coverage after the code is written. Doing this as a human is miserable IMO, but robots make it reasonable. This step resolves SO MANY subtle bugs.
At that point my main role is ensuring alignment with the actual specs.
The trouble comes later when the "experimental features" actually start getting traction and we discover all the holes in our implementation.
By the time we need to "productionize" our experiment, it has already been patched all over the place to account for bugs.
I get a feeling that this is made worse by the fact that since a lot of what we're doing is rapid prototyping, our repo is cluttered with examples of bad code that the agent picks up on and then goes ahead to copy in its own implementation.
I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
> I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
Enumerate, then fix-or-nix all known examples of bad code first. If you clear the path first, you will advance more quickly. It can feel frustrating having to do that, but my experience is that paying off tech debt earlier will prevent hitting the wall at an inopportune time.
A stronger version of this would be to make a separate gate. Fail the commit if the new code duplicates something already in a utility function, renames something that already had a name, uses for-loops instead of list comprehensions, whatever is bothering you.