The team that built Plan Mode is tearing down its own scaffolding

Thariq Shihipar joined Anthropic's Claude Code team a year ago and has since become one of the product's most public faces. In his account, capability overhang describes a simple mismatch: the model's intelligence exceeds what the harness, the interaction, the available tools, or the user allows it to express. The harness is the layer wrapped around the model, including orchestration, tools, and interaction design, that determines how much of the model's ability is actually used. Shihipar considers this mismatch a likely permanent condition: "if you were to freeze model development right now, you'd probably still be figuring out new capability overhang for another 6 or 12 months."

The difficulty is that models do not improve along a smooth or predictable curve. They become more capable in uneven, non-intuitive ways, making it hard to anticipate which new behaviors a model generation will unlock. Shihipar points to a common thesis from 2024: models would become effective at coding once context windows grew large enough. With a 100 million token context window, the reasoning went, the entire codebase could be supplied at once and the model could solve the problem from there.

Claude Code emerged from a different realization. Instead of waiting for a context window large enough to contain everything, the model could assemble its own context by using grep, an old command-line tool for finding text or code by keyword, to retrieve only what it needed as it worked. Without that realization, the team might simply have waited for the larger window. This fork captures capability overhang: an external condition appears to be missing, while the model already has another route that nobody has learned to expose. Models become better in ways that are difficult to explain in advance; as Shihipar puts it, "you just have to grok internally."

Plan Mode is a Claude Code mode in which the model works out a plan before executing it. According to Shihipar, it arose partly as a scaffold for a model that was not yet capable enough to handle a request reliably from a cold start. The plan had to be made explicit up front because simply asking the model to proceed did not work consistently well.

That requirement has begun to disappear. A lot of the team has now stopped using Plan Mode, for one reason:

In Shihipar's description, sufficiently detailed instructions are now often enough for the model to determine both what to do and how to execute it. Plan Mode, built as a fallback during the Opus 4 era, illustrates the short half-life of scaffolding around fast-improving models: a feature can move from necessary to redundant after a single step in model capability. Although the broader coding community still commonly teaches "plan first, then code," the team that built the mode was among the first to stop relying on it.

This does not mean the model produces perfect results. Shihipar locates many remaining failures in ambiguity: when the user has not clearly specified the intended outcome, the model must guess. That changes where improvement may need to happen. In his words, "it's more important to educate humans than improve the agent UX sometimes." The resulting system cannot be reduced to model × harness. It is model + harness + user + world, all operating at once.

If abandoning Plan Mode means tearing down an expired scaffold, workflows represents the other side of the same argument: letting the model construct a better-fitting scaffold for the task at hand. Released by the Claude Code team on the day of the interview, workflows is a feature that builds a custom harness for a task on the fly and then runs it. As Thariq put it, "it essentially creates a custom harness on the fly." Instead of forcing every task through a fixed sequence designed in advance, the model can assemble the process it needs for the specific outcome.

Deep research shows why this matters. Deep research is a long-running task that requires many searches and repeated synthesis, potentially involving a hundred different searches. Previously, a developer would have had to code a harness that decided how to perform those searches, preserve intermediate findings, and combine the results. With workflows, Claude creates that harness as part of the task and then executes it. Simply telling Claude Code to spend a long time researching something is not enough: the work may not fit inside its context window, and even sub-agents may not provide sufficient structure to complete it. A purpose-built harness gives the model a process capable of carrying the task beyond those limits.

This makes planning for future model generations difficult. According to Thariq, the Claude Code team rewrites substantial parts of its harness repeatedly, because stronger models change which controls remain necessary and which become constraints. His framing is to plan around improving outcomes rather than preserving a known process. The mechanism may change as the model becomes more capable, but the system should be designed to accept a better result: plan for outcomes to get better even if you don't know how the process will work.

Asked whether memory and skills would converge across platforms, Thariq emphasized that much of today's scaffolding was always meant to be removed as models improved. Memory, the mechanism that lets an agent retain information across turns and sessions, is an extremely high-dimensional problem, because it can be implemented through RAG, file search, training, or an RL environment, meaning a simulated setting in which a model practices during reinforcement learning. The range of possible implementations makes early architectural commitments unusually fragile.

