I agree, but as a software engineer this gives me pause because I keep trying to insist on coding standards but I’m unable to come up with a compelling reason why it matters. Ostensibly the reason we cared about things like DRY and code quality was so that it would be easy to understand and easy to maintain and easy to make changes to later. But it now seems like a shared understanding of the codebase is less important than ever, and it’s more about shoveling requirements in without breaking any existing functionality.
Is a well tested slopfest better? That seems to be the conclusion for mathematics, so why not software too?
IMO it's still a problem with LLMs; we still have to build in a way that makes it easier for an LLM to make changes later and arguably it's the same things that made software development easier for humans. IME LLMs tend to not know how to do that for themselves and instead just amplify/copy patterns that already exist.
If an LLM can't pave the way for itself then ultimately shared understanding is required to take advantage of LLMs in the first place.
Would you personally vouch, at your job, for the importance of proper assembly coding standards?
I read a lot of assembly.
Certainly scopes vary, but in my line of work i define memory layout and how this data will be processed myself - thus it's great a compiler might do that, but the result of the computation will not change.
Now in comparison giving an LLM specs ... i a) cannot be sure what the computation will be b) it might be something else on another run.
We already have countless examples of such filling up the arXiv, written by hacks long before LLMs started writing proofs. No one cares about them. You might as well build a box blasting radio static into the void. You could save a lot of electricity that way.
I believe Terry Tao when he says the bottleneck will no longer be the writing of proofs, it’ll be everything else: reading them, reviewing, publishing, and teaching from them. A bunch of proofs that nobody reads are of no use to anyone.