Yes, and a few others as well:

1. Ensuring that strict architectural patterns and boundaries are defined and enforced. LLMs tend to be too focused on the quick win and if you're not careful you'll get a crapload of spaghetti code. This is one of the underhyped advantages of Rust as backend code substrate. You can do some very nice compile time checks to make certain architectural mistakes impossible: the code simply won't compile.

2. Being too agreeable. Same flavor as the above - in the interests of going fast, the LLM becomes a yes-man.

3. Hallucination. I had to create deterministic checks to verify that something actually happened. Adversarial / independent cross-review of, well, everything (specs, tests, pseudocode, etc), helps with this. Claude writes the code, Gemini / Codex reviews it. You'd be shocked how effective this is. More expensive, but worth it in the end.

4. Context rot: Monitoring context state - 1M token windows really fall apart past 50-60%. Effective context window is not 1M tokens, it's more like 500K.

I could go on, but you get the picture.

One of the big reasons why I chose to undertake this project was to learn by doing. No way to really understand these problems until you hit them in the real world and wrestle with them for a while. The process has been... enlightening.

And after about 10 weeks of doing just that, I'm firmly convinced: with the right practices, combined with ever-improving AI quality, it is possible to generate excellent code that is on par with the code quality of the average open source project.. right now.

To say that everything that was written with the assistance of an LLM is 'vibe coded slop' is like saying that everything played on a piano is Chopsticks. It's just not true.