Garry Tan's Blueprint for the AI-Native Company

Garry Tan has a number he keeps throwing at the internet, and the internet keeps throwing back. The number is 400. As in, 400 times more productive. Tan, who runs Y Combinator, says that by shifting from writing code himself to directing AI agents, his personal output multiplied by that factor — same hours, fewer of them actually, with a 5 p.m. school pickup now on the calendar.

He knows how it sounds. "Before the skeptic in the third row deflates the number for me, let me deflate it myself," he told the AI Engineer conference crowd. Walk the figure back as far as you want, he argued — assume bloated code, assume he's flattering himself, assume half of it is worthless scaffolding. "It's still 8x at the floor." The floor, he pointed out, is still a very large number.

Fair enough. But the 400x is almost beside the point. The more interesting claim comes right after it.

It's Not the Model. It's the Method.

Tan's sharpest observation is also his most falsifiable: the gap between people getting modest gains from AI and people getting transformative gains has nothing to do with which AI they're using. "The 2x people and the 100x people are using the exact same Claude," he said. "The leverage is not in the weights, it's in how you wire the work."

Weights, for anyone who hasn't attended an AI engineering conference lately, is jargon for the underlying intelligence baked into the model itself. Tan's point is that the model is a commodity — the same tool is available to everyone. What separates outcomes is how deliberately people structure their work around it.

This is a claim worth sitting with, because it cuts against the narrative that dominates most AI coverage: the race to build more powerful models, the arms competition between labs, the quarterly capability benchmarks. Tan is saying none of that is the real game, at least not at the company level. The real game is organizational design.

What "Wiring the Work" Actually Means

Here's where Tan gets practical, and where the jargon can obscure a genuinely simple idea if you let it.

The core concept is the skill file — not a piece of software, but a plain-text document that describes one task clearly enough that an AI agent can execute it reliably and repeatedly. Think of it as a procedure manual, written not for a new hire but for an AI. One skill file handles one job: drafting a particular type of email, running a particular type of analysis, filing a particular type of report. The AI reads the file, does the work, and — critically — the file stays in the system for next time.

Stack enough of these together and you have something that functions like an organization. A routing table that directs incoming tasks to the right skill file is, Tan argues, the functional equivalent of an org chart. Quality checks that verify whether the right procedure got invoked are performance reviews. Written standards for how work should flow are internal process documentation.

"When you sit down with Claude Code or Cursor, you're not writing software," he said. "You're hiring, training, and managing a workforce made of markdown."

That's a genuinely useful reframe — markdown being the simple formatting language these files are written in — because it shifts the question from "what can AI do?" to "how do I manage AI to do what I need?" The first question is for researchers. The second is for people running businesses.

The extension Tan makes, which most engineering talks skip, is that this isn't only for engineers. He described a finance team member at YC who had never written a line of code, but who collapsed roughly a hundred spreadsheets into a single working application by directing AI agents. She didn't become a programmer. She became, in Tan's framing, a manager of agents — which is what he says everyone at YC now is.

The Memory Problem

Behind the skill-file framework is a more fundamental argument about institutional memory.

Human working memory is famously limited — cognitive psychology has documented this for decades — and Tan observes that essentially every organizational tool ever invented is a workaround for that limit. Checklists, org charts, filing systems, process documentation: all of it exists because people can only hold so much in their heads at once.

AI agents don't have that problem at the same scale. A modern AI can hold an enormous amount of context in its working window at once and retrieve from a much larger store of information almost instantly. That's the capability. The question is whether you feed it something worth knowing.

Tan's answer is what he calls a company brain — a structured, curated knowledge base that gives AI agents the right context for each task. He's built his own, called GBrain, which he describes as having grown to roughly 220,000 pages drawn from two decades of emails, meetings, and notes. When a founder writes to him about a crisis, his agent has already surfaced every prior conversation with that founder and pulled relevant cases from the portfolio before he finishes reading the message.

The honest part of his pitch is that he's also clear about where this breaks. A knowledge base nobody maintains becomes, in his words, "a garbage dump with great search." An AI that retrieves stale or contradictory information will present it with exactly the same confidence as accurate information — which is a specific failure mode that can do real damage. The discipline required isn't just building the library. It's curating it, dating it, and actively removing what's no longer true.

The phrase he uses for the alternative is unsparing: "The organization that captures what it learns like this gets smarter every single day. The one that doesn't wakes up every morning with amnesia."

The One Rule He'd Enforce

Tan's single most actionable piece of advice is the one he says he gives to every YC company: never do one-off work.

The pattern he's trying to break is familiar to anyone who has used an AI tool. You have a task, you ask the AI, you get a result, you move on. The next time a similar task comes up, you start from scratch. The AI has no memory of what worked. You're back to zero.

His prescription is to "skillify" every completed task — convert it into a reusable procedure that lives in your system. If you had to ask for something twice, you failed. The first time becomes the template for every time after.

This sounds like a small discipline, but Tan's argument is that it's the whole game. Companies that do this consistently build a compounding advantage. The knowledge accumulates. The agents get better context. The output improves without anyone working harder. Companies that don't are, in effect, rebuilding the same capacity over and over.

What Tan Doesn't Resolve

The argument is coherent and, in its core logic, hard to dismiss. But Tan is also the president of an organization whose business model depends on startups succeeding, and he's giving this talk to a room full of people he wants to energize. The missionary quality of the closing — "abundance is not a policy paper, it is shipped software" — is earned by the talk's substance, but it's still a pitch.

The labor question he raises and then waves away deserves more than a sentence. He acknowledges widespread fear about job displacement and calls it "a failure of imagination," but the people most exposed to that displacement aren't in the room at an AI engineering conference. They're not building the skill files. They are the people whose roles get encoded into them.

That's not an argument against the architecture Tan is describing. It's a question about who benefits from its efficiency and on what timeline. The revenue-per-head ratios he cites as evidence of the model's power are, from another angle, a description of what happens to headcount.

Tan's framework is genuinely useful for founders and executives trying to understand what AI-native operations look like in practice. The skill file as employee, the routing table as org chart, the knowledge base as institutional memory — these are clarifying analogies, not hype. The underlying argument that organizational design matters more than model selection is, based on everything observable in this wave of AI adoption, correct.

The question of who designs those organizations, and who gets optimized out of them, is one the founders in that room will spend the next decade answering — whether they frame it that way or not.

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG