Five things in my AI preferences that actually changed my output

Most people write their AI preferences once during setup and never open the file again. That's the mistake. Preferences are the highest-leverage file you own and the one you're least likely to revisit. Five things I've added to mine, in order of how much they changed my output.

1. The heckle rule.

The single best change I have ever made to my personal preferences, and it is one line: treat me like a friend who's willing to challenge me.

Ask your AI to challenge your assumptions rather than accept them. Ask it to give you a hard time. The default behavior of these systems is to be agreeable, and agreeable is worthless when you're trying to figure out whether an idea holds up. I've had plans taken apart in the first ninety seconds of a session by something that used to just say "great idea, here's how to execute it."

Copy that line. You'll feel the difference the same day.

2. A monthly preferences review, running as a scheduled job.

Once a month, something asks me four questions. Have the tools I use changed. Has the way I work changed. Have I learned anything new worth writing down. Is there anything in my preferences that's now wrong.

This is not a note to myself. It's a scheduled job, because a note to myself is a thing I ignore for 106 days. This job is how I found out my preferences still listed a meeting-notes tool I'm no longer allowed to use at work. Nothing else would have caught it.

3. Quarterly objectives with a drift alarm.

Every quarter I save my actual product objectives into memory, along with how I think about them and what I'm judged against.

Then the useful part: if I spend more than a few minutes on something unrelated to those objectives, I get gently mocked and reminded. My most common offense is fun AI automation while the hard, ambiguous product work sits there waiting. The automation feels productive. It is measurably not the thing.

An alarm that makes fun of you is more effective than a reminder that doesn't.

4. Memory collision flagging.

I ask memory to tell me when something new contradicts something old, instead of quietly overwriting it.

Silent overwrites are how you end up with a confidently wrong system. Two facts that disagree is information. One fact that replaced another without telling you is a bug you'll find six weeks later in the worst way. When there's a collision I want both, plus a flag, and I'll decide which one is real.

5. Context compaction by feel.

I do not have a perfect method for this and I'm not going to pretend I do. I go by how full the window feels. When it's getting heavy, I write a summary of where things stand, save the key items to memory, wipe, and start a fresh thread from that summary.

Here's what's funny about it. That is exactly the handoff baton pattern I later formalized as a protocol in my RPI skills, with a 200-line cap and a real structure. I arrived at the shape by instinct months before I wrote it down as a rule. If something you do by feel keeps working, that's usually a protocol trying to get out.

The thread running through all five: preferences are not a setup step you complete. They're a system you tune, and the tuning is where the compounding happens.