Comment by zarzavat

> This only works if there's no consequences if your code breaks. In the eyes of other humans you're responsible for what you commit. No amount of "scaling" will change that.

You're only responsible for what you merge to master, not everything you commit to a feature branch no one is looking at...

If you have the testing and the infrastructure in place such that you can't ship broken code, then you just need to make sure your invariants are upheld - not that every single line is beautiful and perfect.

Further, I am working on a set of metrics that seems pretty good at identifying sloppy architecture. There's decent prior art at many different components of what "sloppy" architecture actually is, and ways to visualize it.

If you can rely on the consensus of several different models, plus your own judgement with the design and the testing in place to verify its implemented correct...

Then, 1) you don't need to code. 2) you only need to review 1/10th or less of the code written. That scales. Reading every line of code line by line doesn't really scale. LLMs aren't very fast at implementation outside of green-field projects. So you can often times implement something faster than they will if you did it by hand. Reviewing can take just as much time as implementing...