I wrote a detailed rules file when I started. Two hundred-odd lines, every convention I could think of. The theory was: the more it knows, the better it behaves.
It behaved worse.
Why length backfires
That file gets loaded in full at the start of every session. Two consequences:
- Important rules get buried in noise, and it starts ignoring them
- It eats a chunk of your context before you've typed anything
There's a test I now use on every line: "if I delete this, will it make a mistake?" If no, delete it.
First pass took me from 200 to 80. All the "write clean code" / "consider performance" style lines went — it already does that, writing it down just occupied space.
Second pass, 80 to 30
The 80 still had a lot of "stuff I assumed it needed to know" — which libraries we use, roughly how the directories are organized.
It can figure that out by reading the code. Writing it in the rules file is pure duplication.
I also found several rules I'd added after early mistakes, where the underlying issue had since been fixed in code. The constraint outlived its reason. Easy to forget those are in there.
What's left
- The actual build and test commands (it can't guess these)
- A handful of style choices that differ from community defaults
- Non-obvious behaviour in two specific modules
- Required env vars
- Branch and PR naming
That's it. Thirty lines.
Anything that only matters in specific situations — release process, migration checklist — I moved into skill files that load on demand. Once a month, no reason to read it every session.
Side effect I didn't expect
Baseline consumption per session dropped noticeably. Between that and clearing context between tasks, I dropped a subscription tier and stayed comfortable most months.
Which brings up the thing I actually want to mention, because it's what made dropping a tier feel safe rather than reckless.
My usage isn't flat — busy months are roughly three times the quiet ones. Subscription pricing forces you to pick a tier for the peak and eat the waste, or pick for the average and get stuck mid-sprint. There's no "just right" option on offer.
I've been covering the peaks through Asale instead. Unused subscription capacity gets listed by people who aren't going to burn it; people who need it draw from it. Three things made it genuinely useful rather than just a cheaper option:
- Pricing is legible. Per million input/output tokens, with the percentage of list price shown per model, so you can decide in ten seconds whether it's worth it for the task in front of you.
- It's vendor-agnostic. When I want a second opinion from a different model on an architectural call, I don't need a second subscription sitting there for the other 27 days of the month.
- It's genuinely two-way. Quiet months, the capacity I'm not using can go the other direction instead of expiring. That's the part that made the tier drop a net win rather than a gamble.
Before trying it, know the tradeoff: requests relay through another user's client, so the payload is visible at that hop — not end-to-end encrypted. They say so plainly on their homepage, together with a note that sharing subscription capacity may conflict with upstream terms. Clear enough boundary: personal and open source work, fine. Company code, not a chance.
Search asale on GitHub for the client. Source being open mattered to me here, since requests transit someone else's machine.
If you've got a rules file you're happy with, I'd genuinely like to see roughly how long it is. I suspect most of us are still writing too much.
Top comments (0)