Inside Claude Code's Leak: Harness vs. Skills Explained

I wanted to check the “100x productivity” claim for myself

Whenever I hear that productivity has jumped by some multiple, my first question is always: compared to what baseline? The claim that AI agents, used well, deliver 100x productivity struck me the same way. Instead of taking the number at face value, I wanted to look at how work actually changes when people use the same underlying model differently.

Around that time, on March 31, 2026, an incident occurred in which Claude Code’s client source was exposed through a source map in an npm distribution package. It was a codebase of roughly 510,000 lines. This wasn’t about the model’s weights leaking — it was the product code that calls the model and executes tools. I actually wrote a ZDNet column about this incident.

Y Combinator’s Garry Tan read through the code and wrote that it reaffirmed his conviction about a design approach he’d long been championing. What caught his attention was the program structure — how it fed the model the files and information it needed, and how it kept a task moving forward.

He titled that piece Thin Harness, Fat Skills. The proposal: keep the program that coordinates execution lean, and organize task-specific procedures into reusable skills instead.

What interested me wasn’t the productivity multiplier, but this division of labor. Even with identical model performance, the outcome of a task can vary enormously depending on what material the model is given to read, what tools it’s allowed to use, and how the results get checked.

Even the Same Model Runs Under Different Working Conditions

Tan’s piece opens by citing Steve Yegge’s bold claim about productivity gains: someone skilled at handling a coding agent is 10 to 100 times more productive than someone using a chatbot or other tools. But the piece offers no comparative experiment or shared metric that would let us generalize this multiplier.

So it’s hard to say the 100x figure was actually proven by the code-exposure incident. The more useful questions to check are far more specific: Does the model know the repository’s conventions? Can it locate the resources it needs? Can it run the code and then check for errors?

We need to look at these working conditions alongside the model’s own capabilities. It’s hard to argue that improving just one side of the equation solves every problem.

For instance, an agent asked to fix a piece of code has to read the relevant files, make the edit, receive test results, and decide on the next action. Without a program linking these steps together, the model’s responses never translate into actual work. Nor can the mere existence of an unreleased feature’s name or code tell us that the feature has actually shipped in the product.

The program that manages all of this — calling the model, executing tools, tracking task state and permissions — is called a harness¹. For the purposes of this piece, think of it as the part that manages the execution process so the model can actually get things done.

Looking at the fragment, I compared it carefully against the Korean source.

Let’s separate execution management, task procedures, and computational tools

Tan proposes putting the procedures each task requires into skills, while keeping the harness focused on executing those procedures and tools. This isn’t a standard structure to be applied uniformly to every system — it’s a design direction he recommends based on his own development experience.

What he criticizes is cramming in descriptions of tools you won’t even use, or adding unnecessary call steps. This can lengthen input and increase the time spent waiting for tool responses. That said, having many tools or using MCP² doesn’t automatically triple your tokens, time, and failure rate. You need to measure based on actual calls and actual tasks.

Here’s how the roles break down.

A skill³ is a bundle containing the procedures and reference materials for a specific task. At its center is SKILL.md, a markdown document, and you can bundle executable scripts or example files alongside it as needed. Tan gives the example of an /investigate skill that takes a research subject, questions, and materials and applies an analytical sequence.

The examples he offers are investigating emails related to a researcher’s safety concerns, and investigating relationships between corporations in campaign finance data. His point is that even across different materials, you can reuse a procedure of defining scope, arranging things chronologically, and examining conflicting evidence. These examples alone don’t prove the investigation was actually completed or achieved expert-level accuracy.

The harness calls the model and manages file/tool access, task state, and permissions. Tan proposes a lean CLI structure of about 200 lines, but the features you actually need depend on your operating environment. You shouldn’t skip permission checks or error recovery just to cut down lines of code.

Calculations or fixed condition checks can be delegated to a separate tool. For instance, calculating totals in a table or verifying that every item satisfies a given condition is better done in code — with the result then checked — than by asking the model to write out the answer. What’s meant here by deterministic processing⁴ is processing designed to produce the same result given the same input and state.

Seat assignment makes the distinction clear. You can use the model to organize opinions about who should sit together. But when assigning hundreds of people, verifying there are no duplicates or capacity overruns is better suited to checking conditions in code.

If the assignment conditions are complex, you might even use an optimization tool. But code or SQL isn’t automatically correct just because it’s code or SQL. Input data and constraints can be wrong, and programs can have bugs too. You need a process of separately verifying both the model’s judgment and the tool’s calculations.

The pattern is: skills record task sequences and judgment criteria, the harness manages execution, and tools handle calculation and data processing. Dividing roles this way makes it easier to pinpoint which part needs fixing when something goes wrong.

Skills Are Loaded Only When They’re Needed

Agent Skills was already public before the leaked-code incident. You don’t even need the leaked code to understand its structure — the official documentation lays out the file layout and how it works.

Anthropic introduced Agent Skills on October 16, 2025, and on December 18 announced it as an open standard usable across multiple products: a way of bundling a SKILL.md’s name and description, instructions, and additional files together. We need to separate two things: the public release of this file format, and the claim that Tan’s proposed harness design became an industry-wide standard.

The principle the official documentation emphasizes is progressive disclosure⁵ — reading needed information in order. First you read the name and description to judge which skill is relevant, then read the body of SKILL.md when it’s needed. Supplementary materials that the body points to can also be loaded only when the specific task calls for them. You don’t have to feed every document into the input from the start.

