What worked best for me is to start doing things by hand, trying to do the architecture and the standards I really want. Then, AI works really well on following my conventions. Therefore it gets easier if I want to check codebase, because it's already organized as I initially planned, even all the new code is not anymore written by me directly. Then I also use Revix AI as a reviewer on my PRs that really helps me filtering anything that gets out of the standards and conventions I like.

Other than that, on other projects that I fully vibecoded, it's just impossible to keep with the codebase. Just blind trust the AI models on that, and never do it on a serious production product.

I think a lot of folks ended up in a world where you write specs and designs in Markdown documents and use that to drive the outcome (the code, the system, tests, etc). So you drive intend through those specifications and design docs.

Lately though, I've switched tact a bit and have resurrected some ~20yr old research called Behaviour Tree Engineering or Behaviour Trees, so I'm now writing specifications called BT specs.

e.g: https://bte.mills.io/s/v4Mjbyf0OBJWm5YRLwG5XiIH

ponytail plugin is good for reducing amount of code. i have a different ai that code reviews it and i tell it that it is smarter than the ai that wrote the code. i had to tweak it to not be too nitty.

Two distinct strategies.

For tools and architecture,I design data structures and let the LLM write the code, in small steps. Lots of discussion with the LLM. What Cory Doctorow calls centaur mode - a human mind augmented with a more powerful body. Applies to side projects and $DAYJOB.

For applications, I rewrote a framework of mine that I used 2003-2009. It is highly constrained so the LLM has few options to improvise. I can just tell it what features to add and it adds them without much in the way of slop. I still find code repetition which I just tell it to clean up.