The junior sobered up

A year ago I wrote that AI-assisted coding felt like micromanaging a junior who is about 6 pints deep. It was meant as a throwaway line, but it stuck — partly because it was true. You'd hand the work over, and then hover, because left unsupervised the junior would confidently refactor half your codebase to fix a typo.

A year on, the junior has sobered up. They've also, somewhere along the way, levelled up — the drunk junior is now a fairly sharp senior who occasionally still does something baffling, but far less often than I do.

But while the junior was drunk, we all wrote rules. Don't touch the config. Always run the tests. Never use that library. Stop apologising. Every time something went wrong, another line went into the prompt. It was the rational response to an unreliable colleague — write down everything they get wrong, and make them read the list every morning.

The junior sobered up. Nobody threw away the list.

Deleting 80% of the prompt

Boris Cherny — creator of Claude Code at Anthropic — did an interview at Startup School recently, and there's a moment about three minutes in that's worth your time. When Opus 5 shipped, his team deleted about 80% of Claude Code's system prompt.

The model got better.

All that carefully accumulated guidance — the accreted wisdom of every past failure — was actively holding the new model back. Cherny's explanation:

"Every model generation it behaves differently, it has a slightly different personality, and you have to take the time to get to know it."

Their process for finding out which 80% to cut is the genuinely useful part. Delete the whole prompt. Watch where the model actually fails. Add lines back one at a time — and only for failures that keep repeating. The rationale is brutally simple: the model reads every single instruction on every single call. A rule that stopped mattering two model generations ago isn't neutral — it's noise the model has to weigh against everything else, forever.

His broader point is the one I can't stop thinking about: many products are hobbling today's frontier models with prompts written for yesterday's weaker ones. We taught the drunk junior to walk in a straight line, and now we're making the sober senior do the same sobriety test every morning before they're allowed to sit down.

A prompt isn't an asset

The mental model I'd been carrying — and I suspect I'm not alone — is that a prompt is an asset. Something you invest in. It compounds: every rule you add makes it more valuable, more battle-tested, more yours. Teams keep prompt libraries. People sell prompt packs, for goodness' sake.

I think that model is wrong, or at least it's expired. A prompt isn't an asset. It's calibration — for one specific model, at one specific point in time. Like suspension setup for one car on one track. Bolt it onto next year's car and you haven't transferred value, you've transferred assumptions. Some will still hold. Many won't. You don't know which until you test.

None of this means the accumulation was a mistake. Adding a rule every time something went wrong was exactly the right move when models were weaker — those rules earned their place against real failures. The mistake is only in what happens next: the rules outlive the failures they were written for, and nobody goes back to check.

This is really about your product

If this were just about Claude Code config, it would be a tip, not a post. Claude Code even has a /doctor command now that helped me find cruft in my own setup, and Cherny's practical suggestion — periodically delete your CLAUDE.md files and hooks, see what the model does with minimal guidance, then add back only what it actually needs — takes an afternoon.

But the same pattern is sitting inside a lot of products. If you're calling a model over the API — for summarisation, triage, drafting, classification, whatever — then every one of those calls carries a prompt that someone wrote with a specific model in mind. Often a model that's since been swapped out. The prompt survived the migration because it lived in a string constant and nobody thought of it as model-specific. It compiled, the feature still worked, ship it.

What I'd actually do about it:

• Custom prompts per model, per action. One prompt serving three models is calibrated for none of them.
• Version prompts with models. They're a pair. When the model changes, the prompt is up for review by definition — not incidentally, if someone remembers.
• Treat a model upgrade as a re-baseline, not a drop-in swap. Re-run your evals against the new model with the old prompt, then with a stripped-back one. You may be surprised which wins.
• Ideally, A/B test prompts in production and review their performance over time, the way you would any other part of the product that touches users.
• Make every line earn its keep. Cherny's rule generalises: if you can't name the repeating failure a line prevents, it's a candidate for deletion.

My own list

I'm not writing this from a position of smug cleanliness. I build StayUpfront with Claude Code every day, and I've always tried to keep my prompts lean. And when I went through my setup this week with all this in mind, I still found lines to clear out. Instructions solving problems I honestly couldn't remember having. Rules for a model I stopped using months ago, faithfully read on every call since.

Rolling out AI — whether to your team or to your users inside your product — is the kind of thing I help companies with these days. If the prompts in your product are older than the model reading them, that's probably worth someone's afternoon, and I'm happy to be that someone — email me at hello@robgough.net, or see what I do.