Last month I opened my own AI coding setup and could not tell you what half of it did.
Hundreds of small rules, hooks, and helpers, added one reasonable decision at a time, until the whole thing was a museum I was afraid to touch.
Nothing in it was wrong. That was the problem.
Every piece had a good reason the day I added it. None of them ever earned a reason to leave.
So they all stayed. Forever. Quietly piling up.
Let me make one claim plainly, because it cuts against how most of us build.
Growth is not progress. For a personal system, unbounded growth is decay wearing a nice outfit.
The moment it broke
My setup crossed a number I am almost embarrassed to say out loud.
Past five hundred separate pieces. On a system that serves exactly one person. Me.
What I built to save time had started costing me time. Every new idea had to be checked against a surface area I could no longer hold in my head.
Self-cleaning routines I wrote to keep things tidy had quietly stopped running, because I kept adding faster than they could process.
That is the tell. When maintenance cannot keep up with additions, the system has become a second job in disguise.
The one rule
My fix was almost insultingly small.
Every category got a hard ceiling. A maximum count of rules. A maximum count of hooks. A maximum of each kind of thing.
Then one line of policy on top.
To add something above the ceiling, you have to remove or merge something first.
Plus one means minus one. No exceptions, no "I will clean it up later."
Later never comes. Later is the lie that built the museum in the first place.
Why a dumb cap beats good intentions
A ceiling moves the hard question to the right moment.
Before, I asked "is this new thing useful." The answer is almost always yes, because I would not be reaching for it otherwise.
After, I ask "is this new thing more useful than the weakest thing I already have."
That second question is ruthless, and it is the one that matters.
Most days the honest answer is no. When the answer is no, I have learned something for free. The new thing was never a need. I wanted the feeling of adding it.
Merging beats deleting
A cap forces more than deletions. Most of the time it forces merges.
When two rules cover the same ground, the ceiling makes me notice. I fold them into one that is sharper than either was alone.
Consolidation was never my goal. The constraint did it for me. That is the quiet bonus of a hard limit. Nothing keeps piling, and what survives gets squeezed tighter.
The trade-off I did not expect
Here is the part nobody warns you about.
Sometimes you sit down to add something genuinely good, and you cannot find a single thing worth removing to make room.
Your first instinct is to bump the number up. Resist it.
That pause is information. Your own system is telling you the new thing matters less than it felt thirty seconds ago.
I have killed more bad additions in that pause than any review process ever caught.
This is bigger than a setup
The same question keeps reaching me from developers this year, in different words.
What do we actually hold onto in 2026, when a model can generate more of everything in seconds.
Here is my honest answer.
Scarcity flipped. Making more is easy now. Deciding what does not get to exist is the hard part.
We are all about to be buried in generated rules, generated configs, generated helpers, generated abstractions, every one of them individually reasonable, none of them ever pruned.
Whoever wins the next few years will win on what they refuse to keep.
A cap is that line, made mechanical so my future tired self cannot argue with it.
What this did not require
Here is what it was not.
You cannot install this. There is no clever script I am about to paste here. What changed was a number, a rule, and the discipline to let the number win when I am tired and want to add one more thing.
The mechanism is the easy part. Letting it tell you no is the whole game.
My setup stopped growing the week I capped it.
Every week since, the thing has gotten a little better.
Your turn
What is one thing in your setup you keep meaning to delete but never do.
If this was useful
I work through this in public, the wins and the freezes both, mostly on LinkedIn and YouTube. If the real version of building in the open is useful to you, that is where it lives. LinkedIn, YouTube and X under Mirza Iqbal, and the work at next8n.com.
