> "My immediate question would be what kind of adversarial reviews and deterministic gates did the author write to capture the dimensions of maintainability (lack of DRY, cyclomatic complexity, unclear naming, poorly architected flows, etc) that they cared about."
I wrote a tool at Meta to use AI to solve all those issues at scale. I don't necessarily think it really solves the problem, although I'm unsure about the reason (perhaps that's why they got rid of me!). There's something about codebase brittle-ness that isn't captured with those well-known, easy-to-catch quality issues. It could be related to architecture, design patterns, or something else that's a little larger than even the largest LLM context windows right now.
I think code validation is an interesting problem. It's like judging "rightness", which is an inherently subjective thing in all except the trivial cases.
It would only be part of the answer but the most striking thing to me is that AI lacks the inherent sense of minimalism most humans have because creating code is so hard for them. It's so hard that a large part of our initial thinking will simply be to minimise the solution down to the least possible change from current state.
AI tools do have a little bit of this but I think it's heavily in conflict with more recent efforts to increase their persistence and the scope they can undertake and length they can work on something. All these have been optimised to hill climb coding benchmarks, but put against the benchmark of "are you sure you really need this at all? Couldn't we do it a simpler way? What if we just did it X way and then we only need to change 10 lines of code" - they are not even being tested against this metric.