Tokenmaxxing only pays with fat skills and real tests

Tokenmaxxing means paying for every extra bit of work that makes a result more complete, instead of stopping where a human would get tired. Garry Tan says it took him to 400x the code he wrote in 2013. I run the same kind of setup, and the part worth copying isn't the spending. It's the skills that hold your judgement and the tests that catch what comes out. Without those two, you get a bigger bill and more slop.

Garry runs Y Combinator, and he told the story on a special Lightcone episode in May. After 13 years away from code, he went back in January with Claude Code. Since then he's open sourced gstack, his set of Claude Code skills, which had 138,528 GitHub stars when I checked today. The other side of this word is in my note don't count tokens, count what they bought, so read them together.

Three builds of the same blog

His best number comes from a blog platform he's built three times. Posterous, his first YC startup, took about $4 million, six or seven people and a year and a half. Twitter bought it and shut it down, so he and his co-founder wrote it again as Posthaven, for about $100,000, two people and maybe three months.

In January he wrote it a third time for Garry's List, his site about California politics. That took about $200 of Claude Max and probably five days, and this version also crawls the web, runs deep research and has full RAG.

The catch is that by the third time he knew exactly what a blog platform needs. That's my reading, not his, and it matters. Rewriting something you've already designed twice is the best case for any tool.

Twenty sources, not one

The word comes out of how Garry's List writes its articles. A person clicks a link, reads a headline and moves on. His pipeline pulls research through Perplexity's and Grok's APIs, takes 20 sources instead of one and cross-references them: these 13 say this, those seven disagree. All of that goes into the main prompt.

He calls the habit boil the ocean. If extra work makes the result more complete, pay for it. He puts one article at the equivalent of $5 or $10 of Opus calls, for work a person would do by going through dozens of articles and whole books.

He doesn't think that removes people. Someone still has to supply the want, and his is middle schoolers in San Francisco who couldn't take algebra. No model picked that subject for him.

Judgement goes in the Markdown

A harness is the core loop: it takes your input, gives it to the model and runs what the model asks for. YC kept rewriting one for internal agents until they asked why, since Claude Code already exists. Their partner Pete Koomen gave the idea its name: thin harness, fat skills. Stop writing the loop and spend your time on the Markdown.

His test is a wedding planner. Whatever you'd write in plain English to teach the next planner goes in Markdown. Calling 20 venues is a real action, so that's code, a call to Twilio. Most of the pain in agent engineering, he says, comes from putting judgement in code, which is brittle and doesn't understand special cases.

Thin doesn't mean the harness doesn't matter. One of the hosts says anything harder than a simple script fails for them through OpenClaw, on the same Opus 4.7 that works in Claude Code. So use a good loop, and don't write your own.

This is the part I already live in. Claude Code and OpenClaw are my harnesses, and about 30 skills of my own hold the procedures. The skill that saved my brief of this episode is 124 lines of Markdown deciding what goes in the note, next to a 441-line Python script and an 80-line browser check that make the API calls, validate the data and take the screenshots.

gstack started in Apple Notes

He didn't plan gstack. He got tired of typing the same instructions into Claude Code, put them in Apple Notes and then posted them, and about 200,000 people saw that. Now it's a chain of reviews, and each one works on the plan before anything gets built.

Two of its tricks are tiny. Before any work, he asks for an ASCII diagram of the data flows, inputs and outputs, user flows and error messages. Once Claude has drawn that, he says, the work comes out more complete. The CEO review adds a check for what's more ambitious and delivers 10x the value for only 2x the effort.

None of my skills asks for an ASCII diagram. It's the cheapest thing on his list to try.

The chain also stops to ask. gstack leans on AskUserQuestion, because that's where the person supplies what they're actually building. "I never want to be entirely out of the loop," he says. "I just want the machine to do the stuff that I don't want to do."

It's slop until something catches it

He hit what everyone hits. It works for the 80% case, then real users touch it and it falls over. Writing tests by hand was never fun, so he always did the minimum. Now the machine doesn't care, so he aims for 80 to 90% coverage, after finding 100% was too much. Untested agent code, he says, is 10x worse than human code, because you have no idea what will happen.

