#Code reviews seem to be the biggest bottleneck in software development right now.
Open source package ecosystems are victims of their own success. There's a long tail of iffy packages that nobody has reviewed, and nobody wants to.
For the top projects, maintenance is tough. Stakes are high. Reviews are hard. Contributions are meh quality (even before LLMs). It's not just code, but a people problem too. GitHub's primitive workflow wastes everyone's time.
Something's gonna break.
LLMs can spit code-alike outputs 24/7, faster than humans can read it. This is a DoS attack on open source.
A maintainer can't trust that the person submitting a PR has properly reviewed the code, so they have to do all the review work anyway. There's zero benefit. If the maintainer wanted LLM-generated code, they could ask an LLM themselves, and skip the trust issues and slowness of dealing with a random middleman submitting it.
Something's gonna break.
Our model of software is still like manufactured goods: there's one product released, and everyone gets an identical copy.
I think LLMs will turn software into #houseplants - every user will have a slightly different clone, grow it, kill it, start a new one.
Maintainers don't want LLM code. Too much to review, too little value, merge headache. For users incentive to submit is also low: very slow process, with low chance of success. But an LLM can keep reimplementing their pet feature.
I'm not saying that would be a good thing, but the imbalance between the volume of code LLMs can generate vs code that people can maintain is so massive that I can't imagine things staying the way they are.
It makes better-than-LLM quality expensive and bottlenecked in comparison. This creates incentives to shift to quantity over quality, and to find ways to make do with buggy code.
Kornel
Thommy