The Feedback Cap: Lehman's Laws in the Age of AI Agents

Adaptive Software

SubscribeSign in

Your A/B Tests Are Limiting What Your Software Can Learn<br>The Feedback Cap is the one limit software never redistributed and it's the constraint of the agent era

Noam Tenne<br>Aug 19, 2026

Share

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:<br>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.<br>So I decided to trace the history of software evolution research, to find clues and patterns.<br>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<br>Over the course of his research, Lehman proposed the following laws:<br>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.<br>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.<br>Interestingly, open source software has contributed a bunch of revisions and findings.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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...