I Deleted an Entire Enum
I deleted an entire enum last month and the codebase got better.
Here's the part worth sitting with before you nod along: it was good code. Not tolerable code, not the-intern-wrote-it code. Good code, by every rule a competent human engineer would hand you. That's the whole story. The thing I tore out was correct, and it had to go anyway.
The monster nobody built
I build a tool that lets AI agents transform code — rename this, extract that, inline the other thing, dozens of operations, across a lot of languages. For a long stretch, every one of those operations lived as a variant in a single enum called RefactorOp. It grew to nearly 180 variants.
And every one of those variants got handled in a single match statement. One function. Sixteen hundred and eighty-nine lines.
By a wide margin, the most complex thing in the entire codebase. Every time I ran a structural audit, it came back at the top of the list. The number-one complexity hotspot. For months. It sat up there like a tumor with tenure.
Now — nobody designed that. You don't sit down one morning and type a 1,689-line function. Nobody does. It accreted. Each new operation added a variant. Each new capability added an arm. Every single commit was small, reasonable, reviewable — the kind of change you approve without a second thought. And the sum of a thousand reasonable changes was a monster. The worst kind, too: the kind you can't see coming, because no single commit is ever the problem. The problem is the pile.
The cost wasn't the number
Here's what actually hurt, and it wasn't the complexity score.
Every operation lived in the same two files — the enum and the match. So every change to any operation collided there. Two agents adding two completely unrelated operations, at the same time, on different features, touched the exact same two files and stepped on each other. The architecture funneled all work through one door, one change at a time.
I had built a machine for doing many things in parallel, and then I'd bolted a turnstile onto the front of it.
The uncomfortable part
I built it that way on purpose. Because it's the textbook-correct design for a human.
One exhaustive enum. The compiler checks it for you. One place — one file — where you can see every single operation the system supports, top to bottom. Add a variant and the compiler dutifully lists every branch you forgot to handle, and refuses to build until you handle it. Nothing falls through the cracks. Nothing goes stale silently.
For a human reading the code, that isn't bad engineering. That's good engineering. That's the thing you'd point a junior at and say, see how clean this is, see how the compiler has your back.
But here's the thing I had to actually say out loud to myself, in the desert, at some ugly hour: humans aren't the primary authors of this codebase anymore. Agents are. I am one guy. The commits are written, overwhelmingly, by machines I'm pointing at the problem.
And every single property that made that enum pleasant for a human made it hostile to an agent. The giant shared file. The central dispatch. The exhaustiveness that turns every tiny addition into an edit of the whole. A human wants the map — the one file where everything is visible. An agent doesn't read the map. An agent reads the ten lines it needs, makes its change, and gets out. What it needs is to not collide with the other nine agents doing the same thing. The map isn't a comfort to it. The map is the turnstile.
So I inverted it
Operation by operation, I moved each one out to register itself.
Every operation lives in its own file now. It declares what it is and how to run it, in place, and a compile-time registry sweeps them all up automatically. No central enum. No central match. Nothing to edit in the middle. Adding an operation touches exactly one new file and nothing anyone else is touching.
Then I deleted the old structure. The whole thing.
The 1,689-line match shrank to an 83-line residue while I rewired it — and once the last operation was off it, I deleted the 83 lines too. The enum's own file lost 62% of its mass on the way out. And the dependency graph never inverted once: the crates still flow one direction, top to bottom, exactly like before. I took out the load-bearing wall and the house didn't lean.
The lines aren't the win, though. Cutting 1,600 lines feels good for about a day. The win is this: two agents can now add two operations at the same time and never touch the same file. The bottleneck that serialized every piece of work in the system is gone. I didn't optimize it. I didn't shave it down. I deleted the entire category it belonged to.
The recursive part
Here's what I keep coming back to.
I found all of this by pointing the tool at itself.
The tool is act101 — it's the thing I've been building out here, the semantic layer that sits under AI coding agents and gives them real operations instead of blind text edits. Part of what it does is analyze: read a codebase and tell you where the structure is knotting itself up. So I aimed it at its own source. The worst knot it found, out of everything, was this enum. My proudest, cleanest, most textbook-correct design was the single worst structure in the building, and my own tool said so to my face.
So I used the rest of act101 to take it apart — that's the act — and when the dust settled, the parity checks confirmed every operation still did exactly what it had always done. That last part matters as much as the cut: attest. Analyze found it, act removed it, attest proved nothing broke on the way out. The tool found its own worst structure, dismantled it, and signed off that it hadn't lied to anyone in the process.
I started using the tool to build the tool, and that was when everything changed. This is what I meant.
What you're keeping for readers who left
The lesson has genuinely stuck with me, and it's bigger than one enum.
"See everything in one place" is a human value. It's a beautiful one. It's also, increasingly, a value nobody's around to collect on. An agent doesn't read the whole file. It doesn't need the guided tour. It needs to make its change and not crash into the other twelve changes landing in the same minute. The exhaustive, centralized, compiler-checked map — the thing I was so proud of — was a monument to a reader who no longer opens the file.
act101 was good code by every standard a human ever wrote down. It read its own source, found its own worst structure, and I deleted it. The codebase got better the moment it was gone.
Which leaves me with the only question I think is actually interesting here: what else am I keeping around for readers who aren't reading anymore?