From Junk Drawer to Hoarder House: Your AI Mess Just Became a Leadership Problem
A hoarder house doesn’t start with a mountain of trash. It starts with one thing you might need later. A stack of magazines. A box of cables. A junk drawer.
The CTO has always kept a junk drawer of known tech debt. A messy but contained space.
But something has shifted. GenAI and low-code tools have made building software cheap and fast. Everyone is now a builder. We’ve traded the difficulty of writing code for the difficulty of managing its consequences. The New York Times named it the ‘AI Mess’ era.
That junk drawer has spilled out into the hallway. It’s blocking the exits. What used to be the CTO’s (well) contained problem is quickly becoming the CEO’s hoarder house.
The CTO’s team can’t see what’s being built and doesn’t know what the intended behavior is. The business leaders who asked for it have moved on to the next priority. The builders themselves don’t know that what they created carries an ongoing operational obligation.
The decision hasn’t been made because most organizations haven’t realized there’s a decision to make.
John Willis, co-author of the DevOps Handbook, argued at the 2024 Enterprise Tech Leadership Summit that we’re going down the same road as Shadow IT, but faster and with more surface area. He’s right. What’s accumulating now is debt that doesn’t know it’s debt. The builder of that customer-facing workflow doesn’t know she’s created something that needs monitoring, maintenance and an eventual retirement plan. And the longer the ownership question stays unanswered, the more expensive the answer gets.
Engineers spent two decades building the discipline of managing what gets created, who maintains it and when to turn it off. Most of those learnings never left the engineering org. They need to.
“You build it, you run it.”
Twenty years ago, Werner Vogels made the case in six words. The DevOps movement turned them into a discipline.
Before Vogels, the model was simple: developers wrote code, threw it over the wall to an operations team and moved on. When the code wasn’t deployed fast enough, developers blamed operations. When it broke at 3am, operations blamed developers for shipping something that wasn’t built to survive outside a test environment. Everyone blamed the other side.
I remember the specific 3am page that broke my patience.
My phone buzzed on the nightstand. I was one of four people with the access rights to resolve a particular type of catastrophic integration failure. We had been trying to manage this known issue with processes and checklists, but one month I had four middle-of-the-night wake ups. I had enough. I called a meeting. We dug into the code and finally introduced validations that prevented the issue in the first place.
Vogels’ “You build it, you run it” philosophy fixed this by collapsing build and maintain into one accountability. When you own what you ship, you build differently. You think about failure modes. You write documentation your future self can actually use. Launch day is no longer the finish line.
The principle isn’t “builders should also do maintenance.” It’s deeper. Separating the people who create from the people who maintain always produces dysfunction. Always. The creator optimizes for shipping. The maintainer inherits problems they didn’t create and can’t fully understand. The feedback loop that would make the next version better never forms.
Now apply that to AI-built artifacts. The marketing analyst who automated a reporting workflow isn’t thinking about what happens when the data source changes, when the logic needs updating, or when someone needs to debug it at quarter-end. She built it. It works. She moved on. The ownership question never occurred to her, because in her world, building has never carried a trailing obligation.
Principle: You build it, you run it.
Translation: Ownership includes the trailing obligation of monitoring and maintenance.
Risk: Someone gets a quick win. The organization gets a lifetime subscription to a bill nobody knows how to pay.
You can’t manage what you can’t see.
Long before I arrived, a sales team at one company contracted with a low-code automation vendor to send files to their customers. Engineering was resource-constrained. Sales needed a solution. But there was no observability. No way to see what was actually happening inside the black box. When a customer didn’t get their file, someone would just send it again.
Over the years, they kept building. The issues got worse. It wasn’t just missing files. It was the right file to the wrong customer. The wrong file to the right customer. The underlying data was sensitive. Customer trust was eroding. Potential fines and legal action.
Then my team inherited the problem.
Charity Majors, a pioneer of modern observability, argues you haven’t truly seen your system until you can interrogate it without knowing what you’re looking for in advance. When my team inherited this mess, our first move wasn’t fixing the code. It was building the ability to interrogate it.
Most organizations cannot currently answer basic questions about their AI-built artifacts. What exists? Who built it? What does it depend on? Is anyone still using it? What breaks if it goes down?
If you can’t answer those questions about your engineering systems (and many organizations can’t, even now), you definitely can’t answer them about the automations, dashboards and workflows being built across every function.
Principle: You can’t understand what you can’t see.
Translation: Ownership means you can’t build a black box.
Risk: You replastered the leak on the ceiling, but never checked the pipes. You won’t know which pipe is leaking until the ceiling falls in.
Build with boundaries, or everything becomes load-bearing.
You know that feeling when you open a spreadsheet and it’s suddenly full of #REF! errors? You’ve opened that tab a hundred times, but this time something upstream changed and now you’re reverse-engineering which cells pointed where and what broke. That’s a dependency chain.
Now imagine the same dynamic, but instead of spreadsheet cells it’s automations and workflows running across departments. Instead of broken formulas it’s processes that fail silently until the impact is too big to ignore.
These connections grow “one quick fix” at a time, until the system develops a shape nobody designed and nobody can see.
Carliss Baldwin showed that how you partition a system determines where change stays possible.
Build with clear boundaries between components and you can maintain, update and retire them independently.
Build without boundaries and every piece depends on every other piece, even the parts nobody uses anymore.
Modularity isn’t an engineering concept that only engineers should care about. It’s the principle that determines whether your organization can change its mind later without breaking everything that came before.
Principle: Build with boundaries, or everything becomes load-bearing.
Translation: Partitioning determines where change stays possible.
Risk: A minor marketing tweak becomes a Finance catastrophe. Without boundaries, everything is load-bearing.
Maintenance is not cleanup. It’s part of the work.
Tidy First? reframes the relationship between building and maintaining. The instinct is to build first, clean up later. Kent Beck’s argument: tidying, the small ongoing structural improvements, is a first-class activity. Not something you do when the mess becomes unbearable. Something you do before you build the next thing.
And it’s not just “tidy or don’t.” In his book, Beck maps four choices:
tidy first (when cleanup makes the next change easier),
tidy after (when the code works but is harder for the next person to read),
tidy later (when you’re under a hard deadline and the mess isn’t blocking you), and
tidy never (when the code works and you’re never going to touch it again).
That framework matters because each of those is a decision. Engineers struggle with this discipline even when they understand it intellectually. For non-engineers building with AI and low-code tools, the decision doesn’t exist at all. They’re not choosing “tidy later.” They don’t know there’s a choice to make.
And then there’s the decision engineers struggle with most: when to turn something off entirely. I’ve never been on a team that did deprecation well. Code that nobody uses stays running for years because turning it off feels riskier than leaving it alone. The surface area for incidents and vulnerabilities grows quietly. The hoarder house gets a shed in the backyard.
If engineers, who understand deprecation and have tools designed for it, still can’t bring themselves to turn things off... what happens when the new builders don’t realize code retirement is a concept at all?
Principle: Tidying now reduces the need for a “deep clean” later.
Translation: Maintenance isn’t cleanup. It’s a structural decision to prevent operational paralysis.
Risk: You live in a hoarder house. You spend 80% of your energy keeping junk alive until there is no room left for actual growth.
The bind
How organizations assign monitoring, deprecation and incident ownership was designed for engineers. Someone who understood that shipping was the beginning, not the end. Nobody designed it for a world where everyone builds.
Setting up the marketing team with an incident management rotation for their AI-generated workflows is overkill. But routing everything back through the engineering org isn’t the answer either. Engineering can’t maintain what they can’t see, didn’t design and don’t understand the business intent behind.
Restricting who can build defeats the point. GenAI and low-code tools have genuinely reduced the cost to create, and the people closest to the problem are often the right people to build the solution. But the cost to create and the total cost of ownership are different equations. Organizations are celebrating the first while ignoring the second.
Nobody has a clean answer to where ownership lives when builders are everywhere. That’s not a gap in the literature. It’s a genuinely new organizational design problem, and anyone who tells you otherwise is selling something. What’s certain is that the question has to get asked now, while the accumulation is still manageable. Because the interim is going to be messy regardless: things will break and nobody will know what broke, when it broke or whose problem it is.
If you allow a team to build a load-bearing process without the obligation to maintain it, you aren’t being agile. You’re just borrowing stability from the future at a predatory interest rate.
The hoarder house isn’t inevitable. But it requires asking the hard question today: If this automation breaks at midnight, who is going to fix it?
A sincere thank you to Gene Kim, Jeff Gallimore and the IT Revolution community. Their years of work translating hard-won engineering principles for a leadership audience long before GenAI arrived gave me the vocabulary to recognize these patterns. They’re the cartographers; I’m just trying to share their map.
I’m Clare Hawthorne. I fix friction at the seam between technology, finance and go-to-market.
Really loved this post. It has so much resonance with me. Thank you for writing it.
Good boundaries + regular maintenance = healthy systems. These principles transcend software.