> the code we've created looks crap and is mostly wrong, full of fluff, or hard to understand
I don't disagree in general but I've had a lot of success asking the LLMs to specifically fix these things and make things more maintainable when specifically prompted to do so. I agree debugging and getting things working it often needs supervision, guidance and advice. And architecture it often gets a little wrong and needs nudges to see the light.
I'm not great at this stuff and I got tired of reviewing things and generating suggestions to improve implementations (it seemed to be repetitive a lot) but I am having good results with my latest project using simulated ecosystems with adversarial sub-projects. So there's the core project I care about with a maintainer agent/persona, an extension with an extension developer agent/persona (the extensions provide common features built upon the core with the perspective of being a third-party developer), and an application developer that uses both the core and extensions. I have them all write reports about challenges and reviewing the sub-projects they consume, complaining about awkwardness and ways the other parties could be improved. Then the "owner" of each component reviews the feedback to develop plans for me to evaluate and approve. Very often the "user" components end up complaining about complexity and inconsistency. The "owner" developers tend to add a lot multiple ways of doing things when asked for new features until specifically prompted to review their own code to reduce redundancy, streamline use and improve maintainability. But they will do it when prompted and I've been pretty happy with the code and documentation it's generating.