The Business of Cleaning Up Other People's Mess
On judgment, LLMs, and why someone always ends up rescuing projects
A few days ago I ran into the CEO of a company I audited a few months back. Reflecting on that conversation, he told me in confidence (and I have his permission to share this):
“Why does everything always have to be so hard? I’ve been in tech for a long time and the projects that come our way are always so complicated.”
My response, after a few beers and with full honesty, was:
“That’s because your business is built on cleaning up other people’s mess.”
And it’s true. When your business model depends on rescuing failed projects, you inherit decisions you didn’t make, technical debt you didn’t create, and problems you didn’t cause.
It’s the opposite of Stoicism: instead of focusing on what you can control, your day-to-day revolves around what others couldn’t control.
That conversation led me to grab a coffee and remember all the times I found myself in that situation: a project lands on your desk and you have no idea where to start.
The world before LLMs was a different sport.
Hours and hours on Stack Overflow searching for that cryptic error that only 3 people in the world had ever seen. Digging through GitHub issues from 4 years ago, praying someone had found a solution. Reading outdated documentation. Trying absurd combinations of library versions until something worked.
And when you finally solved it, you felt like you’d conquered Everest. But you’d also lost half a day (or more) on something that today gets solved in 30 seconds.
I don’t know if it was better or worse. But it was definitely harder.
What Came Included
I don’t miss the suffering. There was a lot that was simply unnecessary: outdated documentation, cryptic errors, libraries abandoned by their creators. Poorly designed friction that taught nothing.
But there was something that came included, without you asking for it: understanding.
When there were no shortcuts, you had to understand. You couldn’t copy a solution from Stack Overflow without reading the comments that said “this breaks in production.” You couldn’t use a library without checking when the last commit was. You couldn’t move forward without knowing why something worked.
That understanding gave you judgment. Knowing when a solution was solid and when it was a time bomb. When an error was a symptom of something deeper. When to push through and when to walk away.
Today you can skip that part. And many do.
TikTok for the C-Suite
In the previous post I talked about the dopamine hit that code agents deliver. You can have an API running in hours. Features “ready” for the Friday demo.
It’s almost like TikTok for the C-Suite: instant gratification, infinite scroll of features.
But there’s a trap: if you let the LLM run without supervision, without judgment, without someone who understands why things work (or don’t), what you produce is more code. Faster. With more hidden technical debt.
More mess.
Judgment is seeing an 800-line PR generated by an agent and knowing in two minutes that you need to throw it out because the abstraction was wrong from the start. Judgment is understanding that “it works” doesn’t mean “it’s right.”
And without judgment, that mess ends up on the desk of someone like the CEO in this story. Entire companies built on rescuing projects that seemed “ready” because an agent generated them in an afternoon of vibe coding.
The Circle
There’s the irony:
- The pre-LLM world was slow and painful, but it gave you judgment.
- The post-LLM world is fast and addictive, but without judgment it only accelerates the production of disasters.
- And someone has to clean up those disasters.
The CEO wasn’t trapped in a bad business model by accident. He was in the exact place where everything built without judgment ends up. Every “urgent” project that landed on his desk was the result of someone who generated code without understanding why it worked — or why it was going to stop working.
Without judgment, you can’t design systems that tolerate failure, because you don’t understand where they’re going to fail. And when they fail, someone else pays the cost.
Closing
I’m not saying we should go back to Stack Overflow as the only source of truth. LLMs changed the game and there’s no going back.
But judgment — knowing what’s worth it, what to ask, what to discard — that doesn’t come from a prompt.
It comes from having understood why things fail. Having seen it up close. Having had to fix it.
And if you don’t develop it, you’re going to end up in one of two places: generating work for someone else, or being the one who receives it.
The CEO in this story chose the latter. He’s doing well. But every time a project lands on his desk, he’s paying the cost of the judgment that someone else didn’t have.
One Last Piece of Advice
A while back I went to therapy. In one session I asked my therapist how she managed to listen every day to so many problems from so many people and look like it didn’t affect her.
Her answer was clear: she didn’t take it home. She set boundaries.
So the next time you see an architecture or code that you want to throw in the trash, first make peace with yourself. Understand that all of that mess you’re about to clean up is not your fault.
Marcus Aurelius and Epictetus would be quite upset if you took it home. But then again, they’re Stoics. They couldn’t control the fact that you accepted the contract.