That's a good point. We've been using the UML diagrams as a tool to catch behavioral red flags, but the reuse and implementation details of that are left undefined.

Maybe the answer lies in also explicitly spending a few passes focusing on code health, explainability, maintainability (while keeping brain on). This is something I go through at end and then retry verification tests, but not something we explicitly require in our process at the moment.

But in the end you have to know what good looks like and be able to call bullshit. Hmm I guess strong first principles are still the foundation of being good at something, no matter how the tools change. And practice, feedback, and constraint exposure are what turn that into actual effectiveness.