> However, LLMs might reduce that effort to zero — we just don't know how developers will look after ten years of using LLMs now.
LLMs might help the new joiner produce code on the level of an average developer faster. But, at the same time, if LLMs are really trained on all open source repositories without any selection, that level might be limited.
It looks like the overwhelming majority of projects on Github, does not really follow stable growth tendencies. In all fairness, as these were the smaller projects, their developers might have never intended to demonstrate best practices, or make the project sustainable on the long-term.
This is all fine, experimentation and learning are very welcome in open source. But, with 83,9% of the projects (in my study) falling into this category, LLM might pick them up as demonstrating overwhelmingly popular best practices.
In the worst case, this might even lead to actual best practices being drowned out, over time.
In my study, I have seen that 16.1% of the projects (the larger ones) showed stable growth patterns over the last few decades (till early 2025). Showing resilience against any external change during that time.
If AI was able to improve 10% on the growth speed of those projects and it can be sustained over the long term, that is a really big breakthrough in relation to the laws of software evolution.
If the projects they measured would fall into the smaller ones, even a 10% productivity improvement might turn out to be temporary in the long term.
One reason could be that it is hard to evaluate productivity growth, in a general sense, after such a short time.
If we look at the Laws of Software Evolution, we should not really expect any improvement on the long run. This, however, does not mean that a given project might not experience benefits.
I have recently published a study: https://link.springer.com/article/10.1007/s44427-025-00019-y.
There, I investigated the long-term evolution of 66K projects. For about 16.1% of the projects, the growth curves seemed stable over decades. In line with the Laws of Software Evolution, they seemed to be largely resistant to external changes.
At the same time, most of the projects, the smaller ones, did not seem to be that stable. There external factors might have had large impacts. However, on the long term, projects in this group were also more likely to decelerate.
It might take several years, till we can tell if this technology did really bring a productivity growth that was sustainable on the long run, was only improving work in some particular domains, or just created some short term performance jump that came with some much higher costs only realized afterwards.
I'm the author of this study. I spent the last year diving into ~7.3TB of data from 65,987 GitHub projects to see how far the laws of software evolution (proposed decades ago by Lehman) hold up on such a large dataset.
The Findings: A Duality
The projects with more than about 700 commits to their main branch, 16.1% of all projects, follow such stable growth curves that they could support claims of some properties being divorced from human agency.
Despite all the hardware, software, tooling, methodical changes over the last few decades and even Large Language Models till early 2025, the underlying growth trajectories of these mature systems haven't fundamentally shifted. This suggests that while our tools might make daily life easier, they might not change the fundamental physics of effort over time in large codebases.
The Role of Smaller Projects
The smaller projects (83.9% of the dataset) not only follow less stable growth curves, but are also more prone to deceleration. It’s important to note that GitHub is—rightly—a home for everything from experimental prototypes and "homework", to niche tools. This experimentation is vital for the ecosystem, but might also create challenges for the industry down the line.
Whether they were following suboptimal methods or never intended to be long-term sustainable, the observed numerical dominance of smaller projects might in itself create problems:
- Popularity vs. Quality: Training Large Language Models or building learning materials by scraping GitHub indiscriminately risks a "popularity" bias. We may learn suboptimal, immature methods simply because those patterns are numerically overwhelming compared to the more stable 16.1%.
- Feedback loop: When these learnings are used to write new code, the numerically overwhelming proportions of the small projects might lead to ‘good enough, but not yet mature’ processes being propagated, effectively drowning out the potentially better practices present in more mature projects.
- For researchers: Focusing solely on large projects can overlook a much larger and different set of projects that could benefit from a targeted study.
I’ll be around to answer any questions about the research.
LLMs might help the new joiner produce code on the level of an average developer faster. But, at the same time, if LLMs are really trained on all open source repositories without any selection, that level might be limited.
I have recently published a potentially related article: https://link.springer.com/article/10.1007/s44427-025-00019-y
It looks like the overwhelming majority of projects on Github, does not really follow stable growth tendencies. In all fairness, as these were the smaller projects, their developers might have never intended to demonstrate best practices, or make the project sustainable on the long-term.
This is all fine, experimentation and learning are very welcome in open source. But, with 83,9% of the projects (in my study) falling into this category, LLM might pick them up as demonstrating overwhelmingly popular best practices. In the worst case, this might even lead to actual best practices being drowned out, over time.