Tan describes a similar experience of his own. Because he kept adding everything he’d run into, his CLAUDE.md grew to roughly 20,000 lines, which he later trimmed to about 200 lines of guidance pointing to other documents. He changed the setup so that the model looks up the relevant document only when a given task arises. That’s his own operational experience — it doesn’t mean 200 lines is the optimal length for every project.

To make this approach work, simply splitting documents into shorter pieces isn’t enough. The explanation of which document to read under which circumstance has to be clear, and you also need to verify that the model actually finds the document it needs.

Oswarld’s Lens

Looking at this structure, I found myself thinking about how organizations retain operational knowledge. Even when regulations are written down and procedures are implemented in software, the actual sequence of what to check when reviewing a quote or a contract often lives only in the experience of whoever handles it. I realized this kind of knowledge could be split cleanly between documentation and tooling.

For instance, a quote-drafting skill could spell out the required inputs, the order in which to check the price sheet, the conditions under which a discount needs approval, and which items to verify in the final calculation. The actual price computation would be handled by a separate tool. Documentation like this can help the next staff member — or agent — reuse the procedure.

That said, I can’t quite agree with the part of Tan’s piece describing skills as a permanent upgrade. Procedures go stale too, whenever company policy or tools change. A new model might also interpret the same instructions differently. Just as code accumulates technical debt⁶, skills can accumulate a backlog of fixes and verifications that need to happen.

Security is something that has to be managed as well. Snyk reported that in a February 2026 scan of 3,984 public skills, at least one security issue was found in 1,467 of them — about 36.82%. This figure comes from an investigation targeting sources like ClawHub, and it can’t be generalized to represent the flaw rate across all public skills. It also lumps together malicious instructions and unintentional vulnerabilities alike.

Even in document form, a skill can affect file access or code execution. Someone needs to own its maintenance, keep a revision history, and review any part of it that sends data externally or executes commands. I’d argue that a skill only becomes a genuinely useful organizational asset once this kind of management is built in alongside its reusability.

Closing

Coming back to the question I started with: the name “harness” or “skill” alone can’t explain a 100x productivity gain. You need to look at how long it took to reach the same quality of output, how much time humans spent fixing it afterward, and how many attempts failed along the way. Frankly, I care more about these comparisons than about big multipliers.

Choosing a model has to go hand in hand with preparing the working environment. If you decide in advance where the necessary information lives, which tools to use, and what counts as success, it becomes much easier to trace the cause when results go wrong.

Even as new terminology keeps piling up, I don’t think you need to memorize every name. What matters is understanding which program manages execution, which document lays out the workflow, and which tool scores the output — that’s enough to have a real conversation about adoption.

If you’re going to introduce skills, I’d suggest starting with a single repetitive task. Document the procedure, apply it to real cases, and fix whatever conditions were missed or results that came out wrong. And whenever you change the model or the procedure, verify it again against the same cases.

As these verified procedures accumulate, sharing the team’s experience becomes much easier. I’d argue the real yardstick isn’t the number of documents or how long the harness’s code is, but whether it actually helped on the next task.

If your team has managed to cut down a repetitive task using an agent, I’d love to hear about it — what actually got reduced, and what still had to be checked by hand. Experiences like that are what make conversations about adoption concrete.

References & Further Reading

Primary sources

• Garry Tan, “Thin Harness, Fat Skills”, gbrain GitHub repository, 2026. : This piece lays out Tan’s design proposal alongside his personal operating experience. It isn’t an experimental report validating productivity multipliers.
• Anthropic, “Equipping agents for the real world with Agent Skills”, Anthropic Engineering Blog, October 16, 2025 (updated regarding the standard published December 18). : This document explains the SKILL.md standard and the Progressive Disclosure design principle in detail. If you want to build a skill yourself, start here.
• Steve Yegge, “The AI Vampire”, Medium, February 2026. : A personal essay discussing the experience of using agents, along with workload intensity and fatigue.
• Gergely Orosz, “Steve Yegge on AI Agents and the Future of Software Engineering”, The Pragmatic Engineer, February 2026. — An interview featuring Yegge’s views on his agent usage experience and adoption.

Background

• VentureBeat, “Claude Code’s source code appears to have leaked: here’s what we know”, March 31, 2026. : Reporting on the Claude Code source exposure that occurred on March 31, 2026.
• Zscaler ThreatLabz, “Anthropic Claude Code Leak”, April 2026. : An analysis of a case where the source exposure was used as bait to distribute malware. The Axios supply-chain attack on the same day was a separate incident.
• Snyk, “Agent Skills Security Audit Report”, February 2026. : Of the 3,984 skills examined, 1,467 were reported to have security issues. The scope of the investigation and its detection criteria should be read alongside the findings.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

Footnotes

1. Harness: refers to a program that manages model calls, tool execution, task state, and permissions. The functions it covers vary by implementation. ↩

2. MCP (Model Context Protocol): an open protocol that defines how AI applications connect to external tools and data. It can be used alongside skills, which carry the actual work procedures. ↩

3. Agent Skill: a package combining SKILL.md instructions with scripts and reference materials as needed. Adding documentation doesn’t automatically guarantee accuracy or expertise in the relevant field. ↩

4. Deterministic processing: processing that produces the same result given the same input and the same state. Even the results of code or SQL can vary depending on data, execution environment, timing, or use of randomness, so these conditions must be managed together. ↩

5. Progressive Disclosure: a method of reading needed information in stages. Relevance is judged from a skill’s name and description, and the body and supporting files are loaded only when needed. ↩

6. Technical debt: a state in which short-term choices or deferred improvements incur additional costs for later modification and operation. ↩