Hi, On 8/12/26 7:08 PM, Marc Haber wrote:
I'm sad about the contributor effort being lost to this, but this is not something I have a lot of influence on.
Contributor Effort is going to be lost either way. We just don't know which contributors we're going to lose.
With "contributor effort", I mean the work on projects that fail, and the work that is required to deal with the fallout of failed projects.
The flip side of the increased effectiveness is that it often becomes easier to rebuild a project from scratch instead of contributing to an existing project. Typically the main feature of the rewrite is an extensive test suite "to make it easy to contribute", in the hope of attracting more people — but the same mechanism that made it feasible to rewrite the project in the first place also makes it unattractive to contribute to it.
If a project does get used downstream, there is a cost of transitioning users, some of whom might not see their use cases represented at all, might need to perform integration work, or might need training. If such a project then later fizzles out because they failed to build a large enough community, then users need to be transitioned off again.
The increased effectiveness is not a replacement for a large community, even though it allows a single developer to perform more tasks at a mediocre level. It is just enough to stop a community from forming in the first place, when something is "good enough" that no one feels like putting a lot of effort into a slight improvement — that's why I think that we will see more projects being started, and more projects failing.
The aspect of losing contributors is a different one, and it has a third option: the "anti-AI" people leave when they no longer feel valued (after all, the increased effectiveness should more than compensate for that), and the "pro-AI" people leave when tokens get too expensive, which will not placate the "anti-AI" people.
Also, I wrote "effectiveness", not "efficiency" here for a reason: LLM use trades resources for speed, not speed for resources. The argument for calling it "efficiency" would be that we are saving on developer time — but we aren't, since we're just using the time to build more code¹ instead of touching grass².
Simon ¹ code is a liability, not an asset ² yellow
