Stop Copying Other People’s AI Setups. Build One That’s Actually Yours.

There’s a copy-the-setup economy now. It shows up everywhere:

• People post their CLAUDE.md files like recipes.
• Creators ship plugins and tell you to install them.
• Threads fill up with “here’s the system prompt that 10x’d my output, paste it in.”

The promise is always the same. This works for me, so copy it and it’ll work for you.

Almost none of it is actually yours.

Not because the setups are bad. Some are great. The problem is simpler: a rule you copied never had to prove itself to you, on your work. You took someone’s answer without their evidence, and now you follow it because it sounded right in a thread.

That isn’t a best practice. It’s a guess that sounds confident.

So I’m not going to hand you my config. That would make me the exact thing I’m warning you about.

I’m going to hand you a process. A repeatable way to put any rule on trial, yours or someone else’s, and keep only the ones that survive your own results.

I ran it on my own setup. It convicted the rule I was surest about and exposed two-thirds of my “best practices” as untested habit. Those results prove the method works. They aren’t the point. The method is the point, and you can run most of it today.

The Fuzzy Stuff Is Worse

Here’s what people miss.

For coding, there are at least decent shared playbooks, and the feedback is loud. Tests pass or they don’t. The build is green or red. Copy a coding rule and the world tells you fast if it was wrong.

Now think about the work that’s actually yours:

• How you write.
• How you run your day.
• How you want your AI to talk to you.
• How you triage your inbox, structure your research, plan your week.

Nobody wrote the guide to your job, because it’s yours. The generic rule you copied was tuned for someone else’s brain. Copy it here and it’s worse than useless, because the feedback is fuzzy and you’ll never catch it quietly costing you.

The weirder and more personal the workflow, the more the only good config is one you grew yourself.

I didn’t learn this from code. I learned it from everything around the code. Three of mine, none of them programming:

• My writing voice. I keep a voice standard for my articles. It opens with a line I had to earn: “This isn’t a style guide. It’s calibration.” Short paragraphs. Single sentences for emphasis. Enthusiasm, not flexing. I didn’t get those from a writing Medium articles plugin or post. They came from noticing, across a dozen drafts, which moves made a piece land and which made it read like a brochure.
• My time estimates. One rule: never estimate in calendar days, estimate in active working hours/sessions, then compress by three to five times (Claude Code time). That number isn’t borrowed. I measured it against my own past projects. The rule exists because the default time estimates calculate completion in normal handwritten development time, not a fleet of AI agents running in Claude Code time.
• My personal operating system. I keep a config for myself, not just my tools, and it has a changelog. Every entry records three things: what changed, why, and what triggered it. I built an evidence loop for my own life before I ever pointed one at my code.

None of that came from copying a person. It grew from watching my own work and keeping only what kept proving true.

That’s the whole philosophy. The steps just make it deliberate instead of accidental.

Every Rule Is a Defendant

Every instruction you give an AI, or yourself, is a claim about reality. “Research before you build.” “Outline first.” “Batch your email.” Each one quietly says: doing this beats not doing it.

That’s a hypothesis. And a hypothesis you’ve never tried to disprove isn’t knowledge. It’s faith.

Doesn’t matter if you earned it the hard way or lifted it from a popular repo. Until something could have proven it wrong and didn’t, it hasn’t earned its spot.

So the whole process is one habit on repeat:

• Turn each rule into a claim that could lose.
• Go hunting for the evidence that would make it lose.
• Keep what survives. Cut what breaks. Stop calling the rest law.

Hand It to the AI

You don’t do this by hand. The raw material is text, and your AI eats text. Here’s the prompt-shaped version of each step.

Step 1: extract every rule as a numbered hypothesis.

Point it at every place you’ve written down how you work: config files, custom instructions, saved memory, style guides, project briefs.

Pull out every rule. Every always / never / prefer / X-before-Y /
if-X-then-Y statement, and every claim like "saves 30%." List each
as a numbered hypothesis. Don't soften them, don't merge them.
I want to see the size of the pile.

