Original title: Thin Harness, Fat Skills
Original author: Garry Tan
Translation: Peggy, BlockBeats
Editor's note: When the 'stronger model' becomes the default answer in the industry, this article offers a different judgment: it is not the model itself that truly creates a 10x, 100x, or even 1000x productivity gap, but the entire system design built around the model.
The author of this article, Garry Tan, currently serves as the president and CEO of Y Combinator and has long been deeply engaged in AI and the early-stage startup ecosystem. He proposed the framework of 'fat skills + thin harness,' breaking down AI applications into key components such as skills, operational frameworks, contextual routing, task division, and knowledge compression.
In this system, the model is no longer the entirety of the capability, but merely an execution unit within the system; what truly determines the quality of the output is how you organize the context, refine the process, and clearly define the boundaries between "judgment" and "computation".
More importantly, this approach is not merely conceptual but has been validated in real-world scenarios: when faced with data processing and matching tasks from thousands of entrepreneurs, the system achieves near-human analyst capabilities through a cycle of "read-organize-judge-write back," and continuously optimizes itself without rewriting code. This "learning system" transforms AI from a one-off tool into an infrastructure with compounding effects.
Thus, the core message of the article becomes clear: in the AI era, the efficiency gap no longer depends on whether you use the most advanced models, but on whether you have built a system that can continuously accumulate capabilities and evolve automatically.
The following is the original text:
Steve Yegge said that people who use AI programming agents are "10 to 100 times more efficient than engineers who only use Cursor and chat tools to write code, and about 1,000 times more efficient than Google engineers in 2005."
Note: Steve Yegge is an influential software engineer, technology blogger, and engineering culture commentator in Silicon Valley, known for his incisive, lengthy, and highly personal technical articles. He has worked as a senior engineer at companies such as Amazon and Google; later joined Salesforce; and then worked in startups and AI-related fields; he was also one of the early promoters of the Dart project.
This is not an exaggeration. I have seen it with my own eyes and experienced it firsthand. But when people hear about such a gap, they often attribute it to the wrong things: a stronger model, a smarter Claude, more parameters.
In reality, people who improve efficiency by 2 times and those who improve by 100 times use the same model. The difference lies not in "intelligence," but in "architecture," and this architecture is so simple that it can be written on a single card.
Harness (the runtime framework) is the product itself.
On March 31, 2026, Anthropic accidentally released the complete source code of Claude Code to npm—a total of 512,000 lines. I read it all. This confirms what I've been saying at Y Combinator: the real secret isn't in the model, but in "the layer that wraps the model."
Real-time code repository context, prompt caching, task-specific tools, minimizing redundant context, structured session memory, and parallel-running sub-agents—these don't make the model smarter. But they provide the model with the "right context" at the "right time," while preventing it from being overwhelmed by irrelevant information.
This "wrap" is called the harness (operational framework). The real question all AI builders should be asking is: what should be put into the harness, and what should be left outside?
This question actually has a very specific answer—which I call: thin harness, fat skills.
Five Definitions
The bottleneck has never been the intelligence of the model. The model has always known how to reason, synthesize information, and write code.
They fail because they don't understand your data—your schema, your conventions, and the specific shape of your problem. The following five definitions are precisely designed to address this issue.
1. Skill file
A skills document is a reusable markdown document that teaches a model "how to do something." Note that it doesn't tell it "what to do"—that's provided by the user. The skills document provides the process.
The key point most people overlook is that a skill file is essentially like a method call. It can accept parameters. You can call it with different parameters. The same process can exhibit drastically different capabilities depending on the parameters passed in.
For example, there's a skill called `/investigate`. It consists of seven steps: defining the data scope, building a timeline, diarizing each document, synthesizing and summarizing, arguing from both sides, and citing sources. It accepts three parameters: `TARGET`, `QUESTION`, and `DATASET`.
If you point it to a security scientist and 2.1 million forensic emails, it becomes a medical research analyst determining whether a whistleblower has been suppressed.
If you point it to a shell company and filings with the Federal Election Commission (FEC), it becomes a forensic investigator tracking coordinated political donations.
It's the same skill. The same seven steps. The same markdown file. The skill description is a decision-making process, but what truly translates it into the real world are the parameters passed in during the call.
This isn't prompt engineering, but software design: except here we're using Markdown as the programming language and human judgment as the runtime environment. In fact, Markdown is even better suited for encapsulating capabilities than rigid source code because it describes processes, judgments, and context—precisely the languages that the model "understands" best.
2. Harness (Runtime Framework)
Harness is the layer that drives the LLM to run. It does only four things: run the model in a loop, read and write your files, manage the context, and enforce security constraints.
That's all. This is what "thin" means.
The opposite pattern is: fat harness, thin skills.
You've probably seen things like this: over 40 tool definitions, the descriptions alone taking up half the context window; an all-powerful God-tool that takes 2 to 5 seconds to run a round trip in MCP; or wrapping each endpoint of a REST API into a separate tool. The result is that token usage triples, latency triples, and the failure rate triples.
The truly ideal approach is to use tools that are designed for a specific purpose, are fast, and have narrow functionality.
For example, a Playwright CLI takes only 100 milliseconds per browser operation, whereas a Chrome MCP takes 15 seconds to perform a screenshot → find → click → wait → read operation. The former is 75 times faster.
Modern software no longer needs to be "overly polished to the point of being bloated." What you should do is: build only what you really need, and nothing more.
3. Resolver
A resolver is essentially a context routing table. When task type X occurs, document Y is loaded first. Skills tell the model "how to do it"; resolvers tell the model "when to load what".
For example, a developer modifies a prompt. Without a resolver, they might release the update immediately after making the changes. With a resolver, the model first reads docs/EVALS.md. This document states: first run the evaluation suite and compare the scores before and after; if the accuracy drops by more than 2%, roll back and investigate the cause. This developer might not even have known about the evaluation suite. The resolver, at the right time, loads the correct context.
Claude Code has a built-in resolver. Each skill has a description field, and the model automatically matches the user's intent with the skill's description. You don't need to remember whether the skill /ship exists—the description itself is the resolver.
To be honest, my old CLAUDE.md file was a whopping 20,000 lines long. It crammed in all my quirks, all my patterns, and all the lessons I'd learned. It was utterly absurd. The model's attention quality noticeably declined. I even decided to cut the Claude Code altogether.
The final fix consisted of only about 200 lines—retaining just a few document pointers. The resolver would load only the document needed at the critical moment. This way, the 20,000 lines of knowledge could still be readily accessed without polluting the context window.
4. Latent and deterministic (Latent space and determinism)
In your system, every step belongs to either one category or another. Confusing these two categories is the most common mistake in agent design.
The latent space is where intelligence resides. Models read, understand, judge, and make decisions here. This involves judgment, synthesis, and pattern recognition.
• Determinism is where reliability lies. The same input will always produce the same output. SQL queries, compiled code, and arithmetic operations all fall into this category.
An LLM (Latent Management Model) can help you seat 8 people at a dinner party, taking into account each person's personality and social relationships. But if you ask it to seat 800 people, it will seriously concoct a seating chart that "looks reasonable but is actually completely wrong." This is because it's no longer a problem that latent space should handle, but a deterministic problem that has been forced into latent space—a combinatorial optimization problem.
The worst systems always misplace tasks on either side of this dividing line. The best systems, on the other hand, draw clear boundaries with a cold, hard touch.
5. Diarization (Document organization / Theme profiling)
The diarization step is the key to truly enabling AI to create value for real-world knowledge work.
It means that the model reads through all the materials related to a topic and then writes a structured profile. It condenses the judgments from dozens or even hundreds of documents into a single page.
This is not something that SQL queries can produce. Nor is it something that a RAG pipeline can produce. The model must actually read, keep contradictory information in mind at the same time, notice what has changed and when it has changed, and then synthesize all of this into structured intelligence.
This is the difference between database queries and analyst briefings.
This architecture
These five concepts can be combined into a very simple three-tier architecture.
• At the top layer are thick skills: processes written in Markdown, containing judgments, methodologies, and domain knowledge. 90% of the value lies in this layer.
In the middle is a thin CLI harness: about 200 lines of code, takes JSON as input, outputs text, and is read-only by default.
At the very bottom is your application system: QueryDB, ReadDoc, Search, Timeline—these are deterministic infrastructures.
The core principle is directional: push "intelligence" upwards to skills; push "execution" downwards to deterministic tools; and keep the harness lightweight.
The result of this is that whenever the model's capabilities improve, all skills automatically become stronger; while the underlying deterministic system remains stable and reliable.
A learning system
Below, I will use a real system that we are building at YC to demonstrate how these five definitions work together.
July 2026, Chase Center. The Startup School had 6,000 founders participating. Each person had structured application materials, questionnaire answers, transcripts of 1-on-1 conversations with mentors, and public records: posts on X, GitHub commit history, and Claude Code usage (which showed their development speed).
The traditional approach is for a 15-person project team to read each application, make an intuitive judgment, and then update a form.
This method works with 200 people, but it completely fails with 6,000. No human can hold so many profiles in their mind at the same time and realize that the three best candidates for AI agent infrastructure are the founder of a development tool in Lagos, a compliance entrepreneur in Singapore, and a CLI tool developer in Brooklyn—and they described the same pain point in completely different ways in different 1:1 conversations.
The model can do this. The method is as follows:
Enrichment (Information Enhancement)
There is a skill called /enrich-founder, which pulls all data sources, performs information augmentation and diarization, and highlights the differences between "what the founder says" and "what he actually does".
The underlying deterministic system handles: SQL queries, GitHub data, browser testing of demo URLs, social signal scraping, CrustData queries, etc. A scheduled task runs once a day. The profiles of 6000 founders are always kept up-to-date.
The output of diarization can capture information that keyword searches cannot find at all:
Founder: Maria Santos Company: Contrail (contrail.dev) Self-description: "The Datadog of AI agents" Actual work: 80% of code commits are concentrated in the billing module → Essentially, it's building a FinOps tool disguised as observability.
This discrepancy between "statement and actual behavior" requires simultaneously reading GitHub commit history, application materials, and conversation logs, and integrating them in the model's mind. No embedding similarity search can do this, nor can keyword filtering. The model must read the entire document and then make a judgment. (This is precisely the kind of task that should be placed in the latent space!)
Matching
This is where "skill = method call" comes in handy.
Using the same matching skill three times can produce completely different strategies:
/match-breakout: Processes 1200 people, clustered by domain, with 30 people in each group (embedding + deterministic allocation)
/match-lunch: Processes 600 people, cross-domain "random matching", 8 people per table with no duplicates - topics are generated first by LLM, and then seating is arranged by a deterministic algorithm.
/match-live: Handles real-time participants in the event, based on nearest neighbor embedding, completing one-to-one matching within 200ms and excluding people already seen.
Furthermore, the model can make judgments that traditional clustering algorithms cannot:
"Santos and Oram are both AI infrastructure, but they are not competitors—Santos does cost attribution, and Oram does orchestration. They should be in the same group."
"Kim applied for developer tools, but the 1-on-1 conversation revealed that he was working on SOC2 compliance automation. He should be reclassified as a FinTech/RegTech."
This reclassification is something that embedding cannot capture at all. The model must read the entire image.
Learning loop
After the event ends, a /improve skill will read the NPS survey results, diarize the feedback that is "okay"—not negative reviews, but those that are "just a little bit better"—and extract the patterns.
Then, it will propose new rules and write them back into the matchmaking skill:
When participants mention "AI infrastructure," but over 80% of their code is for billing modules:
→ Classified as FinTech, not AI Infra
When two people in the same group already know each other:
→ Reduce matching weight
Prioritize introducing new relationships
These rules will be written back to the skill file. They will automatically take effect the next time the skill runs. Skills are "self-rewriting". In the July event, the "okay" rating accounted for 12%; in the next event, it will drop to 4%.
The skill file learns what "okay" means, and the system becomes better without anyone rewriting the code.
This model can be transferred to any field:
Search → Read → Diarize → Count → Synthesize
Then: Research → Investigate → Diarize → Rewrite skill
If you were to ask what the most valuable cycle of 2026 is, it would be this one. It can be applied to almost all knowledge-based work scenarios.
Skills can be permanently upgraded.
I recently sent a command to OpenClaw on X, and the response was greater than expected:
Prompt: You are not allowed to do one-off tasks. If I ask you to do something that will be repeated in the future, you must: First, manually process 3 to 10 samples and show me the results; If I approve, write it into a skill file; If it should run automatically, add it to a scheduled task. The criterion is: if I need to ask you a second time, it means you have failed.
This post received thousands of likes and over two thousand saves. Many people thought it was a technique from prompt engineering.
Actually, no, this is the architecture I described earlier. Every skill you write is a permanent upgrade to the system. It won't degrade or be forgotten. It will run automatically at 3 AM. And when the next generation model is released, all skills will instantly become stronger—the latent part's judgment ability will be improved, while the deterministic part will remain stable and reliable.
This is the source of Yegge's claim of 100 times efficiency.
It's not about smarter models, but rather: Thin Harness, Fat Skills, and the discipline to solidify everything into competence.
The system will grow with compound interest. Build it once, run it long-term.
[Original Link]