Stop using Claude Code, start using AI

Somewhere right now, someone is proudly posting a three-thousand-line CLAUDE.md. Someone else runs four hundred skills and calls it "my setup". We all drift that way, one instruction file at a time, because every line feels like the assistant getting smarter.

It doesn't. Most of that tooling is context plumbing mistaken for intelligence, and the mistake has costs we've stopped seeing.

Under the hood

In early 2025, Anthropic shipped Claude Code and made "agentic AI" a household phrase. Strip the aura and here is what shipped: a chatbot LLM, a handful of deliberately low-level tools (essentially a terminal and your files), and a loop. You ask. The model calls a tool, reads the result, calls another, and keeps going until it can answer.

Note how humble the hands are. A shell and file access is about as low-level as tooling gets. The power you feel comes from the model and the loop, not from sophisticated machinery around them.

The rest of the market confirms it. OpenAI's Codex CLI arrived seven weeks later, close enough to the blueprint that the press called it the OpenAI answer to Claude Code. The IDE lineage went the other way: Cursor first, then Copilot's agent mode, then Google's Antigravity, all folding the same loop into VS Code and its forks, less opinionated about how you work because the IDE absorbs them. And the cloud lineage (Manus, Devin, ChatGPT Agent, Jules) runs the loop in a remote sandbox and hands you the finished result. CLI, IDE or cloud, supervision or delegation: same chatbot, same hands.

The props

Around that loop grew an ecosystem of props with mystical reputations. None of them is what it's worshipped as.

CLAUDE.md

CLAUDE.md is text injected at the top of every session, and the model takes it as gospel, or close enough. That's the feature, and that's the danger. An error in that file stops being a mistake and becomes a project-wide law. It was also never meant to be big. That same documentation targets under 200 lines, because longer files reduce adherence.

Memory

Memory came from the chatbot side: ChatGPT introduced it in early 2024, Claude followed in 2025, and Claude Code now writes its own notes between sessions. The mechanics rhyme with everything else here: an index loaded at session start, topic files fetched on demand. The twist is the author. These notes are written by the model, for the model, and loaded back next session as established fact. A misunderstanding that makes it into memory doesn't die with the session anymore. It compounds.

Skills

Skills are folders of instructions. Only the name and a deliberately shortened description sit permanently in the prompt, and the body is fetched when the model judges the description relevant. Read that again: a skill is a flat index of documentation with truncated summaries. Useful. Not magic.

MCP servers

MCP servers are the voodoo dolls of the lot: plug one in, says the legend, and the model gains powers. What a server actually brings is tools one level above the terminal. Instead of typing database commands in a shell, the model queries the database through a dedicated tool. Instead of curling an API, it calls it directly. Convenient, sometimes genuinely so. The catch is mechanical: every tool ships with a definition, and most clients load all of them into the context of every single request, needed or not. Anthropic itself recommends code execution to avoid exposing tools wholesale. Plug in ten servers and each of your requests quietly carries dozens of tool definitions, thousands of tokens spent on capabilities you touch once a week.

Everything else

And the family keeps growing: AGENTS.md (an open standard launched by OpenAI, adopted by twenty-plus tools), Cursor rules, Windsurf memories, Copilot instruction files, slash commands, subagents. Every one of them answers the same single question: what sits in the context window permanently, and what gets loaded on demand. That's the whole science.

Hooks and permission files play a different game entirely. They're not knowledge and they're not instructions: they're plain code sitting in the loop itself, intercepting what the agent tries to do, blocking it or feeding the outcome back into the next turn. The one bit of actual logic in the whole machine.

The intelligence is fixed

Time to name the misunderstanding precisely. All of these props get sold, implicitly or loudly, as ways to make the model smarter or more relevant. They can't be. How smart a model is was settled the day its weights were trained. What varies is what it knows.

Every prop from the previous section is a pipe into the second inlet. When one carries actual knowledge, your procedures, your conventions, your domain, it does the only thing a prop can do: it feeds the context. Genuinely useful. Everything else is behavioral instructions, and instructions don't upgrade anything. At best they steer, and the effect is modest. At worst they constrain, and constraints have a price: the model spends capability on compliance instead of on your problem. My bet, from watching these setups, is that the perceived boost is mostly placebo, and sometimes a regression wearing a cape.

None of this is speculative. The costs have been measured, constraint by constraint:

• Ask for brevity and hallucinations go up. Correcting a question built on a false premise takes more words than playing along with it, so a model ordered to keep it short plays along. On the Phare benchmark, concision instructions cost models up to 20 percent of their ability to push back on false claims.
• Force a strict output format and reasoning suffers (Tam et al., EMNLP 2024). The bill lands hardest when capacity is tight: up to 36 points lost on hard math for smaller models, while models with headroom barely move.
• Suppress the thinking and accuracy on math problems can drop fourfold.
• Assign a persona and reasoning degrades, by a third on average for some personas.
• Pile on instructions and compliance collapses: past a few hundred simultaneous rules, the best models follow about two thirds of them, biased toward whichever came first.

The trend even has a mascot: Caveman, ninety thousand GitHub stars for making the model talk like a prehistoric man ("why use many token when few token do trick") in the name of token savings measured around 4.5 percent effective. Style constraint, brevity constraint and persona, all at once, from the list above. And because a model conditions on its own transcript, a persona doesn't stay in one reply. Push a model into declaring itself an idiot, and next turn you're talking to an idiot.

Why it works anyway

On frontier models, none of this hurts enough to notice. Context windows in the hundreds of thousands of tokens absorb the rent, the model shrugs off the noise, and the trophy keeps growing. That comfort is exactly what makes the cult self-sustaining: when an overloaded config misbehaves, the fix is one more skill, one more rule file, one more plugin. Tooling problems get solved with more tooling, because nothing ever pushes back.