The pile is the first finding. My first run, I had sixty-seven. Sixty-seven rules I obeyed and had never once questioned. You’re running on more unexamined assumptions than you think, and stacking them up is worth the afternoon by itself.

Step 2: make each one falsifiable.

This is the step everyone skips, and the one that does the work. Before looking at any evidence, define what would prove each rule wrong.

For each rule, write a pass line and a fail line.
Pass: a specific outcome that supports it.
Fail: a specific outcome that refutes it.
If you can't write a fail line, flag the rule as untestable.

If nothing could ever refute a rule, it isn’t a hypothesis. It’s a belief, and you should know that about it.

“Outline first” feels untestable until you force it. It passes if outlined drafts need fewer rewrites. It fails if they take longer, or come out stiff and you rewrite anyway. Now it can lose. Design every test so the rule can lose, or you learn nothing.

Step 3: mine the evidence you already have.

You don’t need new experiments. You’re sitting on months of them. Every time you followed a rule or broke it, something happened, and a lot of it got written down somewhere.

Go through my history. For each rule, find concrete cases that hit
the pass line and concrete cases that hit the fail line. Quote them,
count both. I especially want the times breaking a rule caused a
problem, and the times following it cost me with no payoff.

That last part matters. People only look for evidence that agrees with them. The gold is the rule you followed religiously that quietly never helped.

Step 4: score it against a bar you set in advance.

Don’t grade in your head. You’ll cheat. Make the count decide.

A rule needs several independent supporting cases and zero clean contradictions before you trust it. One solid contradiction kills it. (More on scoring below, because this is where you should build your own formula instead of borrowing mine.)

Step 5: promote, cut, or label.

Three buckets:

• Earned it. Cleared the bar, no contradictions. Keep it. Now it’s real.
• Refuted. A real contradiction. Cut it, or rewrite it narrower so it stops lying. Log why. That learning is worth more than the rule was.
• Still unknown. Not enough evidence either way. The honest bucket. Stop calling it proven.

That last bucket will be bigger than you want. Mine held forty-seven of the sixty-seven. Good. “I don’t know yet” beats “I was sure for no reason.”

Where Your Evidence Lives

The method lives or dies on Step 3. So here’s the important part (that will produce a lot of fun data): how to get at your own track record, wherever you work.

• Claude Code. The richest trail by far. Your full session transcripts sit as files on your machine. Your git history is a minute-by-minute log of what you did and undid. Any notes or memory system is a ready-made list of lessons. Point it at all of it and let it read.
• Claude on the web or app. On a paid plan, just ask it. With “Search and reference chats” on (Settings, then Capabilities), Claude will dig through your past conversations: “Search our old chats for every time we dealt with X, and tell me whether it helped or hurt.” You can also export your full data from settings on any plan.
• ChatGPT. Two sources. Your custom instructions and saved memories are your config, so mine them in Step 1. For history, go to Settings, then Data Controls, then Export Data. It emails you a zip with a conversations.json of everything you've ever discussed. That file is your evidence.
• Gemini. Your activity is logged in your Google account. Pull it through Google Takeout, but watch the trap: the box labeled “Gemini” is for custom Gems, not your chats. Your actual history is under “My Activity,” as “Gemini Apps.” Your Saved Info is the config. The activity log is the evidence.
• System prompts and custom instructions, everywhere. These are rules too. Often your most powerful ones, and the least examined. Put them on trial with the rest.

The power move: export, then run Claude Code on it. This is the bridge for everyone. Even if you live in ChatGPT or Gemini, export your history, drop the files in a folder, and point Claude Code at it. Now a real agent can read thousands of your past conversations, tag every case for and against each rule, and tally it up. You get the deep version without living in a terminal. Web for the work, Claude Code for the trial.

For fuzzy work, how do you even know it worked? Code has clean signals. Writing and life don’t, so you read softer ones. They’re more reliable than they sound:

• Did you keep doing it, or quietly stop? Abandonment is refutation. If your history shows you ignoring a rule within a week, the rule lost.
• Did the output need fewer passes? Fewer rewrites, fewer redos, fewer corrections is real signal.
• Did the thing you were guarding against stop happening? Did the piece get read, did the client say yes, did the email get answered?