Then manual testing became the bottleneck. He had 15 features waiting for him to click through, and the Claude in Chrome MCP took 2 to 3 seconds a turn. So he wrapped Microsoft's Playwright. That's now browse, a long-lived HTTP daemon with 70 commands, and his QA skill reads what changed on the branch and tests any UI or data change in a real browser.

I got to the same place another way. My skills bring their own Playwright checks, and this note had to pass one in Chromium and WebKit at 320, 390 and 1280 px before it shipped.

What I'd add is a hard stop. "The machine doesn't care. It'll just do it" cuts both ways. Two of my agent sessions ran a pkill with options after the pattern to stop a test server. macOS reads those as more patterns, and Docker Desktop quit both times, taking every container on my Mac mini with it.

So that one is now a hook. Three of them run before a Bash command does: one refuses that pkill form, one refuses taking over another app's port, and one refuses a pull request with no issue. A skill asks. A hook refuses.

I also have the opposite example. On October 25, an agent ran my film app's tests inside its live container. The container's environment aimed them at the real database, and the tests' drop_all dropped every table. A backup brought back what it held. The rule against that is still only written down, which is a gap.

The 400x is arithmetic, not value

He got trolled for counting lines of code, so he published the math. A script counts logical lines across his repos: 5,143 in all of 2013, and 1,233,062 in the first 108 days of 2026. Per day, that's 14 against 11,417, or 810x. Then he assumes AI code is twice as verbose and halves it, and that's the 408x the episode rounds to 400x.

I like that he shows the work, because the same table has the other numbers. Across those same periods, logical lines went up 240x, files touched 47x and commits 4.9x. And the 14 a day was part-time, in a year with a day job.

He concedes the point himself, in bold: "Time to first user is the metric that matters, not LOC." If 80% of what he shipped this year is dead in two years, he writes, the critique gets its teeth.

Tokens are rent, they say

One of the hosts compares token spend to San Francisco rent. Founders flinch at the apartment, and YC tells them to pay it. Save money on the couch, not on the models. Garry goes further, with $500 in a single day, as long as you're building something of great value to you and it's the right thing.

That condition does all the work. J.R. Storment's rule in my tokenomics note was to count what the tokens bought, so I tried it on myself. Meterlex read 4.09 billion tokens for the week ending October 30, and my account merged 417 pull requests across 46 repos that week. That's about 9.8 million tokens per merged PR.

It's a tidy number, and it doesn't tell me much. A PR isn't an outcome any more than a line is. Tokens aren't what they sound like either: in the week open as I write this, Claude Code's count is 3.87 billion and only 25.8 million of that is model output. Nearly all the rest is cached context, read again on every turn.

So I can tell you what I burn and I can't tell you what it bought. That's the same gap the Tokenomics survey found.

A Ferrari with a mechanic on call

His line on OpenClaw is the one everyone quotes. It's like driving a Ferrari: it figures things out you'd never think a machine could, and it breaks down on the side of the road when you most need it, so you'd better be a mechanic. He calls this the Homebrew Computer Club moment, the Apple 1 in a wooden case. Getting one running takes two or three hours and maybe $500 or $1,000 in tokens and cloud.

A host has the better line. It doesn't matter if it's brittle, because you can sit another agent next to it to fix it. I already do that: one of my skills is a Claude Code runbook for OpenClaw. When an agent goes deaf on Telegram, it says to look for a hung codex app-server and kill that, not the gateway.

He predicts that everyone on the planet will have a personal AI a year from now. That's a bet, and he offers no evidence for it. The question he opens the episode with stands either way: "Will you have control over your own tools or will your tools have control over you?" Unless you write your own prompts, he says, you sit below the API line of some PM who doesn't know you. My agents' prompts and memory are files on my own disk, and that's my answer so far.

Try it

The episode is 41 minutes, and the demos are the best part. If you only have ten, start at the thin harness chapter.

• Tokenmaxxing: How Top Builders Use AI To Do The Work Of 400 Engineers, Y Combinator, May 8, 2026. The accidental gstack at 10:07, thin harness, fat skills at 20:59, the Ferrari at 24:35.
• gstack and the math behind the 400x.
• My notes on counting what tokens buy and reviewing the plan instead of the pull request.

Next time you're about to spend more tokens, write down first what would catch a bad result. If you've found a better number than lines or PRs, I'd like to hear it.

Plain text: tokenmaxxing-fat-skills-real-tests.md · Atom feed · All notes