The Other Half of AI-Augmented Development: Knowing What to Kill
AI lets a single developer ship a lot of small tools. Today I spent an afternoon pruning 21 of my own — and learned what makes a project earn its keep.
A confession before I start
By this morning I had roughly fifty active projects on my Mac Mini. Some were genuinely useful — a few are paying clients, a couple are the kind of internal tooling I rely on every day. But a lot of them were just… there. Running launchd jobs nobody opens. Dashboards on ports I haven’t visited in months. Three different tools that all generate Cisco config diffs because I kept building “the right one” instead of finishing one.
If you’ve been writing software for any length of time you know this feeling. The folder of side projects that started with energy and ended with neglect. The “I’ll come back to this” that turned into “what was this for, again?”
This afternoon I cut a third of it.
What the audit actually looked like
I asked four exploration agents to run in parallel — each taking a slice of the portfolio (revenue and apps, networking, gambling and investments and personal, infra and clients). For every project they found, they pulled the last commit date, checked whether anything was running, looked at recent log activity, and made a recommendation: keep, fix, pause, or archive.
This is the part the discourse around AI-augmented development tends to skip. Everyone wants to talk about how fast you can ship a new thing. Almost nobody talks about how fast you can audit what you already have. They are the same skill applied in opposite directions, and the second one matters at least as much.
By the time the four reports came back, the picture was sharp. About fifteen projects were genuinely active — they earn attention or money, they’re being touched, they have a visible reason to exist. The rest fell into three buckets: paused with a clear unblock condition, decisions I’d been avoiding, or simply dead weight.
What I learned from the dead weight
The networking category was the worst offender. Eleven projects in there overlapped with each other. Three different tools to do config diffs. Two to validate device configs. A standalone topology generator that does roughly what one of the others can already do. Each of them was, in its moment, the right call. The problem is the moment passes, and the project lingers.
The pattern that finally became obvious is this: I tend to build slices of a problem until I eventually understand the problem well enough to build the substrate. The substrate replaces the slices. But the slices don’t archive themselves. They sit there with their own launchd jobs, their own ports, their own forgotten READMEs. This morning a tool I shipped two days ago — an analyst that reasons over network captures and intent docs — quietly subsumed seven of those slices. They could go.
What the audit caught that I’d missed
Three things, embarrassingly:
A trading bot was bleeding money. Real money, on a real exchange, with insufficient-funds errors stacking up in the logs every day. Nobody told me. The audit pulled it up immediately and I shut it down within ten minutes.
An OAuth pipeline I thought was working was silently failing every five days. The fix needed a separate path that I wouldn’t have found without forcing myself to look.
And my own infrastructure docs were lying to me. A service was listed as “healthy” in the project root file even though it hadn’t been running for weeks.
None of those were going to surface during normal work. They surface when you stop building long enough to look around.
I caused one of my own outages along the way
It would be dishonest to skip this part. While archiving the scraping project, I moved a launchd plist whose label was com.cloudflare.scraping-api. Read the name; assume it does what it says. It did not. That single plist was actually running my main Cloudflare tunnel — every public hostname I host, including my own website — and when I archived it, all of those hostnames went dark for about thirty minutes before I noticed.
I fixed it, restored the tunnel, and saved a note in my memory system so the next audit doesn’t fall for the same misleading name. That is the loop. You break things, you write down what broke and why, you don’t break it the same way next time.
What’s left, and why it’s enough
The fifteen projects that survived the cull are the ones I actually care about — the agency portfolio you’re reading right now, a handful of public tools, two newly-shipped internal assistants, an active client engagement, and the work I do for a Fortune 50 telecom on the side. The rest is paused with clear conditions for revival, or archived with the option to bring it back.
If you’ve been watching your own folder of half-projects with a vague sense of guilt, I’d recommend the audit. Not as a shame exercise — as a clarity one. AI is very good at building. It’s also very good at telling you what’s already there. Most of us under-use the second one.
The hard part is being willing to look.