3 Secret Ways Claude Code’s Creator Actually Uses It

More Instructions Are Making Claude Code Worse

I've spent months adding skills, hooks, and persistent instructions to make Claude Code better.

Then Opus 5 dropped, and some of my results felt worse.

The strange part is that the fix might be deleting instructions, giving Claude a harder task, and letting it think.

TL;DR

→ Anthropic deleted more than 80% of Claude Code's system prompt for Opus 5

→ Instructions written for an older model can hobble a newer one

→ Keep business context, brand rules, and non-negotiables, but loosen the recipe

→ Give Claude a high-level goal, guardrails, exit criteria, and a way to verify its work

→ Manage AI agents like capable people: set direction, review, and let them use their brains

Why Claude Feels Worse

Boris Cherny, the creator of Claude Code, explained this in a 35-minute interview on the Y Combinator YouTube channel, and it changed how I think about my entire setup.

Every model is different.

Different strengths. Different flaws. Different behaviors that need correcting.

That means Claude Code's harness is always changing. Anthropic adds and deletes tools, rewrites the prompts attached to those tools, and changes the system prompt whenever a new model ships.

For Opus 5, the team deleted more than 80% of Claude Code's system prompt.

A lot of those old instructions were compensating for behavior the previous model should have handled but could not. Opus 5 could already do those things, so keeping the correction only got in its way.

This hit me because Opus 5 had felt degraded in some of my real work.

I was occasionally going back to 4.8 because I liked the output better.

My first assumption was that the new model was worse. I had not seriously considered that my old instructions might be the problem.

Boris's recommendation is simple: every six months, delete or disable your CLAUDE.md, skills, and hooks. See what the current model does without them.

You might be surprised.

Think about teaching three people to build a slide deck:

→ A 10-year-old

→ A college student

→ A professional who has spent 10 years making hundreds of decks

The 10-year-old probably needs exact instructions. The 10 slides to create. The title format. The colors. Where every block of text goes.

Give that same recipe to the experienced professional and you prevent them from using their judgment.

The instructions that help the beginner can hobble the expert.

Boris calls this product overhang. Today's models can already do things we have not discovered because our products and prompts have not given them the room to show us.

One way to find those capabilities is to give the model a slightly harder task than you think it can handle.

What My No-Skills Test Showed

I made a duplicate of my AI operating system and removed the CLAUDE.md file and all my skills.

Then I gave both versions the same task: take Boris's interview and create one of the YouTube resource guides I make for my audience.

The version with my full setup created a polished nine-page guide.

It used my colors. It added my header image. It linked to my YouTube channel at the top and AIS+ at the bottom.

It knew my preferences because I had given it that context.

The blank version looked messier.

No branded header. No polished formatting. No knowledge of where my links belonged.

But honestly, I preferred the content structure.

Without a skill telling it exactly how to break down a resource guide, Claude organized the interview around its main ideas. It gave each idea a clear label and attached the relevant timestamp.

The first version followed my recipe better.

The second version thought about the material better.

My takeaway is not to delete every skill.

It is to separate context from procedure.

I still want Claude to know:

→ Where my business context and wiki live

→ Which image belongs in the header

→ Which brand colors to use

→ Which links are required

But instead of prescribing the entire structure, the skill can say: make the resource guide however you think is best, then apply these brand requirements.

Keep the destination. Loosen the route.

The Advice Depends on Your Work

The annoying part is that you cannot take advice from Boris, Andrej Karpathy, another YouTuber, me, or someone in a community and apply it blindly.

Boris and Karpathy often speak from the perspective of people designing model harnesses, training models, and working inside massive software codebases every day.

That is not how I use Claude most of the time.

My day-to-day work is research, knowledge work, documents, and deliverables. I need Claude to understand my company, my file structure, my audience, and my brand.

Someone building software may be able to delete a lot of old build and orchestration instructions because the model and harness now handle those patterns better.

A knowledge worker may still need strong persistent context because the model cannot guess which logo, link, wiki, or business rule matters.

Both can simplify their setup, but they should not delete the same things.

The useful question is not, "Should I delete all my skills?"

It is, "Which instructions provide necessary context, and which ones are micromanaging a capable model?"

Prompt Goals, Not Recipes

Modern models do not need a 40-step recipe for every task.

Boris recommends giving them four things:

1️⃣ A high-level task

2️⃣ Clear guardrails

3️⃣ Exit criteria

4️⃣ Room to choose the route

Then let the model cook.

This does not mean accepting mediocre output.

Claude still needs to know what good looks like. If the standard is vague, the result will probably be vague too.

When I set a /goal, I define the outcome and list the evidence the agent must produce to prove it reached that outcome.

Sometimes I add language like this:

"I am not looking for a prototype or proof of concept. I want something tested, iterated on 10 times, fully QA'd, and ready to go to market tomorrow."

That language is a little emotional, but I have found that models sometimes respond well to it. It communicates the level of persistence and finish I expect without telling the agent every move to make.

Verification Is the Real Skill

Boris's biggest point was that the skill is becoming less about prompt engineering.

It is becoming more about giving Claude a hard task and making it possible for Claude to verify its own work along the way.

Verification is the part most people miss.

Do not just say what good looks like. Give the agent concrete ways to test whether it got there.

Have it run the tests. Inspect the output. Compare the result against the standard. Ask another agent to play devil's advocate. Keep iterating until the evidence passes.

This idea is tool-agnostic.

Claude Code. Hermes. Codex. Whatever comes next.

The durable skill is managing AI agents.

Good managers do not micromanage every click. They set direction, check in, review the work, and apply judgment and taste.

They also let capable people use their brains. Those people were hired for a reason.

The same is true for the sessions and agents we spin up.

Outsource some of the thinking to them, but never outsource the understanding.

You are still responsible for the vision. You still need to understand what the system is doing, judge whether the output is good, and decide whether it is safe to use.

Wrap

Claude may not be getting worse. Your old instructions may be preventing a better model from showing you what it can do.

Keep the context. Cut the micromanagement. Raise the standard and make the agent prove it got there.

I walk through the test and all three changes in the full video. Link in the first reply.

Which instruction in your AI setup would you test removing first?

Full video: youtu.be/XNQBCRcwXV4?si…