> Now you have to audit the LLM generated code - all of it - and you have gained exactly nothing. It's even worse, because you can assume your library code has

> Now you have to audit the LLM generated code - all of it - and you have gained exactly nothing. It's even worse, because you can assume your library code has been tried and tested by others You're right to raise the first part as a concern and observing that, all things considered, you probably haven't gained anything on net. (You might actually be losing.) But you're wrong about the last part. What we've seen in practice is that like the free-rider problem there's a dearth of folks performing the work that people are assuming everyone else is doing and a glut of people relying on that false assumption. And it's worth considering how many of those fixes are _only_ necessary because of the rampant code sharing. Monocultures have downsides. A single vulnerability in a single package ends up exposing people to greater risk because the package is trying to be all things to all people and therefore contains functionality that only a fraction of its dependents actually wanted/needed. Because there's a monoculture, though, everyone is impacted. This is the counter to your #3: when you aren't following the same path others are on, you don't get their fixes, but you also aren't impacted by bugs that others are introducing in the first place. Anyone who's ever stared at server logs for an application that isn't Wordpress can see this principle in play when you consider how much protection simply not being on Wordpress provides for thwarting would-be attackers.