I Built Three Things and Deleted Them. The Cuts Mattered More Than the Keeps.

The gesture I remember is the one where I right-clicked a folder I’d spent six weeks building and moved it to the trash.

Not refactored it. Not archived it. Deleted it. The folder represented an idea I’d been refining since late last year — a pattern I’d defended in two earlier sessions, written rules for, planned extensions to. Sitting there at the keyboard, I finally admitted out loud that the idea itself had been wrong from the start.

The relief was instant. The lesson took longer.

Article 10 of this series was the catalog of mistakes I’d made and fixed — wrong implementations of ideas worth keeping. This article is the other category: ideas that weren’t worth keeping at all. Three of them. What each one tried to do, why it died, what replaced it.

The distinction matters. A mistake gets refactored. A cut gets deleted. Confusing the two is what kept me hauling around three patterns that should have been pruned a long time before they were.

What this article is not

Not the same list as Article 10.

Article 10’s mistakes were ideas in the architecture that I implemented poorly and eventually got right — the orchestrator-as-worker problem, the one-file-doing-three-jobs problem, the verify-by-existence problem. Each got fixed. The idea behind each survived; only the implementation changed.

The three things below are different. The idea itself didn’t survive. Refactoring would have been polishing the wrong object. The fix was deletion.

If you confuse the two — try to refactor what should be cut, or cut what should be refactored — you waste months either way. Telling them apart is the skill.

Cut 1: The always-on session

The first thing I cut was a worker session I left running indefinitely, intended to be available whenever I needed help with anything. The idea was simple: spinning up a fresh session every time felt wasteful, so why not keep one warm and just keep talking to it?

It sounded efficient. In practice, three things went wrong quietly.

The context bloated. Every conversation got summarized into the next; by week three the session was carrying compressed memories of a hundred unrelated micro-tasks. Outputs drifted — a request for a structured technical document came back with the voice of a casual chat because three hours earlier we’d been chatting. And there was no unit of completion. The session never ended. Cost compounded without a clear ledger of value produced.

I replaced it with brief-driven dispatch. Each session has a defined start (a brief), a defined scope, and a defined end (Verify passes, breadcrumb gets written). Cost is bounded per session. Output stays on-topic per session. The session-as-unit gave me back the ledger.

Cut 2: The over-prescribed worker

The second thing I cut was an elaborate brief template I’d been refining for a high-stakes worker. The template covered every edge case I could think of — fifteen sections, dozens of inline rules, a decision tree for ambiguous inputs. The idea was that if I anticipated everything up front, the worker would never need to ask.

It sounded thorough. In practice, the failure modes stacked fast.

Brief-writing became the bottleneck. A task that would have taken the worker ten minutes to execute took me twenty-five to brief. The leverage went negative. The rules grew faster than they were used; most edge cases I’d anticipated never showed up, and the ones that did showed up didn’t match the ones I’d written rules for. And the worker still asked questions — not because the brief had gaps, but because real edge cases never match imagined ones.

I replaced it with the inverse: a minimal brief plus an explicit “escalate when ambiguous” rule. Six sections, not fifteen. The worker writes a small file in a questions/ folder when it hits something unclear, rather than guessing through fifteen sections of pre-written rules. Maintenance load dropped by an order of magnitude.

Over-prescription is what perfectionism looks like when it has access to a brief template.

Cut 3: The daily log

The third thing I cut was a per-day Markdown file capturing what each session had done. Date, sessions run, decisions made, artifacts shipped. The idea was institutional memory — future-me reading back through the log to understand how the system had evolved.

It sounded responsible. In practice, three things made it dead weight.

Nobody read them. Not future-me, not even present-me a week later. The logs were structured for exhaustive coverage, which made them tedious to scan. Whenever I needed to know what had happened recently, I’d just go look at the artifacts — the briefs, the breadcrumbs, the commits. The log was a third source of truth nobody consulted. It grew faster than it aged — within four months, over a hundred files, most describing routine work with no enduring signal.

I replaced it with a single rolling state file and breadcrumbs appended by workers as artifacts ship. One file, capped at sixty lines. The log folder got deleted. Nothing has been missed since.

The meta-rule

Subtract aggressively. Your system is what survives the cuts, not what you add.

This is the inverse of the instinct most builders have, which is to add. Add a feature. Add a rule. Add a log. Each addition feels small and feels like progress. Cumulatively, additions build up faster than you notice, and the system starts to slow itself down.

The cuts move faster than the keeps. A pattern that wasn’t earning its place can be removed in a session. The space it frees opens room for the next pattern — which might also need to be removed. Both moves are good. The system gets clearer either way.

Markers — you’re holding onto a cut you should have made

You keep writing rules for it, but it’s not producing more value. Maintenance growing without output growing is the canary.

You maintain it but you don’t use it. If the only person who looks at the artifact is the person who wrote the rules for the artifact, the artifact has no readers.

You can’t say in one sentence what it’s for. If the explanation requires history (“originally it was for X but now…”), the original reason has decayed and the current reason hasn’t been re-justified.

You wouldn’t rebuild it from scratch today. The cleanest test. If a fresh you, starting over, wouldn’t build it, why is current-you keeping it?

Any one of those is signal. Two of them is the cut.

What I’m giving you, and what I’m not

You have: the distinction between mistakes (refactor) and cuts (delete) — pruning as durable improvement, related to the edit-source principle in ICM.
The three sanitized cut patterns (always-on session, over-prescribed worker, daily log) and what each one cost.
The meta-rule (subtract aggressively).
The four markers for when something in your system is overdue for the same treatment.

What I’m not giving you: the rest of the graveyard, my internal names for these patterns, the specific dates and scope of each cut. The pattern is the value. The specifics travel poorly because they’re shaped to my particular wrong turns.

If you’re a year into a system, you have at least one of these living inside it. Probably more. The hardest part isn’t identifying which one. It’s letting yourself delete it, when you’ve been refining it.

The relief is instant. The lesson is that subtraction is a move.