The Kessler Syndrome is a theoretical scenario created in 1978 by Donald Kessler. The scenario predicts that humans could launch so many satellites into orbit that a collision between two pieces of space debris could trigger a chain reaction of collisions. These collisions create more and more debris, making it impossible for anything to get through. Human life would become pinned to planet Earth.
The desire by many to make life interplanetary would become an impossible goal; the risk of total loss if Earth becomes uninhabitable is greatly increased, all because we couldn’t stop sending satellites to space without wondering how we would clean up the rubbish left behind. Our desire for growth led to our demise.
The risk that the scenario becomes true increases with cheaper, more frequent access to space. There are more private rockets than ever; access to space is becoming cheaper. More people can put more things in orbit.
Companies are trying to find ways to profit from becoming space scrap merchants. According to ESA, there are over 1.2m bits of space debris the size of a coffee cup, 54000 bits bigger than 10cm and almost 17,000 full satellites in orbit (ESA - Space Debris by the Numbers, n.d.).
That’s quite the legacy people have built; somebody is still having to support this.
What if the same happened with software? What if the cost of producing software becomes so cheap that we could build and launch almost anything? While excess software is unlikely to pin human life on a planet, it could lead to localised problems within organisations.
Around the turn of the 2020’s, tools like ChatGPT started to emerge. These platforms could predict the next word with a good degree of success. It didn’t take long for people to test whether these tools could predict the next function call or the next piece of syntax.
Fast forward to 2026, and we have artificial intelligence tools like Codex and Claude that take a written description of an idea and produce a functional application. These tools have become so sophisticated that the character-by-character prediction (Altman, n.d.) tasks we used to perform now start to look like artisanal sourdough.
Decreasing margins, tighter timeframes, and more competition have pushed product managers to seek methods to streamline software development. People have authored books and forged careers on selling the best way to build software. But these new AI tools are starting to promise the ability to condense months-long roadmaps into weeks or days; that's an incredibly attractive proposition to anyone.
Like space, the cost of building software and putting it into the cloud is dropping fast. Traditional software projects where risk was assessed by how long the software might take to build, and what its potential returns were. Whatever the timeframe, businesses exercised their judgment to make a bet on whether the “juice is worth the squeeze”.
You'd expect that paying for six months to have two, three, or even ten or more people execute their craft with care would be expensive. If it doesn’t produce the expected returns, the board will ask some tough questions about what went wrong. This placed a natural barrier on what people could build. They naturally drifted towards the strongest internal knowledge bases, the experience in the room, and the ability to charge a good price for access to the software.
Now, that judgment is largely ungoverned and exercised less rigorously. Fewer people are asking if the budget can support it; products need less demand to qualify. Suddenly, the list of things we can do is much longer. The risk of getting it wrong remains, but the consequences are different. It’s no longer half a million in salary, and 5 figures of hardware. It's three people's salaries, a few weeks' time, and a cloud bill. For the same thing.
Suddenly, the ability to create more software is bringing along with it the unquestioned thought that we are creating more value. Justifications like “If we build it ourselves, we don’t need to pay for it” or “we never really liked how that worked, but maybe we can do our own take on it”. These end up being heard as “cost savings” and “workflow efficiency”. The building begins. Less time needed to complete building the idea means less time required to make that judgment call. AI reduced risk and the input required for judgment.
Teams didn’t really stop to think about software updates, maintenance, hosting, and customer support like they traditionally would have. It doesn’t matter; they can build anything now. The building commences, and the AI shapes the decision across everything. Of course, the AI isn’t forcing a decision, but its recommendations go unchallenged. People defer to it, rather than think or debate it.
The team of ten is now a team of seven. Three people left, and the company decided not to hire replacements. Saving money and building cheaper software! Life seems great.
Products ship, SDR’s get lots to talk about, excitement is high.
The software teams are productive; they’re keeping the models busy, too. The pro subscription is the best investment made since sliced carbohydrates. They’ve shipped a bunch of internal tools, and the products are in the hands of the customers. Profit should come next.
The number of competitors did increase, but the SDR’s are shouting louder with marketing. They’re working harder, but the omelettes are in the pan. Profit should come next.
Customer support is stretched, supporting more software, and they’re spread over a larger surface area. AI is creating tickets automatically, and finance starts to ask why infrastructure costs have increased. The board are wondering where in the forecasts it says about the profit. Not long, the team is building at its quickest rate EVER. Profit should come next.
A chain reaction of collisions is starting.
Technology costs are signed into contracts, and deliverables start to slow down because people are now wary about upsetting fewer customers across a larger surface area. Engineering capacity is almost depleted; they’re spending more capacity on supporting issues. Internally, there are lots of discussions about context windows and token limits. Like the space debris, the business is pinning itself down; sunk costs, customer dependence, internal politics, and weak ownership are blinding it. AI made the mess, it can fix it, is the mantra.
Nobody predicted rising operational complexity. Nobody predicted a team's attention being stretched. The AI is hungry for tokens; it's eating them up and still carrying an unchallenged authority. Nobody is asking why intelligence is bringing more bug reports. There must be something wrong with the idea of using AI to mark its own homework.
Generating code got cheaper, but building a business didn’t. AI made computing more expensive (Sparkes, 2025), AI created the need for more repos, microservices, and variations. Nobody quite realised that teams were being paid to operate paid artificial intelligence tools to execute commands on paid-for machinery.
Before AI, scarcity was in code; now it's in judgment, ownership and operational discipline. Acceptance of something nobody understood, because the value went unchallenged.
But you can use AI to manage this better! Maybe, but if you’re managing complexity, or AI is managing complexity, you still have complexity. AI doesn’t have context for your business; it doesn’t even have a full context for the application.
Like those aspirational space-scrap-merchants, figuring out how to reclaim space junk, the adopters of AI need to retain the judgment that has protected them in the past. The question “could we?” needs to evolve into “should we?”.
Left unchecked, this will spiral out of control and in the worst case, the business collapses. Like Kessler's syndrome, too much surface area in software can lead to the same effect in a business. Luckily, software can just be turned off, but businesses often don’t think it can be, with leaders remaining committed to a high-cost, underperforming product.
But shutting a badly performing product frees you. You may boost a competitor's customer figure, but you create strength in understanding the failure, and you create governance to protect yourself. But to do that requires recognition that the commitment made at the start was built on a soft foundation. The reclaimed resource can be allocated to another area of the business.
If you do not have a clear path of ownership and responsibility, you have software debris. The debris will eventually collide with engineering capacity, support, finance and security.
Software will survive in companies that have the knowledge, understanding, and history of decision-making that led to its existence. That requires ownership, long-term investment, and an understanding of support, security, and costs. It requires operational maturity. Without it, organisations become congested by the software they were too quick to build.
So, should we?