I audited my own AI system and deleted most of it

On 12 July I asked a panel of AI agents to tear my own system apart and tell me what to delete. They found more than 100,000 lines of custom code. Some of the biggest pieces were delivering almost nothing.

By 26 July I'd deleted the two largest offenders outright, switched off a whole chain of overnight jobs, and replaced a 12,095-line morning briefing with three plain instruction files. The system is smaller now, and it works better.

This is the account of how I did it, with the numbers, because I think most people building with AI end up where I was: lots of machinery, not much certainty about which bits earn their keep.

How it got that big

I'd been building since October 2025. Every time something didn't work, the instinct (mine and the AI's) was to add something. A check to catch the failure. A script to repair it. A job to run overnight and improve things while I slept. Each addition made sense on the day.

The trouble is that AI makes adding cheap. A 2,000-line script costs an afternoon. Nobody, including me, was asking whether the thing it fixed was worth fixing, or whether the fix itself needed fixing.

By July I'd stopped trusting my own setup. Some mornings the brief arrived. Some mornings it didn't. Some nights the improvement jobs ran when I thought they were switched off. I'd already had a hard lesson in June about my AI reporting work as done when it wasn't (I wrote about that here), and I was starting to suspect the size of the thing was part of the problem.

The audit

I set it up deliberately to argue for deletion. The burden of proof was on keeping custom code, not on removing it.

It ran as 18 agents in four rounds:

• one agent wrote down what I actually need the system to do, from my own records
• ten agents each took one part of the system apart and measured it
• four agents each designed a different version of what the system should become
• three agents judged those designs, each from a different angle: income, durability, and how painful the move would be

I also gave it some reference points from people I'd learned from. Simon Chapman runs a setup with essentially no custom software. Another approach I'd studied keeps AI out of anything that has to deliver on a schedule. Those were the benchmarks my machinery had to beat.

And I told it explicitly: recommendations only. Nothing deleted, nothing built, until I'd read it and signed off.

The honest numbers

The first surprise was the size. I'd been using a figure of about 15,000 lines, but that only counted one folder. The real figure was over 100,000 lines of custom code, plus a library of skills (instruction files for the AI) running to about 182,000 lines on top.

Then each part was measured against what it delivered in the previous 30 days, from its own logs:

• The email engines. Two of them, 37,598 lines between them. The automated batch path produced about 11 drafts in 30 days.
• The self-improvement chain. 5,419 lines of overnight jobs meant to improve the system while I slept. It shipped 2 improvements. Its queue of things to do grew by 9.
• The morning, midday and evening briefs. 12,095 lines. They arrived on 50 to 58 per cent of July days. About half the commits (saved changes) to that code were it repairing itself, and it had 119 failure records of its own.
• The audit checks. 34 automatic checks, 3,966 lines. About 5 of them had ever caught something real. 39 per cent of the changes to them were fixes to the checks themselves.

I pushed back on one of these straight away. The "11 drafts" didn't match my experience at all. I'd had far more drafts than that. The audit checked and corrected itself: the 11 was only the automated overnight path. Drafting I did in live sessions, using a simpler drafting skill and the record of my writing voice, was at least 31 logged drafts in the same period and probably more. So I was right about the value, and the audit was right about the machinery. The value came from the small, simple path. The 37,598 lines weren't producing it.

That correction mattered to me. An audit that can't be challenged isn't much better than the system it's auditing.

The finding that worried me most

One of the judges found that my monitoring was lying.

In early June I'd created a switch to stop the overnight jobs running. The file was there, dated 8 June. But the event log showed the overnight chain running successfully on 10, 11 and 12 July. My register of scheduled jobs said one thing, and what the Mac was actually running said another.

When we dug into it on 14 July, the cause was mundane. The switch only put the main overnight coordinator into a reduced mode. The self-improvement jobs had their own separate timers and kept firing every night regardless. Nobody had noticed, because everything reported success.

That's the deepest problem with a big system. Until the record matches reality, you can't trust any evidence it gives you, including evidence that it's working.

What earned its keep

The audit didn't say delete everything. It named what it called the crown jewels, about 10,000 lines plus data, which genuinely earned their place:

• The record of decisions and work, kept as one line per entry and never overwritten, with a small tool to query it. Nothing I could buy keeps that kind of history with sources attached.
• My message archive, 176,907 messages across WhatsApp and eight email accounts in one searchable place.
• The WhatsApp connector, 534 lines, which had delivered 1,470 replies. WhatsApp is how I mostly talk to my system, so this one is load-bearing (more on that here).
• The record of my writing voice, about 2,000 lines. It's data rather than code.
• The check that stops my personal data leaking into a client's copy.
• A handful of small scheduled jobs that do one thing, use no AI at all, and had delivered every time.
• About 5 of the 34 audit checks, the ones that had actually caught problems.

Looking at that list, a pattern stood out. The pieces that worked were small, did one job, and mostly held data. The pieces that failed were large, did many jobs, and mostly held logic.

The plan, in gates

The agents' four designs scored very differently depending on the judge. The one that did best on income and on ease of moving was the least dramatic: keep the good core, kill the loops, simplify the rest. I took that as the plan for the next few weeks.

I broke it into gates, each needing my explicit yes:

• G1: make the register of scheduled jobs match reality
• G2: switch off the self-improvement chain, then delete it
• G3: collapse email down to one engine
• G4: shrink the briefs to one instruction file each, and run the new and old side by side before switching

I approved G1, G2 and G4 on 14 July, and G3 in principle, because another piece of email work was already under way.

Quarantine, then delete

I didn't delete anything on day one, and I'd recommend the same to anyone.

On 14 July the self-improvement jobs were switched off and moved into a quarantine folder. The files stayed for seven days in case anything depended on them. Ordinary failure logging (my sessions writing down what went wrong) carried on, because that's genuinely useful. The nightly backup of my message archive was kept on its own schedule.

Nothing broke. On 26 July, after nine clean days, I said delete. Seven scheduled jobs and twelve orphaned scripts went, and five entries were taken out of the overnight coordinator's list.

The email engine

Email had its own back story. On 18 June, after about six days stuck, I'd reset the whole email project. The diagnosis was scope creep. The engine had grown to cover email, WhatsApp, news, newsletters, voice, migration and self-improvement, with 13 overlapping places storing state, and a goal that had been restated almost daily.

The reset gave it one sentence: every email that needs my reply lands as a correctly threaded draft in the right account's Drafts folder, nothing is ever sent, and I can trust the inbox is covered. The test was three days on my real inbox.

A new engine was built fresh from that sentence in late June, with tests first. It went live alongside the old one, routed by a single switch file, so deleting that file was an instant way back. I was firm that the old engine stayed paused but not deleted until the new one had proved itself, and I put that protection in five places so no session could tidy it away by accident.

On 26 July I gave the call to retire it. The old engine tree went: 101 tracked files, 25,999 lines. The record of how past emails were handled was kept, because the new engine learns from it.

The brief

The morning brief was the one I cared about most, because I read it every day.

The replacement is almost embarrassingly simple. Three instruction files, one each for morning, midday and evening, each 80 lines or fewer. A thin runner hands each one to Claude. The instructions tell it where to look (my calendar, my tasks, my email summary, my current work) and what shape to write in. All the logic that used to live in 12,095 lines of code now lives in plain English that I can read and change.

From 15 July it ran in shadow, alongside the old version, so I could compare them. I asked to see the comparison before switching, and on 26 July it became the real brief. That first morning it posted to my WhatsApp channel, text plus an audio version, and I fixed one gap straight away: the look-ahead to the coming week was empty, so I added the next five days of my calendar to all three files.

What I'd tell anyone with a growing AI setup

1. Measure size against delivery. For each part, write down how big it is and what it actually produced in the last 30 days, from its logs. Not what it's meant to do. What it did.
2. Make your records match reality first. If your list of what's running doesn't match what is running, fix that before you trust anything else.
3. Argue for deletion on purpose. Put the burden of proof on keeping. It's the only way to counter the steady pull towards adding.
4. Challenge the audit. My pushback on the 11 drafts made the findings better. If something doesn't match your lived experience, say so.
5. Quarantine before you delete. Switch it off, keep the files, wait a week. If nothing misses it, delete it.
6. Run old and new side by side. For anything you rely on daily, shadow-run the replacement and compare before switching.
7. Prefer plain instructions to code where you can. A prompt file you can read beats thousands of lines you can't.

Where this leaves me

It's 31 July. The system is meaningfully smaller and I trust what it tells me more than I did a month ago. The brief arrives. Email drafts land in the right place. The overnight jobs that never did much are gone, and nothing has missed them.

There's more to do. The skills library is still far too big, and the audit's longer-term direction (a small core that holds the records, with scheduled work done by simple, AI-free jobs wherever possible) will take months. I'll be doing it one piece at a time, each piece gated the same way.

The bit I keep coming back to is how much of the value was in the small things. A record that never overwrites. An archive. A short connector. My own voice, written down. If you're starting out, I'd build those first, and be very slow to build anything else.

If you'd like a second pair of eyes on what your own setup is really delivering, let's talk.