upvote
If the work can be checked by the next iteration of LLMs, does it really matter? Won't the work converge correctly?
reply
Like humans, LLMs also have to expand more effort when dealing with large piles of fragile spaghetti code. Spaghetti code isn't just aesthetically displeasing; there's a objective complexity increase and for large enough apps the increase is exponential. It's hard to imagine this ground truth ever changing.

Like humans, LLMs get into a place where fixing one thing breaks three others. They compensate partially with insanely big test suites, but now fixing one thing breaks three others, and 57 different specs, half of which also need to be updated.

I think roughly three outcomes are possible.

1. LLMs get fast/good/cheap enough that this just doesn't matter. Your 50M LOC monolith is a mess? Yeah, it still takes more effort for the LLM -- but this just means it costs 5 additional seconds and $0.03 instead of $0.02 to ship a new feature.

2. Stepping away from the "code as source of truth" paradigm. What if specs/docs were the vetted source of truth, and we just regenerate the whole 50M LOC monolith every time somebody makes a change, just like we rebuild binaries from C today whenever there's a change? (This probably requires some of the LLM advances from #1. Also, at this point, perhaps we should just skip the intermediate language and generate ASM -- what purpose is human readable source code serving at that point?)

3. Status quo as I see it -- human engineers overseeing projects, both guiding AI and being accelerated by it.

I think #2 is probably the... most ideal future? Though, of course, if we switch to that paradigm, the source-of-truth docs will have to be very thorough and structured, and will probably resemble a programming language of sorts themselves, except describing intents instead of operations.

reply