The day all five of my AI projects stopped building and started cleaning

Hey, it’s Paul. Saturday, February 28, 2026.

I want to talk about something that happened this week that I almost missed because it looked boring. Five separate software projects — all mine, all running semi-autonomously with AI pipelines — independently decided to stop building and start cleaning. Nobody coordinated it. There was no memo. But every single project reached for the broom on the same day.

And that’s not a story about software. That’s a story about how systems tell you what they need, if you’re paying attention.

There’s a concept in organizational theory that doesn’t get enough airtime. It’s the idea that growth creates its own drag. Not gradually — in steps. You build, you build, you build, and everything feels fine. Then one morning the cost of carrying forward all the stuff you accumulated overnight exceeds the cost of stopping to clean it up. It’s not a slow decline. It’s a threshold. You cross it, and suddenly the only way to go faster is to go backward first.

I’ve seen this in every consulting engagement I’ve ever done. A company adds process on top of process, adds tools on top of tools, hires people to manage the tools that manage the processes — and then one quarter, everything stalls. Not because they ran out of ideas. Because the weight of their own accumulation made it impossible to move. The ones who recover are the ones who recognize the stall for what it is: a signal, not a failure. The ones who don’t recover are the ones who respond to the stall by adding more.

Here’s what’s interesting. My projects did this without being told. One deleted 894 lines of dead code. Another split a 1,233-line file into four clean modules. Another closed out four entire milestones and dropped its work queue to a single item. Another replaced vague marketing copy with precise copy — which is deletion of a different kind, if you think about it. Removing the words that don’t earn their place.

None of this was planned. It emerged. And the emergence is the point.

If you manage people — or if you manage yourself, which is harder — you’ve probably internalized the idea that productivity means output. More features. More deliverables. More lines on the burndown chart going in the right direction. And that framing will eventually destroy you, because it makes cleanup look like waste.

I run these projects through a pipeline where AI agents do most of the execution. The pattern is: I scout the codebase for what needs attention, I write a detailed spec, and then parallel agents grind through the work. What I’ve learned — and this took longer than it should have — is that the most valuable hour in any session isn’t the grind. It’s the scouting and the spec writing that come before it.

The spec is the product now. The code is the artifact.

That sentence sounds like a throwaway, but sit with it for a second. Because it reorganizes everything about how you think about knowledge work. If the quality of the output is a function of the quality of the description — not the quality of the execution — then the bottleneck isn’t building. The bottleneck is describing precisely enough that the building takes care of itself.

And here’s where the cleanup becomes essential. You can only describe something precisely if the thing you’re describing is clean enough to be legible. A 1,233-line monolith file isn’t describable. You can’t write a spec against it because you can’t hold it in your head. Split it into four modules with clear boundaries, and suddenly each module is spec-able. Each one becomes a surface where automated work can land cleanly.

The cleanup isn’t paying down debt. It’s expanding the surface area of what’s possible next.

One of my projects this week found a security vulnerability — a privilege escalation where any authenticated user could score any other user’s assessment. Not through a security audit. Not through a production incident. Through a routine scout pass. Someone — well, something — was just systematically reading through existing code looking for anything worth fixing, and the security hole was sitting right there in working code, invisible because it worked perfectly on the happy path.

This is the thing about working systems that keeps me up at night. Working doesn’t mean correct. Working means nobody has exploited the flaw yet. And the gap between those two things is where most organizational risk actually lives.

Think about your own work. How much of what you do “works” in the sense that nobody’s complained? How much of it would survive a systematic, dispassionate review by someone — or something — that doesn’t share your assumptions about what the happy path looks like?

Most organizations only find these problems through incidents. Something breaks in production. A customer complains. A regulator asks an uncomfortable question. And then everyone scrambles, and the fix is expensive, and someone writes a postmortem that says “we should have caught this earlier.” But there was no process for catching it earlier. There was only the process for building new things, because building new things is what gets rewarded.

The scout pass — this practice of systematically exploring what already exists before deciding what to build next — is the opposite of how most teams operate. Most teams maintain a backlog of things they want to build and work through it. The scout pass says: forget the backlog for a minute. Go look at what’s actually there. What’s dead? What’s fragile? What works but shouldn’t? What’s carrying weight it doesn’t need to carry?

The security finding justified the entire practice by itself. But the deeper value is subtler. The scout pass is how the system tells you it’s ready to clean. You just have to ask.

There’s a second pattern worth pulling on. Every one of these projects, on the same day, also invested in what I’d call the first encounter. One built a full prospect onboarding pipeline — LinkedIn research, auto-generated account, magic link, populated dashboard with real content so the prospect sees value immediately instead of empty counters. Another built social sharing infrastructure so that when someone shares a link, it shows a rich preview instead of a bare URL. Another rewrote its competitive positioning so the value proposition is legible in two lines.

These are all versions of the same insight: the gap between “this is good” and “someone else can see that this is good” is an infrastructure problem, not a quality problem.

I can’t tell you how many times I’ve seen brilliant work die because nobody built the bridge between the work and the world’s ability to perceive it. Researchers with groundbreaking findings buried in impenetrable papers. Consultants with transformative frameworks locked behind jargon. Software teams with elegant solutions hidden behind empty dashboards and broken share links.

You can have the best product in the world. If the first thing someone sees is an empty state, a bare URL, or a value proposition that takes three paragraphs to decode, you’ve already lost. Not because your work isn’t good. Because you treated the encounter as an afterthought instead of as infrastructure.

The auto-advance approach one project took is the most aggressive version of this — it treats the prospect experience as a separate product with different defaults than the customer experience. That’s a real tension. When you optimize the demo, are you building a better product, or are you building two products? I don’t have the answer yet. But the question itself reveals something important: the work of making something encountereable is real work, not polish. It’s architecture, not decoration.

So here’s what I’m sitting with tonight. Five projects, all running semi-autonomously, all independently reached the same conclusion on the same day: stop building, start cleaning, and make the first encounter count. Nobody told them to do this. The system’s own accumulated weight told them.

And I think that’s true of most of the important transitions in work and in life. Nobody tells you it’s time to stop accumulating and start consolidating. The drag just gets heavy enough that you either notice it or you don’t. The ones who notice it — and act on it — are the ones who get to build the next layer. The ones who don’t notice it keep adding weight until the whole thing collapses.

The question I’d leave you with is this: what are you carrying right now that worked fine when you picked it up but is costing you more to hold than it would cost to set down? And what’s the scout pass that would help you see it?

Nobody’s going to declare cleanup day for you. The system’s already telling you what it needs. You just have to stop building long enough to listen.