One recurring problem, in his account, begins when a startup builds its first memory system around one generation of model capability. The founder may produce a workable v1 but then struggle to hire someone capable of designing the v2, because harness engineering remains a rare skill. The result is a memory architecture that stays tied to whatever was initially built for Opus 4, even as the underlying models change. Thariq's assessment is that Opus 4.7 and 4.8 are already effective at reading and writing memory through files, which is now how the Claude Code team expects memory to work. Once that pattern becomes established, bespoke scaffolding designed for an earlier capability level becomes difficult to justify. He put it bluntly:

RAG is a particularly clear example. RAG is the approach of dividing material into chunks, converting those chunks into embeddings, indexing them, and retrieving selected material when a query arrives; an embedding turns text into numbers so a machine can compare passages by meaning. Thariq's judgment was that "rag especially for context search is now like maybe an anti-pattern … you should use grep instead." An anti-pattern is an approach that was once considered standard but has become more likely to create problems than solve them. He cited startups that built RAG indexing systems in 2024 and now find those systems a drag on scaling. This does not mean RAG is useless; the narrower claim is that RAG built specifically for context search has, in his reading, been overtaken on cost-effectiveness by models that can inspect and read the code directly.

If both the models and the harness keep changing fast, how can a team tell when something is "done"? Several audience questions returned to this, and Thariq's answer is counterintuitive.

He describes harness engineering, the craft of designing the orchestration, tools, and prompting around a model, as largely an art. An eval, meaning a test set used to score whether a model or feature is working, is somewhat more scientific because teams can hill-climb against it, tuning the system against a score and improving it a little at a time. But evals are not necessarily where new development begins. In the early stages of a feature, his team often does not use them: for workflows, the team did not first construct an eval for long-horizon tasks and then build the feature against that test.

His advice is that many startups may not need to build evals at all in their earliest phase; they may learn more by iterating quickly and developing direct intuition for whether a feature works. Evals become critical at a different transition: when the person who built the first version begins managing other people who build the next one. At that point, evals make the work legible, turning performance into something others can inspect and use. Making a process legible, he cautions, is not the same as producing a good result.

There is a deeper limit too: no team can write an eval for every possible failure in advance. When people say Claude Code feels less capable, a public benchmark like SWE-bench can test whether its software-engineering ability has declined; but the complaint may instead be that the agent stops early when it should continue. Testing that would require a specific "stop-early" eval, and the need for it becomes visible only after the problem appears. In Thariq's account, evals remain very valuable, but they chase problems; they can't enumerate them in advance.

The last stretch is about founders, and Thariq repeatedly qualifies his advice: he has not built a successful startup himself, and in his view nobody is an expert on a field this unpredictable. Even Anthropic must make commitments years ahead, spend billions on compute, and bet that future demand will repay the investment.

He describes the present as an age of exploration, in which companies and frontier labs alike are still discovering what has become possible. Starting a company is no longer the safe, high-status choice it once appeared to be. Because the environment keeps changing, he argues that founders need genuine interest in uncertainty and an internal conviction that they can operate through it.

One direction, in his view, is to build products complementary to the model labs. Much of the world remains inaccessible to agents: an agent cannot simply reach a person's health records or bank data. Making those gated sources legible to agents means turning information they cannot currently reach or read into something they can access and use. Extending AI into regulated and restricted domains can be valuable, but access is fundamentally a human problem: someone must persuade institutions to share data and navigate the red tape. As the cost of building falls, defensibility shifts toward those human obstacles.

A second direction is boiling the ocean: attempting projects that previously seemed too large to undertake, rather than simply adding AI to an existing product. Thariq cites Chang, formerly on the React team, who was dissatisfied with browser text rendering and built a custom text-rendering library that he could not have built before. The same framing applies to problems that once appeared to require 20 million or 500 million lines of code.

In the end, he describes product design as a forecast. Conductor, a GUI for Claude Code, reflects a bet that models will commoditize and perhaps follow an S-curve, a pattern that begins slowly, accelerates, and eventually flattens. A product people genuinely value may endure across those shifts. Every product, he says, is a bet on where the capabilities are going.

This piece draws only on the one public conversation below; it adds no outside commentary. Quotations are taken from the auto-generated transcript, with obvious mis-transcriptions corrected in context (e.g. grep, Karpathy). Thariq's own judgments are attributed to him.