Surfing the Models, an Outsider View on Claude Code

The team that built Claude Code talks about it constantly, and that is useful, but the sharpest external read I have heard this year came from Vaibhav Gupta at BoundaryML, the team behind BAML. On a recent ai-that-works session, Gupta dropped an analogy that reframed how I think about the whole tool. "Claude Code's team is like a compiler," he said. The rest of the hour kept earning that framing.

The compiler analogy is more than a clever line. It points at a specific decision every team using Claude Code has to make, and it gives you a rule for when to invest in custom tooling versus when to lean on what Anthropic ships by default.

The Compiler Analogy

Here is the full quote from Vaibhav Gupta on the Apr 21, 2026 ai-that-works session:

If you have ever worked on performance-sensitive C++, the framing lands instantly. Modern compilers fold constants, vectorize loops, reorder instructions, inline aggressively. Most of the time, beating them by hand is a fool's errand. The exception is when you know something the compiler does not, like a specific memory access pattern or a hot path that only matters under a particular workload. Then handwritten assembly wins, but only there.

Apply that to Claude Code. The default harness gets autoloaded CLAUDE.md, compaction, MCP wiring, subagents, hooks, skills. Most teams who rip that out to build their own agent loop end up rebuilding the same boring infrastructure, except worse, because they have two people on it instead of fifty. The compiler wins by sheer engineering volume. This matches what Boris Cherny has said from inside Anthropic about keeping the harness vanilla. The same conclusion, arrived at from a completely different vantage.

That 10% is not nothing. If you genuinely have domain knowledge that no general harness can replicate, custom tooling is the right call. But the test should be high. You should be able to name the specific thing you know that Claude Code's defaults do not, and you should be able to measure the lift. Otherwise the compiler wins.

A Harness Is the OS Around the While Loop

The other line from that session that I keep returning to is Gupta's definition of a harness itself:

This is worth slowing down on. The agent loop is genuinely simple. You assemble a context, the model picks a tool, the tool runs, the result goes back into the context, you loop. That pattern has been stable for years. What has changed, dramatically, is everything wrapped around the loop. Compaction strategies that decide what to drop when the window fills up. CLAUDE.md autoloading that pulls in project context without you asking. MCP servers that register tools on the fly. Skills that load specialized prompts when triggered. Hooks that run before and after every action. None of that is the loop. All of it is the operating system around the loop.

Angela Jiang at Anthropic made the same point from the inside at Code w/ Claude 2026:

The two framings rhyme. Jiang is warning that a harness designed to be model-neutral leaves performance on the table. Gupta is explaining why: the harness is the OS, and an OS that does not know its hardware cannot exploit it.

Once you see the layers clearly, the trap is obvious. The middle layer, the harness itself, is where the unsexy engineering volume lives. It is also where teams without 40-50 engineers reliably fall behind. The outer layer, your custom skills and slash commands and subagents, is where your alpha actually shows up. The mistake is spending your budget on the middle when the outer is where the leverage is.

Exhaust the First While Loop Before Adding a Second

On the same session, Dex Horthy offered the most useful operational rule I have heard for multi-agent design:

The discipline here is unfashionable. The field is racing toward multi-agent everything, orchestrators dispatching subagents dispatching subagents. Horthy is saying that most of those architectures are premature. A single well-prompted agent with thoughtful tools and clean context can do a startling amount of work. Adding a second loop multiplies failure modes, doubles your debugging surface, and often does not improve the outcome. You should only add the second loop when you have actually run the first one to ground and know specifically why a single agent cannot get you there.

This lines up with what Sid Bidasaria at Anthropic calls "let the model cook." Both framings push back on the impulse to over-architect. The model is smarter than you think. The harness wrapping it is more capable than you think. Add complexity only when the data forces you to.

There is a corollary worth saying out loud. If you cannot articulate exactly what the first loop is failing at, you have no business designing the second loop. Most multi-agent systems I have seen in the wild fail this test. They were built because multi-agent felt like the next step, not because anyone hit a concrete ceiling with a single agent first.

Tool RL Is the Real Product Alpha

This was the part of the conversation that genuinely surprised me.

The naive view of model-harness pairing is that any modern frontier model can drive any reasonable harness, and what you are picking between is mostly raw model quality. Gupta is saying that view is wrong, and the evidence is right there if you try the experiment. Claude has been reinforcement-learned against the specific Claude Code tool interfaces. The model knows what old_string and new_string mean operationally. It knows the failure modes of the bash tool. It knows what a successful read followed by a successful edit looks like as a sequence. A model trained against a different tool surface, even a model of comparable raw capability, simply does not have those reflexes.

The implication for builders is sharp. Your harness choice is not just a UX decision. It locks in your model choice, because switching harnesses costs you a meaningful chunk of the alpha you were paying for. This is also why Anthropic ships the harness and the model together. They are coupled artifacts, RL'd against each other. Treating them as independent components misreads what is actually happening.

This also means that as Claude Code ships new tool interfaces, the model behind it will keep getting better at those interfaces specifically. Anyone trying to swap the model out is fighting against that ongoing optimization. The gap will not close.

Gupta was emphatic about this on the session, and it is the single sharpest piece of practical advice in the conversation:

It is also the most ignored.

Design Once, Implement With Agents

On the follow-up session a week later, Gupta described how BAML's threading system actually got built. He spent four days designing it before writing a single line of code. Not because he was stuck, but because a thorough enough design means you can break the work into five chunks, each of which a coding agent can implement without additional guidance.

This is the leverage pattern that gets undersold. Most discussions of AI-assisted development focus on the implementation phase, faster typing, better autocomplete, smarter refactors. The actual unlock is upstream. If your design is precise enough, implementation becomes parallelizable across agents. Four days of careful thinking can compress two weeks of implementation into an afternoon of agent dispatching. The cost is the design discipline, which is genuinely hard and not what people want to do.

Thariq Shihipar at Anthropic has talked about an "interview me" pattern, where the model interrogates you to extract design intent before writing anything. Same insight, opposite direction. From inside Anthropic, the model pulls the design out of you. From outside, at BoundaryML, the human does the design work first and feeds it to the model. Both are correct. Both rest on the same observation, that agents implement well only when the design is sharp enough to leave nothing ambiguous.

What This Means For You

• If you're a founder: Trust the compiler. Build custom harness only when you can name a specific domain advantage Claude Code's defaults cannot reach. Spend your engineering on skills, slash commands, and integrations, not on rebuilding the loop.
• If you're changing careers: Surf the models. The code you write against this month's model may expire, but the intuition for how to use frontier models compounds. New model drops are a head start, not a reset, if your context engineering is solid.
• If you're a student: Watch the ai-that-works sessions for the outside-Anthropic view of the same patterns. Hearing two people from completely different teams converge on the same conclusions is the fastest way to learn which conclusions are real.