For years, the software industry has been focused on making software easier to create.
We built higher-level programming languages so developers could stop thinking about the underlying machine, and later the adoption of frameworks and cloud platforms helped remove a lot of the repetitive work in application development and infrastructure management. Each wave of tooling lowered the amount of effort needed to transform an idea into working software, allowing organizations to expand what they could deliver without requiring a proportional increase in engineering effort.
AI is simply the next step in that evolution, although it is a far bigger leap than most of the advances that came before it.
The difference is that this time the improvement is measured in orders of magnitude rather than incremental gains. Features that once required weeks of development can now take only hours. Teams can stand up new services and prototype entirely new products in a fraction of the time those efforts once required.
Most conversations about AI focus on how quickly teams can turn ideas into working software. The discussion usually centers around speed and output, how to get the software to production, rather than what happens once it is in production.
I think the real conversation should be about ownership and the long-term consequences of dramatically increasing the amount of software teams can write.
Every Line Is a Future Obligation
While software can create enormous value, every line that enters production also creates an obligation that a team must carry forward. It becomes something that must be maintained, tested, secured, monitored, supported, and understood for years to come. Eventually it will need to be modified, replaced, or retired. The value generated by a feature may justify those costs, but the costs themselves never go away.
Historically, the relationship between software creation costs and software ownership costs remained somewhat balanced because software was expensive to write.
If a team wanted a new application, somebody had to spend a lot of time building it. That effort acted as a natural brake on complexity because every addition had to justify the engineering investment required to bring it into existence. Before software entered production, there was usually enough friction in the process for teams to ask whether the thing they were building was worth owning for the next five or ten years.
The cost of creating software is falling rapidly, while the cost of maintaining, understanding, and evolving that software remains largely unchanged.
Complexity Has Always Compounded
Programs don't become hard to understand due to a single bad decision. They move toward confusion with each of the thousands of reasonable decisions that are made over time.
A feature is added for an important customer, a new service is introduced to support a business initiative, and years later all those decisions still live inside the program along with the assumptions they were built on, the dependencies they created, and the interactions they introduced when those decisions were made.
Every addition expands the amount of software the team must keep in mind. It increases the number of relationships between components and makes it slightly harder to predict the consequences of changes within the program.
The Software Still Works
When people think about code rot, they usually imagine technical failures such as outdated dependencies, dead code, missing tests, or documentation that no longer reflects reality. While those problems still matter, I suspect the next generation of code rot will look very different from the traditional examples that engineers typically associate with an aging program.
Imagine an engineer trying to retire a service that has existed for six years. The original team is gone. The architect who designed it left years ago. The documentation suggests that the service is no longer required. Monitoring shows traffic flowing through the system, but nobody is entirely sure whether that traffic originates from customers or from another internal dependency. After two weeks of investigation, the service remains in production because removing it feels riskier than leaving it alone.
Nothing in this scenario is technically broken, and the software continues to function exactly as intended. But the problem is that the team no longer understands their systems well enough to make decisions about them.
Traditionally, we thought of code rot as something that happened to software itself. Dependencies became outdated. Tests fell behind. Documentation drifted out of sync with reality. I suspect the next generation of code rot will be less about the condition of the software and more about the condition of the organization's understanding.
In many cases, the software itself is not deteriorating at all. Instead, the organization's ability to explain why the software exists, who depends on it, or what would happen if it disappeared gradually erodes over time.
Historically, organizations accumulated these mysteries slowly, with a handful of forgotten services emerging over the course of several years. AI raises the possibility that organizations could create the same amount of future uncertainty in a matter of months simply because they can generate software so much faster than before.
That is the kind of code rot that concerns me most because it affects decision-making rather than functionality.
The Real Risk
The risk is not that AI generates bad code, although that possibility will always exist.
The more significant risk is that AI allows organizations to create software faster than they can manage the complexity that accompanies it.
For the first time, companies can dramatically increase the amount of software they own without making a corresponding increase in the number of people responsible for understanding how that software works and why it exists.
At first glance, that sounds like a productivity breakthrough capable of transforming software development.
It may also become an organizational memory problem that grows larger with every new feature, service, workflow, or automation that enters production.
Features remain in production because nobody knows who depends on them. Services continue running because ownership is unclear. Workflows survive because nobody is willing to risk removing them. Over time, more and more decisions become constrained by uncertainty rather than guided by understanding.
The consequences are not necessarily catastrophic outages or dramatic failures.
Instead, organizations may experience a gradual decline in their ability to move quickly because every change requires more investigation and more caution than the one before it.
Teams become increasingly hesitant because nobody fully understands the blast radius of a change. Features remain in production because removing them feels risky. Services continue running because nobody can confidently say they are no longer needed. Every modification demands additional analysis because understanding has become the scarce resource within the organization.
As a result, organizations may find themselves generating software faster than ever while simultaneously becoming slower at evolving the systems they already own.
Won't AI Understand It?
Whenever I bring this up, someone eventually argues that AI will understand the complexity for us and eliminate much of this concern.
Perhaps it will help, and there is good reason to believe it will become increasingly useful in this area.
AI is already remarkably good at reading code, tracing execution paths, identifying dependencies, and explaining behavior in ways that would have seemed impossible only a few years ago.
The problem is that software consists of far more than source code.
Software is also the accumulation of customer commitments, business decisions, operational compromises, regulatory requirements, historical context, and years of organizational knowledge that often exists outside the repository.
Questions such as why a service exists, which customer depends on a particular behavior, why a workaround was introduced, or what would happen if a component disappeared tomorrow are often far more important than understanding the implementation details themselves.
Most of that knowledge does not live in source control, architecture diagrams, or technical documentation.
Instead, it lives in conversations, institutional memory, and the people who were present when those decisions were made.
The challenge is that people leave. Teams change. Priorities shift. Organizational memory fades over time.
Stewardship Becomes the Job
This is why I believe the role of senior engineers and architects is becoming more important rather than less important.
For years, engineering leadership focused on helping organizations build faster because the primary constraint was the effort required to create software.
The challenge ahead may be helping organizations remain understandable even as the volume of software they produce continues to increase.
That requires treating complexity as a cost rather than an inevitability. It requires being willing to delete software that no longer serves a purpose and questioning whether every new service, workflow, abstraction, or agent truly deserves to exist.
The organizations that manage complexity most effectively may not be the ones that generate the greatest amount of software. Instead, they may be the organizations that become disciplined about removing software that no longer creates meaningful value and preserving understanding around the systems that remain.
Most importantly, it requires recognizing that every line of code generated today becomes something future engineers will inherit.
The New Bottleneck
The software industry has spent decades trying to make software easier to create, and by most measures that effort has been extraordinarily successful.
What AI may reveal, however, is that creating software was never the hardest part of the problem, even if it consumed most of our attention for many years.
The harder challenge has always been preserving enough understanding to safely evolve what we have already built while continuing to adapt it to changing business needs.
As a result, the central question is shifting from "Can we build it?" to "How do we prevent complexity from growing faster than our ability to understand it?"
The reason this matters is that code does not become truly dangerous only when it breaks. It becomes dangerous when nobody can confidently explain why it still exists, who depends on it, or what consequences would follow if it were removed.