However, "doesn't scale" doesn't sound like a valid reason to skip code review to me. More code does not directly translate to more shipped features.
There are definitely areas where I’m reviewing individual lines. Protocols are high on the list. I always want to know that high-level services aren’t leaking their internal details to the outside world and that whatever entity owns a protocol is controlling what is being communicated.
AI is bad at certain kinds of abstraction (for now). For example:
Connect service A to service B. Service C exists in some deployments and will do the real work in those cases, but A must never use B as a passthrough to C or use C’s language. That would cause future planned changes in the app to require a massive refactor.
Then, later, in review: Why is A’s client protocol to B referencing functionality that only exists in C? B’s entire purpose in life is to prevent this!
I haven’t tried to solve this via automation yet. I think it will involve limiting what AI has access to.
Humans tend to bring up things that matter to them + correctness, when they have time to think about it.
So in this example quality of comments is checked my LLM and not statically
If you're in finance, aviation, or some other industry where the cost of errors is very high, I do kinda want a human to look at every line of code even today.
Generating? Fine. But type it out again when placing it into the codebase to make sure.
But I'm not worried, some planes still update with a floppy. I'm sure that code is handwritten.
Sounds very interesting!
It’s just lots of declaration, detection, and fancy tests. But you need to apply a lot of attention to detail and make sure you have confidence that a given rule is enforced, and that a given entity can be detected. There’s more to it than that, but if you start playing around I’m sure you’ll figure the rest out.
I will warn that the goal isn’t to get AI to write code like a human would. It’s to enable controlled, high-velocity AI-driven SDLC that scales to large, complex applications.
The fundamental issue is that traditional code review doesn’t scale.
I now use a “Controls” linter which applies deterministic methods to constrain AI output, requires explicit declaration when key resources are used (file system access, network egress, outside libraries, or whatever I feel is important), and ties directly to other external requirements for business level controls that may be audited. (And more, but this gets the idea across)
Individual control violations can block PR mergers, block release, or just flag for review.
I genuinely don’t care that much about AI code quality these days (though I exclusively use SOTA models like Astra, which could be related). I care about code structure and architectural quality. I’ve found those can be deterministically enforced and made visible. If structure and architecture are high quality, I have no need to nitpick code quality.
If I were working with humans, this system would be cruel. It is far harsher than any manual code review I’ve ever given to humans. I let humans get away with small issues all the time. Dealing with the consequences of small mistakes is how people learn. For anything that really matters, I am ruthless with AI developers.
The system itself needs to be audited, so code review is still necessary. It’s more spot checking than full review though. You need to be a decent traditional software developer and architect to build new controls and to run control audits.