100x Your AI. Same Model as Everyone Else.

Steve Yegge says the best AI users are 100x more productive than the rest. Identical models. Different architecture. Here's the index card.

2026-04-21 · By Guilherme Salgueiro

[Steve Yegge recently said something](https://newsletter.pragmaticengineer.com/p/from-ides-to-ai-agents-with-steve) that sounds absurd until you check it: **people using AI coding agents are 10x to 100x as productive as engineers using Cursor and chat today, and roughly 1000x as productive as Googlers in 2005.**

I've seen that number. Some of you have lived it. But the common explanation is almost always wrong. Smarter Claude. Better GPT. More parameters. A new model quarter.

The 2x people and the 100x people are using the same models.

The difference isn't intelligence. It's architecture.

The gap isn't in the model. It's in the machine around the model.

Here's what a model actually is, stripped of marketing: a function that takes text and returns more text. That's it. It can't open a file on your computer. It can't run a command. It can't see your database. It can't click a button. Every tool-using, file-editing, browser-driving thing you've watched an AI do — none of that was the model.

Think of it like a chef. The chef can cook anything in theory. But drop a world-class chef into a disorganized kitchen — no stations, knives in random drawers, ingredients in a walk-in three rooms away, no prep, no recipe pinned anywhere they can see it — and the output is mediocre. Put a decent chef into a kitchen with sharp tools at hand, ingredients *mise en place*, a recipe card posted at the station, and everything pre-measured, and the output is excellent. Same skill. Different kitchen. Different meal.

The kitchen is the harness.

Here's how the kitchen runs. You walk in and place an order — your prompt. The chef writes down what to do next. Sometimes that's the finished dish. Sometimes it's a note that says *fetch flour from the pantry* or *preheat oven to 180°C* — a tool call. The kitchen reads the note, does the fetching or preheating, comes back, tells the chef what happened. The chef writes the next step. Repeat until the order is served.


Every AI tool you use runs that loop. The magic feeling is the loop. The intelligence feeling is what the kitchen staged for the chef before they arrived.

Once you see this, a lot of the discourse stops making sense. "Claude vs GPT." "Cursor vs Claude Code." Those aren't model comparisons. They're kitchen comparisons — the tool set, the station layout, the recipe card, the prep work — mislabeled as chef comparisons because the vocabulary collapses the two.

[Garry Tan made this concrete recently](https://x.com/garrytan/status/2042925773300908103). Claude Code ships via npm, which means its code is inspectable. Tan read it. What he found wasn't special model access. It was live repo context, prompt caching, purpose-built tools, context bloat minimization, structured session memory, parallel sub-agents — *a kitchen*. None of that makes the chef smarter. All of it makes sure the right ingredient is within reach at the right moment.

The gap isn't between Sonnet and Opus. It isn't between Claude and GPT. The gap is between an AI user ordering from a disorganized kitchen and an AI user who has quietly arranged one that works.

Which raises the obvious question: if some kitchens work dramatically better than others, what separates a good one from a bad one?

The answer fits on an index card: thin harness, fat skills.

Garry Tan has the cleanest version of this I've seen. It fits on an index card:

**Thin harness. Fat skills. Deterministic base.**


Three layers. Each one does a specific job. The 2x users get this wrong in a specific way, and the 100x users get it right in a specific way.

The harness stays thin.

Back to the kitchen. A good kitchen does four things: it holds the tools, it lays out the prep, it runs the timing, and it keeps the chef from burning the building down. The harness is the same: it runs the model in a loop, it gives it tools, it manages the context, and it enforces permissions. Four jobs. No more.

The anti-pattern is what Tan calls the *fat harness* — a kitchen so crammed with gadgets that the chef can't move. Forty-plus tool definitions eating half the context window. God-tools that wrap entire REST APIs and take five seconds per call. MCP servers that chain six operations into one slow round-trip. Tan points out that a Playwright CLI doing each browser action in 100 milliseconds beats a Chrome MCP that takes 15 seconds for screenshot-find-click-wait-read. Seventy-five times faster, because the kitchen is narrower and each tool does one thing well.

Software doesn't have to be precious. The best harnesses are small by design.

The skills get fat.

"Fat" here isn't bloat — it's weight. A *skill* is a reusable markdown document that teaches the model how to do a specific kind of work. Not what to do in the moment. How to do it, reliably, every time you ask. Recipe cards pinned in the kitchen, not orders written on scraps.

Here's the move that separates skills from prompts: **a skill file takes parameters.** Same procedure, different arguments, radically different capability.

Tan's example: a skill called `/investigate`, seven steps long — scope the dataset, build a timeline, synthesize what changed, argue both sides, cite everything — with three parameters: TARGET, QUESTION, DATASET. Point it at a safety scientist and 2.1 million discovery emails and you get a medical research analyst determining whether a whistleblower was silenced. Point it at a shell company and FEC filings and you get a forensic investigator tracing coordinated campaign donations. Same markdown. Different world.

That isn't prompt engineering. It's software design, with markdown as the programming language and human judgment as the runtime. As Tan puts it: markdown turns out to be a better encapsulation of capability than rigid source code, because it describes process and judgment in the language the model already thinks in.

The principle holding the stack together.

The third layer is the **deterministic base** — the part of your stack where the same input always produces the same output.

A database query is deterministic: ask for user #42's email, get the same email every time. Arithmetic is deterministic: 2 + 2 is always 4. A git diff is deterministic. A file read is deterministic. Anything where you want the answer *exactly*, not the model's best-effort guess at the answer.

Back to the kitchen: the oven at 180°C produces 180°C every time. The timer rings at 30 minutes every time. The scale weighs the flour to the gram. These are the deterministic equipment. The chef's judgment about whether the crust is done isn't deterministic — that's latent, interpretive, probabilistic. The kitchen works because the chef doesn't eyeball the oven temperature and the oven doesn't get opinions about the recipe.

In your AI stack, the deterministic base is anything you want trusted, not generated: your app's database, your search index, your existing code, your APIs, your arithmetic. You already have most of this. The skill calls into it whenever *exact* matters.

The architecture only works if you keep the traffic moving in one direction:

**Push intelligence up into skills. Push execution down into deterministic tools. Keep the harness thin in between.**

When the next model ships, every skill instantly gets better in its judgment steps, while the deterministic layer stays exactly as reliable. That's what compounds. That's why the 100x users are still 100x a year from now, while the users who chased the latest model upgrade start over.

Where the leverage actually lives.

Four moves, ordered by how much return you get per hour of effort. Every one of them comes straight out of Tan's framework.

1. Rewrite your CLAUDE.md as a resolver, not a knowledge dump.

Tan confesses that his own CLAUDE.md grew to 20,000 lines — every quirk, every pattern, every lesson he'd ever encountered. *Completely ridiculous*, in his words. The model's attention degraded the more he added. Claude Code literally told him to cut it back.

His fix: about 200 lines. Not knowledge — *pointers*. When the task is X, load document Y first. When the task is Z, load document W. The resolver is a routing table. Twenty thousand lines of knowledge are still accessible, but only the right few hundred lines get pulled into any given session. The rest stay on disk until a task actually needs them.

You may already have a CLAUDE.md. If not, or yours is thin, [I wrote a guide to the fundamentals](/writing/claude-md-guide) — start there. The upgrade from that baseline isn't more content. It's fewer words pointing at more documents.

Kitchen version: the recipe card at the station shouldn't contain every recipe you've ever cooked. It should say *for this dish, read page 42 of the binder over there*.

2. Codify every repeated task into a skill file.

This is Tan's most transferable instruction. He gave it to his own coding agent and [tweeted it verbatim](https://x.com/garrytan/status/2043566215927328955):

You are not allowed to do one-off work. If I ask you to do something and it's the kind of thing that will need to happen again, you must do it manually the first time on three to ten items, show me the output, and if I approve, codify it into a skill file. If it should run automatically, put it on a cron. **The test: if I have to ask you for something twice, you failed.**

The test is what makes this real. Not "try to reuse prompts." Not "save good prompts in a folder." *If I have to ask twice, you failed.* That forces the codification move to happen while the context is still fresh.

Every skill you write is a permanent upgrade to your system. It never degrades. It never forgets. It runs at 3 AM while you sleep. And when the next model ships, every skill instantly gets better in its judgment steps while its deterministic steps stay exactly as reliable.

3. Separate the latent from the deterministic.

Every step in your system is one or the other. Getting this wrong is the most common mistake in agent design.

Tan's example lands this in one image. A model can seat eight people at a dinner table, accounting for personalities and who doesn't get along with whom. That's a social judgment call — latent, interpretive. Ask the same model to seat eight hundred and it will produce a plausible-looking seating chart that is completely wrong. Because seating eight hundred isn't a social problem. It's a combinatorial optimization problem, and it belongs in code.

The mistake is forcing the wrong work on the wrong side of the line. The model should never do arithmetic you could run in SQL. Your SQL should never try to interpret tone. When your stack confuses the two, the model hallucinates confidently and the code fails silently.

Kitchen version: you don't ask the chef to weigh the flour. You don't ask the scale for a taste opinion.

4. Edit your tool descriptions like they're prompts.

Because they are.

The model doesn't see your tool's code. It sees the short string describing what the tool does, and that description steers which tool gets called and how. Rewrite a tool description from "read a file" to "deprecated — use bash instead" and the behavior changes, even though the code is identical. The model trusts the description the same way it trusts any other text in its context — because, to the model, that's all the description is.

If you build your own harness, tool descriptions deserve the same care you give the system prompt. They are the system prompt, just delivered inline.

The model is a commodity. The architecture compounds.

The race for the best weights is commoditizing. Each generation, the gap between [Anthropic](https://www.anthropic.com/news/claude-opus-4-7), OpenAI, and Google shrinks. Model choice will matter less from here, not more. That isn't a prediction — it's the trajectory of every technology that hits scale, from operating systems to databases to cloud compute. The thing that got commoditized never stayed the bottleneck.

What doesn't commoditize is the architecture around the model.

Your CLAUDE.md. Your skill files. Your separation of judgment from execution. The way you specify tasks. The context you pre-load. The feedback loops you build so the system gets smarter every week without you. These are human skills. They don't ship in a model release. They don't get beaten by the next lab. They compound in one place — you.

This is what AI-native leverage actually looks like in practice. Not which model you use. Not which tool you subscribed to. The quality of the thinking you put between you and the model — written down, reusable, improving itself.

Yegge said the best AI users are [100x more productive than the rest](/writing/5-levels-ai-chat). He's right. They're running the same models you are. What separates them isn't intelligence — theirs or the model's. It's that they quietly built a kitchen while the rest of the field argued about which chef to hire.

Build it once. It runs forever.

---

*The architecture in this piece — thin harness, fat skills, resolvers, latent-vs-deterministic — is Garry Tan's framework. [His recent post on the topic](https://x.com/garrytan/status/2042925773300908103) is the sharpest short version I've seen. If the ideas here land, the ideas are his; any awkwardness in the translation is mine.*