Build Your Own Scoring

Now the part I most want you to take. Do not copy my scoring. Copying my numbers is the same mistake as copying my config.

For the record, here’s the dial I used, so you can see the shape and then build your own. Each rule starts at zero. Each clean supporting case moves it a quarter of the way to certainty:

new_confidence = confidence + (1 - confidence) * 0.25

One case gets me to 0.25, then 0.44, 0.58, 0.68, 0.76, and the sixth lands at 0.82, where I graduate the rule. A contradiction cuts hard the other way.

That 0.25, that “six cases,” that one-strike rule: those are my knobs for my work. Yours should be different. How to think about it:

• Weight evidence by what it costs you. A real disaster (a leak, a lost client, a blown launch) should outweigh a stack of small wins. Don’t treat all evidence as equal when the stakes aren’t.
• Some rules are zero-tolerance. “Never hardcode a secret” gets no confidence curve. One violation and it’s binary law forever, because the downside is unbounded.
• Some rules are genuinely a coin-flip, so let them be. “This subject line gets more opens” will never be always-true. Your bar there isn’t “zero contradictions,” it’s “wins clearly more than it loses across enough tries.” Track a rate, not a verdict.
• Match the bar to the noise. Low-stakes, noisy stuff (creative, stylistic) needs a longer streak before you believe it, because any one result could be luck. High-stakes, clear-cut stuff (did the deploy break) can graduate on fewer, cleaner cases.

The philosophy is the constant. The formula is yours. The whole point is to stop following someone else’s numbers, and that includes mine.

What It Found on Me

Fast, because the findings are the demo, not the lesson.

It convicted the rule I trusted most. I had a rule, in its own file, capitalized with conviction: parallel AI agents multiply throughput three to five times, so always run independent tasks at once. Parallelism was my favorite trick.

My own logs convicted it.

H015  "Parallel agents multiply throughput 3-5x"   

VERDICT: REFUTED

evidence for: 0   evidence against: 1

Seven agents on related code: a 7-way merge conflict
Two agents, unaware of each other, fixed the SAME bug twice
A piece of work died because two branches couldn't reconcile
  replaced by: parallelize research and independent files,
               run anything that shares files one at a time

Not hypotheticals. Entries in my own logs, written the day they happened.

The win was real for research, the reading and searching nobody else touches. It was destructive the moment the agents shared work. My rule said “always.” The “always” was the lie. The rule failed because I trusted it enough to create the exact failures that sank it.

Then I counted the notes my system had carefully saved over months:

• Seven percent of them did eighty percent of the work.
• Sixty-nine percent were never looked at again. Saved, filed, carried forever, never reused.

My diligent note-taking was mostly ritual, and I’d never have known without counting.

The rules that survived were the boring ones. Research before building. Small focused commits. A test for every bug fix. Never hardcode secrets. The exciting rule is the one that hurt me. That holds well past code.

Where This Cheats

If I’m telling you to interrogate everything, the method has to face it too.

• It’s biased toward what you already believe. You’re grading rules on the record of someone who followed them. A rule can look “proven” partly because you obeyed it and never logged the path you skipped. Treat a graduated rule as strongly suggested by your evidence, not proven for all time.
• The score is a tool, not a truth. Its only job is to stop you from grading in your head. Don’t mistake a tidy number for proof.

Neither sinks the method. They bound it. A real refutation survives all the bias in the world. You can’t wish your way out of a merge conflict that already happened.

The point is to make these weak spots visible instead of hiding them under a confident config. A rule that knows where it could be wrong already beats one that’s just sure.

The Real Move

Copy the popular setup, install the hot plugin, paste in the instructions that worked for someone with a different job and different scars. It feels productive. It’s borrowing answers you never earned.

The better move is slower, and it’s yours:

• Treat every rule as a defendant.
• Make it face the evidence of your own work.
• Keep only what survives.

Your setup gets shorter, sharper, and true for you instead of true-sounding for nobody. And because you built the loop, you run it again regularly, watch rules rise and fall as your work changes, and get better on purpose instead of by accident.

So don’t follow my formula. Follow the philosophy and build your own.