There is a second layer of comfort, and it's opacity. A hosted agent is a black box wrapped around the model. You don't see the system prompt, which may well be written to defuse the worst of your config. You don't see what happens in the thinking phases, where something may quietly compensate for the noise you injected. So when your setup seems harmless, you can't tell whether it actually was, or whether the harness cleaned up after it.

Two things break the illusion, though: a smaller model, and a new colleague.

The first revealer: local models

I like Claude Code. I also like imagining the day it disappears, or the day I stop wanting to pay for it. So part of my attention lives with the models I can run on my own hardware, and they have become seriously good. Qwen3.6-27B fits on a single high-end consumer GPU, and Gemma 4 ships variants from laptop class up to a 31B dense. On GPQA Diamond, the 27B sits about four points under the frontier trio. On SWE-bench Verified it posts 77.2 against Claude Opus 4.6's 80.8. Vendor-reported numbers, and newer frontier releases score higher, but the direction is hard to miss: the gap has nearly closed.

What local models are not is forgiving. You can't mumble half a wish and trust the model to recover. You guide more, you feed cleaner context, and every token counts double. Now bring your trophy along: twenty thousand tokens of permanently loaded signatures is a rounding error for a frontier window and a disaster for a local one.

And where the hosted agent is a black box, a local stack is glass. You wrote the system prompt. You see every token that goes in. Nothing hides, nothing compensates. Less headroom and full visibility: the mistakes the giants absorb in silence show up here immediately, in plain sight.

The local model didn't create the waste. It revealed it.

If your workflow only works inside Claude Code, you've learned a tool, not AI. And it gets worse with commitment. Learning a vendor's harness is a habit you can break. Building your tooling around it is a wall you'll have to climb.

The second revealer: the new colleague

You have already worked with this agent, in human form. A junior joins the project. They take the onboarding docs literally, they don't know any of the implicit conventions, and they need guidance before they need autonomy. Someone online described Claude as an intern who has read all the documentation and shows up extremely motivated, and the image stuck with me (Simon Willison runs with a similar one). Every symptom we blame on agents, the junior has too.

Which means the two problems share a solution. Whatever onboards a newcomer well onboards a model well. And that's precisely where the tooling cult does its worst damage.

The real damage: documentation

Since these tools went mainstream, I watch teams quietly stop writing documentation. In its place: skills, and shared agent configs. Ask "how do we deploy?" and the answer has become "use the deploy skill".

The AI now knows. You still don't.

The knowledge exists, but it's locked inside a tool's config, invisible to the junior, useless in a meeting, unreadable in a code review.

Staleness plays out differently too. An outdated doc eventually trips a human: an onboarding, a review, an incident walkthrough. An outdated skill keeps producing plausible-looking runs, and since nobody ever reads it, nobody catches it. The doc fails loudly. The skill fails silently.

And opening the file doesn't save you, because who wrote it? The AI did, usually. AI-authored config prose is a dialect of its own. Each sentence, taken alone, reads perfectly fine. The whole is strangely indigestible: over-specified, oddly ordered, confusing for a human trying to learn from it, effortless for the model that wrote it. It's the uncanny valley of documentation. It looks like text written for you, something feels quietly off, and the something is that it never was.

There is a subtler loss too. Documentation puts pressure on your design. Nobody wants to write a forty-five-step deployment guide, and nobody wants to follow one, so the steps get scripted, the script gets a name, and the doc shrinks to "run this". Writing for humans forces you to automate the automatable. Hand the same forty-five steps to an agent instead and the pressure is gone: the model will happily click through all of them, in the right order if you're lucky, and nobody ever feels the pain that would have produced the script.

My rule for working with AI is a division of labor: the model takes what is tedious, repetitive, or beneath anyone's attention, and the intelligence stays on my side of the desk. "The skill knows" inverts that split. The tool holds the knowledge, and the humans hold the shortcut.

What I do instead

The mindset shift comes first. I don't ask AI to help me understand. I ask it to help me do. I already know what I want, and the model refines the thought, fetches what's missing, or builds. Understanding stays on my side, and not out of principle: understanding is what accumulates from one task to the next, and a context window doesn't survive the day. In this whole setup, I'm the only component where it can compound.

Then one image drives everything else: any task may be handled by a fresh agent with no memory of the previous one. In other words, every task is done by a colleague who joined the project this morning. Take that seriously and onboarding becomes the whole game:

• Projects that work out of the box. The ideal: installing the standard runtime of your stack is the only prerequisite. The build tooling ships inside the repo, the Docker Compose is committed, and everything runs locally with zero extra setup. What automation already encodes, neither the junior nor the agent has to discover.
• A documentation tree. The README doesn't hold everything. It's the entry point that leads, link by link, to everything: architecture here, conventions there, deployment further down.

Look at what the tree really is: progressive disclosure. A cheap entry point, full content loaded only when a branch turns out relevant. The exact economy skills promise, on a better substrate: navigable instead of flat, specific to your project, and readable by the junior at the desk next to yours.

The pragmatic concession

One honest weakness: an agent forgets the tree existed the moment its context resets. And I still use Claude Code every day, so ignoring its mechanisms would be posturing. My compromise is a CLAUDE.md of a dozen lines whose only job is to say: read the README, the documentation is a tree, walk it before you act. The smallest permanent rent that buys the whole library.

That's what the title means. Keep the tool, it's a good tool. But understand the model underneath: two knowledge sources, a context window with a budget, and a loop with hands. Feed it documentation written for humans, and let it read over our shoulder. That's using AI.