Starting Sky Valley Ambient Computing, building Differ and thinking a lot about Adaptive Software means that the evolution of software is often on my mind. Software engineering is constantly evolving, so much so that under AI every assumption is being undermined:
Who will conceive of the software?
Who will write the software?
Who will tend to the software?
Who will use the software?
Adaptive Software plays a part in each one of those questions and there are many implications to every answer. The knee-jerk reaction is that agents are gonna do all of the above and we’re all just happy Scrooge McDucks swimming in a pool of golden coins.
So I decided to trace the history of software evolution research, to find clues and patterns.
A legendary computer scientist by the name Meir M. Lehman kicked it off by researching software evolution in the late ‘60s by looking at data from releases of OS/3601 and later published a paper named “Programs, Life Cycles, and Laws of Software Evolution.”2
Over the course of his research, Lehman proposed the following laws:
Software continuously undergoes changes
Software increasingly becomes complex
Software growth regulates itself in a statistically predictable way
The rate of work on a system is roughly constant, regardless of how many people you throw at it. This is similar to the Mythical Man-Month but stronger. Brooks said that adding people doesn’t add progress; Lehman observed that the pace of progress stays the same no matter what you do
Familiarity of the software must be conserved (or users/developers lose mastery)
Software continuously grows
Software continuously declines in quality (unless continuously maintained and adapted to its environment)
Software evolution is governed by a multi-level, multi-agent feedback system
As years went by, some of the laws were refuted or amended. Often alongside shifts in how development was distributed.
In 1988, Pirzada3 ran research on three UNIX systems and proposed the nuance to restrict the laws to evolution in commercial settings. Commercial settings apply different pressures with things such as deadlines, profitability, shifting business metrics, etc. Things that don’t exist in research and academic settings. This, as I read it, means that the laws are about coordination, not software! Researchers, academics and volunteer contributors do not coordinate the software development effort in the same way that a business would.
Interestingly, open source software has contributed a bunch of revisions and findings.
In 2000, Godfrey & Tu4 found that the Linux kernel grew super-linearly, as the main kernel codebase stabilised and changes concentrated in device-driver code. Because Linux was developed in a distributed manner (as opposed to centralised), its growth was not self-regulating in a statistically predictable way, as first derived from commercial and centralised efforts.
In 2009, Xie, Chen & Neamtiu5 found contradictions to law 7, that quality must decrease over time. Rather, they found that quality actually improved across the projects they had measured.
In 2010, Israeli & Feitelson6 found that the average complexity of the Linux kernel decreased over time, breaking law 2, which claims that software becomes increasingly complex. On top of that, the super-linear growth found by Godfrey & Tu ended around kernel version 2.5. Meaning that distributed development had earlier introduced a higher ceiling, and that ceiling had been reached.
Finally, the widely held position7 is that change never stops, growth never stops, and claims such as “software growth regulates itself”, or “rate of work is constant no matter what” should be scoped to managed commercial developments, not all developments.
Arriving at today (2026), we find that AI agents are redistributing the act of building again, but there are still no peer-reviewed tests of the laws against AI-built software.
So what patterns can we observe so far? First, we must recognise that software development faces different pressures depending on whether it’s built in a commercial or open source setting. Closed source commercial software isn’t governed by the same laws as FOSS.
Second and more interesting is that redistribution of work kills the laws dealing with caps and regularity, and spares the laws that speak of change and growth.
I’m looking forward to seeing how AI affects law 8, which claims that software evolution is governed by a multi-level, multi-loop, multi-agent feedback system. That is, software evolves thanks to friction with the real world. Think of user interactions, bug reports, errors, feature requests and exposure to different segments that have different needs. All of these are pressures that drive evolution.
So if feedback governs evolution, we can assume that what limits feedback also limits evolution. Let’s call it The Feedback Cap. The Feedback Cap is the ceiling on how much feedback returns to a software system, guiding further evolution.
New methods of software distribution such as the PC, the internet and the mobile phone have increased the number of people that software can reach, and therefore the number of interactions through which it can receive feedback. But this is still constrained by the number of users you can serve at any moment, whether you’ve reached them or not. Secondly, the feedback is bound by the attention that you’re able to retain from your users.
AI agents are already stressing the coordination caps of building software, but no matter how much software you build, its evolution is still constrained by the feedback it receives from its environment - The Feedback Cap. All the agents’ coordination, complexity and size growth of your software mean nothing if the feedback system is the bottleneck.
One could argue that agents will increase the limit by using more software, more often, but agents are still acting on behalf of someone or something, and fulfilling their intention. Any feedback they generate is therefore still constrained by the needs and motivations of the entity that dispatched them. These are not infinite.
It’s possible that Adaptive Software could raise the limits even further. A one-size-fits-all solution, by definition, underserves different segments, users and use cases because it is a compromise. So there is feedback that you could never apply because that would make the product worse for everyone else. Furthermore, by not applying that feedback, you’re closing the door on any possible derivative feedback from these paths that were not taken. By forcing convergence, we are kneecapping ourselves because we are forcibly reducing our feedback surface.
Adaptive software can instead respond differently to different users and environments, allowing more feedback paths.
Enter Software Speciation. Instead of forced convergence, software is allowed to speciate and evolve per deployment, per cohort, even per person!
This creates a positive cycle because software that can adapt can serve a wider range of users and environments. More environments create more unique feedback loops, and those additional feedback loops create more evolutionary pressure, giving the software more opportunities to adapt. By killing the need to converge, you discover the real preferences of the user, and how they change over time.
Adaptive Software will uncover the next new limits of feedback. Reducing the cost of creating software shouldn’t be limited to creating the same thing, but quicker and with more working hands (or robotic arms). If we allow our software to then diverge and speciate we will increase the surface, and increase the cap on the feedback loop.
Furthermore, a network of Adaptive Software will uncover possibilities that were so far out of reach, by enabling adaptations and divergences to travel between versions for different users, and even between different applications for the same user! That means that lessons learned from divergences can compound across the network, rather than die out in niche species.
Adaptive Software that speciates and diverges will help us reach this new limit, if divergence grows total usage and lessons propagate. Our first product, Differ, is a bet on both.
L. A. Belady and M. M. Lehman, “A Model of Large Program Development,” IBM Systems Journal 15(3), 1976 — the OS/360 release measurements. https://doi.org/10.1147/sj.153.0225
M. M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution,” Proceedings of the IEEE 68(9), 1980. https://doi.org/10.1109/PROC.1980.11805
S. S. Pirzada, “A Statistical Examination of the Evolution of the UNIX System,” PhD thesis, Imperial College London, 1988. Full text: http://hdl.handle.net/10044/1/7942
M. W. Godfrey and Q. Tu, “Evolution in Open Source Software: A Case Study,” Proc. ICSM, 2000. https://doi.org/10.1109/icsm.2000.883030 · open PDF: http://plg.uwaterloo.ca/~migod/papers/2000/icsm00.pdf
G. Xie, J. Chen and I. Neamtiu, “Towards a Better Understanding of Software Evolution: An Empirical Study on Open Source Software,” Proc. ICSM, 2009. https://doi.org/10.1109/ICSM.2009.5306356
A. Israeli and D. G. Feitelson, “The Linux Kernel as a Case Study in Software Evolution,” Journal of Systems and Software 83(3), 2010. https://doi.org/10.1016/j.jss.2009.09.042
I. Herraiz, D. Rodriguez, G. Robles and J. M. Gonzalez-Barahona, “The Evolution of the Laws of Software Evolution: A Discussion Based on a Systematic Literature Review,” ACM Computing Surveys 46(2), 2013. https://doi.org/10.1145/2543581.2543595 · open copy: https://oa.upm.es/20813/