Yet, it could be as easy as having a specialised model which is a code quality checker, refactor-er or QA tester.

Also, claimify (MS research) could be interesting for isolating claims about what the code should do, and then following up on writing granular unit test coverage.

However, with AI coding tools it's becoming a lot easier to write A LOT of code. And all this code (similar to when a human would write it) adds complexity and bugs. So it's not just the quality, it's also the quantity of code that damages existing code bases (in my view).

Really need to be adhering to set of defined specifications (functional / non-functional / domain specific), (work,project, etc). (and/or looking at what level(s) the specifications still relevant, post definition of specifications -- historically via different management levels). Note: doesn't necssarily mean riedgid specs first, code next, document.

Sigificant coding is "DFA" per setting/defining pre/post environment : repository check-in/out can be setup to do specification checking/diffing for auto-documentation, 'language/project features requirements, aka use, do not use, only use when, never use' can be done/filtered via . Above certain 'size', 're-inventions' would be an AI statisticall inference thing per amount of information.

Non-DFA aka "context sensitive" stuff : AI would only make sense if way to compare specifications with 'intentions'. aka generate confidence in how much newer coder has been on-boarded relative to coding attempts & project/work specifications. Perhaps also give work place management insite into how relevent things are (vs. "worker is the issue"). aka non-adherance to 'spec' because spec doesn't cover issue(s). Time to review spec. Still need human(s) in loop to figure out the relevant tangibles/intangibles. AI can certainly help identify ambiguities in specifications & how specifications are implimented/used. aka code debt & code drift