Harness Shrinkage as Models Improve

Sources#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Beyond RAG: Building Agentic Document Workflows with LlamaIndex
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Claude Fable 5 and Claude Mythos 5
• Coding Agents and Technical Debt
• Fable's judgement
• Garry Tan: Own Your Intelligence
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models
• Prompting Claude Opus 5
• Recursive Self Improvement for Coding Agents
• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI
• The new rules of context engineering for Claude 5 models

Summary#

The harness — prompts, skills, scaffolding, mechanical verification — exists to compensate for what the underlying model cannot yet do. As models improve, the harness needs to shrink, not grow. Boris Cherny explicitly predicts Claude Code "may be 100 lines of code a year from now." Cat Wu reports the team reads the entire system prompt with every model launch and removes anything the new model handles natively. The principle works in two directions: capabilities the harness used to inject move into the model, and crutches the harness used to provide become drag.

The to-do list as canonical example#

Cat Wu's case study:

• Early Claude Code: asked to refactor 20 call sites, the model would change 5 and stop. The team added an explicit to-do list tool ("Sid on our team was like, what would a human do? Make a list, go through one by one"). With the tool prompted aggressively, the model finished all 20.
• Opus 4 onward: model uses the to-do list spontaneously, no aggressive prompting needed.
• Today: to-do list is "deemphasized" — model may or may not use it, doesn't need to be reminded, mostly kept around for user-facing visibility.

The crutch (the prompt section forcing to-do list use) was removed; the tool stayed for a different reason (UI value).

The Boris claim: 100 lines#

"I think Claude Code itself may be 100 lines of code a year from now."

Read literally this is hyperbole, but the direction is real:

• Anthropic now uses the same models internally that ship externally, so internal harness lessons transfer
• Each model release lets the team delete prompt sections, shrink fallback logic, remove safety wrappers (per Cat Wu: "all the safety mechanisms today — prompt injection, static verification of commands, permission modes, human in the loop — will be less important because the model will just do the right thing")
• The product surface stops being "what the harness does" and becomes "where the model decides to do it" (CLI, mobile, web, IDE, all sharing the same model logic)

The flip side: capabilities migrate inward#

Boris reports Opus 4.7 spontaneously starts loops:

"I'll tell it 'pull this data query.' It says 'I noticed the data is changing — I'll start a loop and report every 30 minutes.'"

The /loop primitive (see Agent Loop Pattern) was introduced as a harness feature; in 4.7 it is becoming model-native behavior. The harness primitive doesn't go away — but the user no longer needs to invoke it.

This generalizes: anything the harness teaches the model how to do via a prompt section is a candidate for migration into the next model's training data.

The cleanest demonstration: Fable 5 plays Pokémon with no harness#

The June 2026 Fable 5 launch supplies the most legible version of the whole thesis. Earlier Claude models "struggled to play Pokémon FireRed even with harnesses that gave them additional helpful tools" — maps, navigation aids, game-state readouts. Fable 5 beat FireRed with a minimal, vision-only harness: raw game screenshots, nothing else. The scaffolding that compensated for weak spatial/visual reasoning didn't get improved — it got deleted, because the capability moved into the model. The same pattern shows up in Fable's memory results: file-based persistent memory improved Fable's Slay the Spire play 3× more than it improved Opus 4.8's — the model got better at using the harness affordance, so less hand-holding around it is needed. Vision and long-horizon memory are exactly the axes where 2025-era agents needed the most scaffolding; they are now among the first to dissolve.

The wrong direction: harness bloat#

The opposite failure mode is worse than no harness — it actively degrades the model:

• Cat Wu: "What models are capable of in [a one-month] timeline" is the hardest forecast for PMs; over-specifying the harness for an old model wastes tokens that the new model uses better unsupervised.
• Matt Pocock: 250K-token system prompts push the model into the dumb zone before it does anything (see Context Window Smart Zone).
• Repeated capability injections drift toward contradiction: rule X for case A, rule Y for case B, until the model can't tell which applies.

A ceiling, measured independently (2026-08-04). Every argument on this page for keeping the prompt short is Anthropic-sourced and reasons about tokens — Pocock's dumb zone, Cherny's ablation, Thariq's >80% deletion. Eliav 2026 (arXiv 2607.19257, empirical, sole author, five models including Sonnet 5 and Haiku 4.5) supplies the first outside measurement, and it binds on a different quantity: the rate at which every instruction in a prompt is obeyed falls steeply by 40 simultaneous verifiable rules and reaches zero by 80, holding flat through 160, identically across markdown / plain / prose / table rendering and both prompt slots. The rules are distinct and individually satisfiable, so this is not compounding and no per-line ablation would find it — which means Cherny's line-by-line add-back method, correct as it is, cannot detect the condition where a prompt of individually-justified lines is simply too many lines. "Delete your CLAUDE.md every 6 months" now has a number to aim at, and it is a count rather than a length.

The vendor states it as an instruction (Opus 5, July 2026)#

Everything above is inference from how a team works. Anthropic's Opus 5 prompting guide (vendor-claim) is the first place the vendor writes the pruning rule into public documentation as an imperative — and it makes two upgrades to the thesis:

1. Some scaffolding doesn't go redundant, it goes harmful. "If your prompt contains explicit verification instructions… remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality. The same applies to legacy harness scaffolding that adds separate verification steps." Cat Wu's discipline saves tokens by cutting reminders the model no longer needs; this cuts lines that make the output worse by adding to a behavior the model now performs on its own. A team that keeps a stale instruction because "it can't hurt" is wrong, which turns the prune-at-every-launch pass from housekeeping into a correctness obligation. Developed at Instruction Compounding; the same guide tells you to re-validate prompt-side vision workarounds, which "may no longer be needed" — the Fable-5-plays-Pokémon result restated as migration advice.

2. The pass has two directions. The same document adds prompt: Opus 5's conversational replies, agentic narration, and written files all run longer by default, and effort does not control any of it, so length calibration is prompt that did not need to exist a release ago (Output Length Calibration). Capability scaffolding comes out; communication scaffolding goes in. This is the model-facing/human-facing asymmetry below (HTML as the New Markdown) showing up inside a single system prompt rather than across two products.

The measured deletion: >80% of the system prompt (Claude 5, July 2026)#

Thariq Shihipar's context-engineering post (July 2026) supplies the largest concrete number the thesis has: "We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations" (Anthropic-measured, stated without published data). His framing is "unhobbling" — the team found it was over-constraining the model, and reading transcripts of internal usage showed why: conflicting instructions arriving in a single request ("leave documentation as appropriate" vs. "DO NOT add comments") as system prompt, skills, and user requests clash. The model can usually resolve the conflict, but must spend thinking on arbitration that a cleaner context wouldn't demand — Instruction Compounding's drift-toward-contradiction observed in the vendor's own transcripts.

The canonical before/after is the comments rule. Old system prompt: "default to writing no comments. Never write multi-paragraph docstrings… one short line max." New system prompt: "Write code that reads like the surrounding code: match its comment density, naming, and idiom." A hard rule that was wrong for a subset of prompts (users with documentation preferences, complex code needing real comment blocks) replaced by a judgment delegation — the guardrail was a tradeoff accepted for older models' weaker judgment, now deleted because the judgment moved into the model.

The pruning discipline is also now productized for users: the claude doctor / /doctor command applies the same rightsizing to your own CLAUDE.md files and skills — Cat Wu's read-the-whole-prompt-at-every-launch pass shipped as a tool anyone can run.

The same move, prescribed to users (Willison, July 2026)#

The comments-rule rewrite above is Anthropic doing this to its own system prompt. Simon Willison (2026-07-03, practitioner-opinion) records Cat Wu and Thariq Shihipar prescribing it to users, at an AI Engineer World's Fair fireside he hosted: let Fable "use their own judgement rather than dictating how they should work." Their worked example is the comments rule in a different domain — you can tell Fable "only use automated testing for larger features, don't update and run tests for small copy or design changes," but "it's better to just tell Fable to use its own judgement when deciding to write tests instead."

Two things this adds. The pruning obligation moves onto the user's prompt, where none of this page's machinery reaches — a hard rule in someone's CLAUDE.md is the same class of artifact Anthropic ablates at every launch, and nobody runs SIMPLE=1 on it. And the replacement is a delegation, not a deletion: deleting a rule leaves the model to its defaults, while "use your judgement" hands it a decision it now knows it owns. Every measurement on this page is of the deletion form; whether the delegation form beats either the rule or the silence is unmeasured here and everywhere else in the corpus.

Willison's own test points the delegation at model routing: "For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent." That is Nathan's model-decides-the-surface-route observation above with the target changed — a user moving model selection into the model, by prompt, without waiting for the vendor to move it. Evidence value is low: one developer, no measurement, the tip itself second-hand (from Jesse Vincent), and the reported outcome is "it seems to be working well" plus a Fable allowance "shrinking less quickly than before."

The methodology, from the source: ablation, and a gain without the prompt#

Cherny's YC interview (July 2026) is the first place the >80% deletion's method is described, and it upgrades the headline in three ways:

1. The deletion is an ablation, run at every model release. "You delete the entire system prompt and then you bring it back line by line to figure out what is the impact of each individual line" — an eval where deletion measures each line's contribution. The same discipline applies to tools ("we unship tools all the time"). The add-back rule is strictly empirical: don't guess what instruction the model needs — run the product, watch where it repeatedly stumbles on the same thing, and only then add the line, "because the model is going to read this instruction every single time."
2. The result is stronger than "no eval loss." The undocumented SIMPLE=1 environment variable strips all prompts, including the tools' — the team's standing ablation switch — and "what's interesting is that the model is actually a little bit more intelligent without these prompts." The residual prompt exists for product behavior (helping the model act the way a person using the product wants), not capability. This sharpens Thariq's "no measurable loss" above into a mild measured gain, and hands users the same experiment: --system-prompt accepts a full replacement.
3. What's left of the harness isn't prompts at all. "If you look at the code that's in the Claude Code harness today, almost all of it is about safety and permissions and static analysis and there's a bunch of UI code" — the surviving harness is exactly the boundary-enforcement residue the Resolved Question below predicts, stated by the harness's owner.

The user-facing corollary is now explicit advice rather than inference: "every 6 months delete your Claude MD. Delete your skills. Delete your hooks. See what the model does" — pruning as a calendar discipline for everyone, not just the vendor.

The non-Anthropic check: OpenAI ships an architecture that presupposes this#

Everything above is sourced from Anthropic — Cherny, Cat Wu, Thariq, the Opus 5 docs, the Fable 5 launch. The thesis had no independent vendor confirmation until OpenAI's July 2026 ChatGPT Work merge, described by Akshay Nathan on Latent Space (Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI, practitioner-opinion). It doesn't restate the thesis — Nathan never discusses prompt pruning — but it presupposes it, in two ways:

1. The surface-differentiation residue matches Cherny's harness residue. OpenAI runs Codex and ChatGPT Work on one shared harness and differentiates only three things: git-state visibility, diff-forward chain-of-thought display, and sandboxing defaults. That is permissions and UI — the same short list Cherny gives for what survived Claude Code's ablation ("safety and permissions and static analysis and… UI code"), reached from the opposite direction (forking one surface into two rather than deleting until nothing more can go). If capability still lived in per-surface prompt scaffolding, "same harness, wildly different audiences" would not be shippable. See Shared Harness, Differentiated Surfaces.
2. Routing became model behavior. Asked whether ChatGPT's hand-off to Work mode is a router, Nathan says "this is the decision that the model is making… it sees that you're trying to do something that would be better served in Work mode." A dispatch rule that would have been harness logic is now a model judgment — the same migration as the spontaneous-loop observation, at the product-surface layer.

The counter-current in the same source. OpenAI is simultaneously growing the user-facing knob surface: "there's 32 options" across model classes and reasoning levels, plus a slider, plus Ultra, plus sub-agent controls — and Nathan concedes "one could argue that there might be too many right now, and we're working on simplifying it." This is not a contradiction of the thesis; it is the model-facing/human-facing asymmetry again, with the human-facing side visibly overshooting. What OpenAI is pruning is the human's configuration surface, not the model's prompt.

Process: read the system prompt at every launch#

Cat Wu's discipline:

"We read through the entire system prompt and we reflect on, okay, for each of these sections, does the model really need this reminder anymore? And if not, we'll remove it."

This is a backwards practice — most teams would only add to a prompt, not subtract. Doing it on a cadence aligned to model launches is what keeps the harness from accreting.

Build for the next model, not this one#

Counterintuitive corollary from Boris:

"We were trying to build this thing that was like pre-PMF, and we knew that it wouldn't have PMF for 6 months because we were building for the next model."

Most products are built for the model they're released against. Anthropic builds Claude Code for the model six months out — accepting it doesn't quite work today, with the bet that the next release closes the gap. This shifts what "harness work" means: not "make the current model usable" but "build a product surface that will work when the model arrives."

Cat Wu's variant: "It's pretty important to build products that don't necessarily work yet so that you know what is missing for this product to work, and then with the newest model you can just swap it in."

Dan Carey gives the cleanest retrospective case: Claude Design's early-prototype gaps were closed not by clever engineering but by Opus 4.7 shipping ("the model releases are a tide that lifts all boats"). Dedicated treatment, with the next-model-vs-AGI-strawman calibration: Build for the Next Model.

The same claim from the retrieval side — and where it stops#

Every measurement on this page is taken on a coding harness. Doulcet's 2024→2026 RAG retrospective (AI Engineer Singapore 2026, practitioner-opinion, LlamaIndex vendor COI, no measurement) states the identical trend for the retrieval stack, and Jerry Liu's summary line when publishing it is this page's thesis in retrieval vocabulary: "how we've increased offloaded logic to the agentic loop as models improved — and coincidentally, the retrieval layer can get simpler."

The worked instances are concrete and they run the full ladder:

• Hand-written query transforms deleted. HyDE (draft a hypothetical answer, embed that) and multi-query + Reciprocal Rank Fusion were the 2024 way to close the user-speak/document-speak gap inside one retrieval call. The 2026 verdict is deletion, not tuning: "both are subsumed by agentic loops — an agent that grades and rewrites does this dynamically, and recovers when the first attempt misses." Kept only as literacy for reading 2024-era code.
• The loop itself absorbed into the weights. Search-R1 / R1-Searcher (2025) RL-train reasoning models to call search() mid-thought, so the retrieval loop a team used to hand-write "ends up baked into the model itself." Adaptive-RAG squeezes from the other side by routing most queries away from any loop at all. The formulation is the sharpest version of this page's thesis found in another domain: "the workflow shape sticks around; what runs inside each step keeps changing."

Where it stops is the more useful half, and it is a scope condition this page has not previously had. The layer the deck says did not get simpler — and got harder — is parsing: turning bytes on a page into structure. That layer is deterministic software operating on inputs the model never sees, and its failures are byte-level rather than judgment-level, which is exactly Layerwise Omission Attribution's deterministic/behavioral split. The generalization worth extracting: what shrinks is scaffolding that substitutes for model judgment; what persists is machinery that changes what reaches the model at all. That is the same boundary as the Pocock counterpoint below (mechanical verification is infrastructure, not instruction) and the same boundary as Crystallizing Agent Work into Workflows's authority-versus-instruction distinction, now with a third instance from a fourth domain.

The one live tension is that the deck also sells the parser. Its own cost-vs-accuracy figure shows a general frontier VLM at its high setting landing within ~9 points of the specialist parser — narrower than the accompanying prose claims, and the direction this page would predict. Recorded as an open question there rather than settled here.

Counterpoint: harness still matters#

Not every voice agrees. Matt Pocock argues the harness — feedback loops, deep modules, mechanical verification — is the ceiling:

"If your code base doesn't have feedback loops, you're never ever ever going to get decent AI decent output out of AI. The quality of your feedback loops influences how good your AI can code, essentially. That is the ceiling."

The synthesis: prompt scaffolding shrinks as models improve; mechanical verification remains essential. Tests, types, linters, isolated review contexts — these are infrastructure that the harness provides and that doesn't migrate into the model the way capabilities do.

The counter-datum: harness codebases are not shrinking#

Every measurement above is taken on the system prompt. OpenHands' July 2026 GitHub analysis (Coding Agents and Technical Debt, case-study) is the first in the corpus pointed at the codebase, and it points the other way: four coding-agent harnesses — OpenHands, Codex, OpenCode, Hermes — each carry 1.05M–1.75M lines and absorbed 5,679–7,736 merged PRs in twelve months, with Codex accelerating from ~124 merged PRs/month in mid-2025 to ~1,000/month a year later. Full treatment, with the vendor-interest caveats, at Harness Build-vs-Buy.

Most of the apparent conflict dissolves on inspection, in three steps: prompt is not codebase (deleting 80% of a prompt removes no lines from an app server or a UI); Cherny's own residue list is exactly what a million lines looks like — "safety and permissions and static analysis and… a bunch of UI code" is not a small program, and OpenHands prices its surface half at 313K lines (Agent Canvas 246K + CLI 67K) before the server or the runtime; and the pruning discipline is itself PR volume — Cat Wu's read-the-prompt-at-every-launch pass and Cherny's line-by-line ablation are merged PRs, so a faster model cadence raises maintenance flow while lowering steady-state prompt size. Churn and size are different variables, and this page has only ever measured one of them.

What survives the reconciliation is a directional problem for the "100 lines" prediction below: it is a claim about the harness codebase, the only trajectory anyone has measured for that variable is up, and it is case-study public data against a self-labeled hyperbolic prediction. Not a falsification — the prediction is about Claude Code specifically, and Claude Code is closed-source and absent from the comparison — but the first evidence against the reference class.

The counter-current with a slope: harness leverage#

The counter-datum above is about size. Writer's harness-swap paper (The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI, arXiv 2607.06906, 2026-07-08, empirical with a total vendor COI — see Orchestration Sets Token Economics) supplies one about direction, and it is the sharpest challenge this page has taken.

Holding 22 tasks and six models fixed and swapping only the orchestration layer, efficiency improved for every model (cost −33% to −61%, no exceptions) but quality gains tracked baseline model strength almost perfectly: Palmyra X6 +0.079, Sonnet 4.6 +0.073, Gemini 3.1 +0.050, GLM 5.1 +0.028, Flash 3.5 +0.010, Qwen 3.6 −0.031 — r = 0.99 across six points. All seven of the 48 capability × model cells that regressed belong to the three smaller models, concentrated in the capabilities that exercise orchestration hardest (MCP tool use, Playbooks, Presentations). The paper's phrasing: "the same richer harness that a strong model converts into quality, a weaker model experiences as load." And its one net-new capability, sub-agent delegation, clears a usable reliability threshold only on the two strongest models (0.85–0.86 against 0.42–0.45 on the fast tier) — an orchestration feature with a capability floor, below which exposing it produces failures rather than function.

Read naively that is this page inverted: harness richness paying off more as the model gets stronger, not less. The reconciliation is the distinction the wiki's own Resolved Question already drew, now with a measurement behind it:

• What shrinks is scaffolding that compensates for weakness — behavior requests, reminders, verification nudges, vision workarounds. Every measurement on this page is taken on exactly that: system-prompt lines an abler model no longer needs, and past expiry actively resists.
• What leverages is structural machinery the model cannot perform for itself — prefix-cache shape, compaction contracts, context offload to the filesystem, typed failure classification, zero-token durable suspension, per-task token accounting. No amount of model capability lets a model cache its own prompt prefix, suspend itself at zero cost mid-run, or refuse to bill for a discarded attempt. That is the inference/deployment structure survivor class, and this is the first source to show it doesn't merely survive — it pays more the better the model is.

Two details make the reconciliation more than a definitional escape. First, the losing arm in that experiment is exactly what this page calls harness bloat: a 49 KB monolithic system prompt replayed every turn, with regex-parsed XML tool calls and destructive middle-truncation. The winning harness is not smaller; it is more structured, and the token savings come from structure. Second, the capability floor points the same way as Instruction Compounding with the sign flipped — where a stale instruction becomes harmful to a strong model, a rich orchestration feature is harmful to a weak one. Both are arguments that harness surface has to be re-fitted to the model rather than monotonically added or monotonically deleted.

What does not dissolve: this page's implicit prediction is that the harness's contribution declines over time, and harness leverage says the quality half of that contribution is increasing in model strength within the band measured (baseline capability means 0.710–0.789 — a narrow eight-point span over six models, so treat the slope as local). If the trend holds at frontier capability, "the harness shrinks" is true only of prompts, and the structural half of the harness is a complement to capability rather than a substitute for it.

The counter-position on authority: a track record, not a release, earns autonomy#

The counter-currents above concede size and direction while leaving the page's instruction intact: at each release, reread the prompt and delete what the model no longer needs. Crystallizing Agent Work into Workflows (Malik, Azure Networking, case-study) contradicts that instruction directly, on the permissions half of the harness:

"Autonomy is attached to the specific playbook class and action type, based on its evidence, rather than to the capability of the underlying model. A more capable model does not automatically earn more autonomy; a track record does."

On that design what a workflow is allowed to do unsupervised is a property of its own demonstrated reliability — ≥10 clean runs with ≥90% identical action sequences to reach hybrid, ≥50 more plus ≥99% classification consistency and human review to reach deterministic — and a model upgrade transfers none of that evidence. Where this page says the launch pass deletes scaffolding, crystallization says the launch pass changes nothing about earned authority; a better model improves discovery, and the savings arrive later, when what it discovered crystallizes.

The candidate reconciliation is that the two are about different objects — this page has only ever measured instruction scaffolding (system-prompt lines), while Malik is describing authority scaffolding (evidence-gated permissions) — and that the pruning discipline was never meant to reach the latter. It is a candidate, not a resolution: nothing in the corpus settles which governs when a team upgrades a model, and both prescriptions arrive at that same moment. Filed as the open question on the other page.

The counter-position on affect: the same trend read as a reason to invest#

Every source above treats shrinkage as an instruction to delete. Garry Tan's Startup School 2026 keynote (Owning Your Externalized Cognition, practitioner-opinion) is the first in the corpus to take the identical premise — the model is rented and commoditizing, capability keeps migrating inward — and derive the opposite prescription: build more context, because it is the only input the release cadence does not commoditize. His answer to "the models will improve and make the harness obsolete":

"When everyone's engine is a thousand horsepower, the race is won on the driver and the map."

A smarter model, on this reading, extracts more from the same library, so each release is "a free upgrade to a workforce I already own."

This is less of a contradiction than it sounds, and the page's own Resolved Question is why. The survivor taxonomy already separates behavior requests (which migrate) from organization-specific record — a smarter model cannot infer a decision nobody wrote down. Tan's personal library is exactly that survivor class relocated to an individual, and his rebuttal quietly swaps the subject from harness (which may well shrink) to library (which the taxonomy predicts won't). Both can be true; his phrasing conflates them.

What is genuinely new is the affect, not the mechanism: the same slope that makes this page's prescription "prune at every launch" makes Tan's "write more down, and hold the repo." Where it is exposed is measurement — every number on this page is taken on scaffolding that compensates for weakness, and nothing in the corpus measures whether a context advantage widens or narrows across a model generation. The nearest counter-evidence is Agentic Work Systematization's telemetry (53% of reused skills never modified, maintenance 2.7:1 additive), which describes a library that is copied rather than compounded. Unmeasured on both sides, and the speaker runs an accelerator whose interest points the same direction as the doctrine. Question filed on the other page.

Connections#

• Owning Your Externalized Cognition — the counter-position on affect: the same commoditizing-model premise read as a reason to accumulate context rather than prune scaffolding. Reconciled by this page's own survivor taxonomy — personal context is the organization-specific-record class at individual scale — but the library half of the trend has never been measured
• Crystallizing Agent Work into Workflows — the counter-position on authority: shrinkage says each release retires scaffolding, crystallization says a workflow's permissions are earned by its own track record and survive the upgrade unchanged. Unreconciled; the candidate split is instruction scaffolding versus authority scaffolding
• Orchestration Sets Token Economics — the counter-current above: efficiency gains from a richer harness are model-invariant while quality gains scale with model strength (r = 0.99), and advanced orchestration features carry a capability floor. The reconciliation is prompt-scaffolding-versus-structural-machinery, which is this page's own survivor taxonomy given its first measurement
• Boris Cherny — "100 lines" claim and the spontaneous-loop observation
• Shared Harness, Differentiated Surfaces — the corpus's only non-Anthropic corroboration: OpenAI's Codex/ChatGPT Work merge differentiates surfaces on exactly the safety/permissions/UI residue Cherny names, and moves surface routing into the model
• Harness Build-vs-Buy — the counter-datum and its reconciliation: four harness codebases at 1.05M–1.75M lines and 5,679–7,736 merged PRs/year, because this page has measured prompts and never repositories — and because pruning at every model launch is itself churn
• Claude Fable 5 — the cleanest demonstration: vision-only Pokémon harness and 3×-better memory utilization vs Opus 4.8
• Cat Wu — the operational discipline of pruning prompts at every launch
• Instruction Compounding — the sharp edge: scaffolding that becomes harmful rather than merely useless, which is what obligates the pruning pass rather than merely rewarding it
• Output Length Calibration — the counter-current: the same Opus 5 guide adds prompt for output length, so the launch pass has to add communication scaffolding as it cuts capability scaffolding
• Matt Pocock — counterpoint that mechanical verification stays load-bearing
• Agent Loop Pattern — example of a primitive migrating from harness to model
• Context Window Smart Zone — why prompt bloat is a cost, not just bloat
• Claude Character as Product — character is the rare harness asset that probably doesn't shrink
• Agent Harness Engineering — generalizes the "enforce invariants, not implementations" principle to harness-vs-model division of labor
• Claude Code Auto Mode — a harness feature whose necessity Cat Wu predicts will fade
• AI Brain Fry — partially mitigated by harness shrinkage (less to oversee), reintroduced by output volume from loops
• Human-AI Accountability Redesign — what doesn't shrink is the human at the boundary; this paper names what that boundary work becomes (oversight quality, decision rights, escalation, consequences)
• Model Spec Midtraining (MSM) — alignment moves from harness-prompt-injection of values to model-internalized values; the alignment side of harness shrinkage
• Interaction Models — the same move on the interaction axis: VAD / turn-detection / dialog-management harnesses dissolve into the model (Thinking Machines Lab, May 2026)
• The Bitter Lesson — the underlying principle: hand-crafted scaffolding gets outpaced by scaled general capability
• Build for the Next Model — the product-strategy corollary spun out as its own page: prototype "the thing that almost works" and let the next release close the gap (Dan Carey / Claude Design / Opus 4.7)
• HTML as the New Markdown — the crucial distinction: this page describes the model-facing harness shrinking, while Thariq Shihipar's HTML artifacts (plans, micro-apps) are human-facing harness that grows as models improve (the binding constraint moves from "can the model do it" to "can the human stay in the loop")
• Compute Allocator — names the human role that expands as the model-facing harness shrinks; ~99% of tokens go to human-facing scaffolding
• Founder as Agent Orchestrator — orchestration affordances themselves will shift as harness shrinks; founders building permanent workflows around 2026 Claude-surface affordances should expect rewrites
• Agentic Technical Debt — CLAUDE.md as architectural context is one form of harness; may eventually be inferred by the model, but currently load-bearing
• Compounding Data Moat — vertical-edge-case test suites are a form of harness that doesn't migrate inward (no generic training signal for niche industry edge cases)
• AI-Native Startup Lifecycle — founders building permanent workflows around 2026 Claude-surface affordances should expect them to shift as harness shrinks
• Zero-Friction Scope Creep — written-scope discipline is human-process work that does not migrate inward as harness shrinks
• MCP and Computer Use — complementary to harness shrinkage: connectors don't shrink, they broaden as the model decides which substrate (MCP / API / computer use) to use for each task
• Evals as Product Spec — what doesn't shrink on the PM side: evals are durable artifacts that re-validate the product as the harness around them dissolves
• Agentic Loops Overtake Bespoke Systems — the same dynamic in formal mathematics: DeepMind's bespoke proof-search scaffolding (AlphaProof + evolution) converted from capability-enabling to merely cost-saving as the LLM improved
• Verification as the New Bottleneck — Fiona Fung's org-level corollary: as the generation harness shrinks, verification becomes the binding constraint
• Recursive Self-Improvement — harness shrinkage run to its endpoint: the harness dissolving into the model is the same trend that, applied to AI development itself, closes the self-improvement loop
• AI Accelerating AI Development — the measured deployment-side story: as capability migrates inward, internal engineering throughput rises (~8× code/engineer; >80% Claude-authored)
• Research Taste as the Human Bottleneck — the human-side mirror: what's left after the model-facing harness shrinks is taste, review, and direction-setting
• Vibe Coding vs. Agentic Engineering — Karpathy's ">10x and widening" leverage curve is the practitioner-facing form of shrinking harness / growing capability
• Loop Engineering — the deployment-side evidence: Osmani's "a year ago a loop was a private pile of bash you maintained forever; now the pieces ship inside the products" is harness-shrinkage seen from the loop layer — capability absorbed into the tools as named primitives (automations, worktrees, skills, connectors, sub-agents)
• Agentic Work Systematization — the same absorption measured: skills/plugins are harness capability shipped as named, shareable product primitives, with the OpenAI study's adoption curve (5.4%→26.6% of weekly-active Codex users)
• Conversation-to-Delegation Shift — rising delegation (Codex token share by population) is what a shrinking harness enables on the usage side: less hand-holding per task, more work handed off
• Agent-Authored Harness Optimization — the same human-role narrowing arriving at the harness-authoring layer (write the brief, review the PR), with a twist that cuts against the shrinkage thesis: the agent added scaffold — retry logic, output-aware loop detection, PID tracking — because the harness was too thin, not too thick

Open Questions#

• The Boris "100 lines" prediction is a year out from May 2026 — testable in 2027. Partially answered: Harness Build-vs-Buy supplies the first measurement of harness codebase size and its trend — four comparable harnesses at 1.05M–1.75M lines with merged-PR rates still climbing (Codex ~124 → ~1,000/month over twelve months). That is evidence about the reference class, not about Claude Code, which is closed-source and unmeasured; the 2027 test stands.
• If harness work shrinks, what new work expands to fill it? Cat Wu's bet: PM/product taste, eval-writing, character work.

Resolved Questions#

• Does all prompt scaffolding eventually migrate into the model, or does some remain — e.g. organization-specific style, security rules, brand voice? Answered: What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — no: only behavior requests migrate (and past expiry turn harmful per Instruction Compounding). Five classes survive, sorted by the bitter-lesson exemption rule (structure encoding a task prior migrates; structure encoding boundaries, records, identity, or serving arithmetic doesn't): boundary enforcement (security rules survive as constraints, the instruction class that keeps working), organization-specific record (a smarter model can't infer an unrecorded decision — org style qua arbitrary convention lives here), deliberate identity (brand voice/character is held stable across capability jumps by design), inference/deployment structure, and human-facing legibility (which grows). Communication calibration flows the opposite way — added, not removed, as defaults lengthen. "Harness shrinkage" is really request shrinkage; the prompt converges to a residue of constraints, records, identity, and calibration.

Derived#

• What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — the survivor taxonomy answering this page's migration question, plus the compounding-detection signature and the stall analysis for Build for the Next Model
• Learning to Co-Work with AI: A Software Engineer's Field Guide — pruning-at-every-launch framed as a daily practice; "build for next model" as career-strategic horizon
• Opinions on Using AI Tools & the Future of the Software Engineering Role — the harness-shrinks vs harness-is-the-ceiling tension is one axis of the four-stance debate map
• Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling? — the model-facing/human-facing asymmetry taken to its conclusion: the human-facing harness can't shrink to zero and faces more bloat pressure as models improve
• Where Does Agent Harness Work Remain Durable as Models Improve? — separates shrinking capability scaffolding from durable boundary work: verification, repo-local truth, context budgeting, isolation, tools, and human decision surfaces
• Authority and Audit Survive Abundance — the instruction-vs-authority candidate split (this page's crystallization tension) confirmed and generalized: the survivor taxonomy's boundary/record classes plus the security corpus's circularity doctrine are why a model upgrade prunes instructions but never earns authority — and why the same rule keeps the retrieval layer alive under free context

Sources#

• Beyond RAG: Building Agentic Document Workflows with LlamaIndex — Pierre-Loic Doulcet, AI Engineer Singapore 2026 (practitioner-opinion, LlamaIndex vendor COI): the retrieval-side statement of this thesis (HyDE/multi-query subsumed by agent loops; Search-R1 absorbing the loop into the weights; Adaptive-RAG routing around it) and the scope condition — parsing is the layer that did not shrink. Full treatment on Document Parsing as the Retrieval Bottleneck
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Full Walkthrough: Workflow for AI Coding — Matt Pocock (counterpoint)
• Claude Fable 5 and Claude Mythos 5 — vision-only Pokémon FireRed harness; memory-utilization gains
• Prompting Claude Opus 5 — Anthropic platform docs (retrieved 2026-07-25, vendor-claim): the pruning rule stated as vendor instruction, including harness scaffolding that now degrades output rather than merely wasting tokens
• The new rules of context engineering for Claude 5 models — Thariq Shihipar, 2026-07-25 (practitioner-opinion): the >80% system-prompt deletion with no eval loss, the "unhobbling" framing, conflicting-instruction transcripts, and claude doctor as productized pruning
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space, 2026-07-28 (practitioner-opinion): the non-Anthropic check — one shared harness across Codex and ChatGPT Work differentiated only by permissions and UI; model-decided surface routing; and the counter-current of a growing user-facing knob surface ("there's 32 options")
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny, YC interview (2026-07-27, practitioner-opinion): the ablation methodology, SIMPLE=1, "a little bit more intelligent without these prompts," the safety/permissions/static-analysis/UI residue, and the delete-your-CLAUDE.md-every-6-months advice
• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI — Sayed Ali et al. (33 authors, all Writer, Inc.; arXiv 2607.06906, 2026-07-08, empirical, total vendor COI): §6.4 harness leverage (per-model Δq̄, r = 0.99), §6.3 the seven regressions all on smaller models, §6.5 the sub-agent capability floor, §4.2 the frozen baseline's 49 KB replayed system prompt. Figure 6 viewed — the fit is clean but spans only 0.710–0.789 in baseline capability. Table 2 is cell-collapsed and Table 7 row-shifted in the raw parse; neither is cited
• Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models — Netanel Eliav, arXiv 2607.19257, 2026-07-21 (empirical, sole author, single lab, not peer reviewed): §4.2 and Table 4 the instruction-count floor, §8 the 40-instructions-is-a-redesign-point guidance — the first non-Anthropic, non-vendor evidence on this page that prompt size has a hard ceiling, and the only one denominated in instruction count rather than tokens. Table 1's model roster is cell-collapsed in the raw markdown and is not cited; see the Sources note on Instruction Compounding
• Coding Agents and Technical Debt — Rajiv Shah, OpenHands, 2026-07-28 (case-study, vendor-interested): the counter-datum — four harness codebases at 1.05M–1.75M lines, 5,679–7,736 merged PRs/year, and a rising PR rate
• Garry Tan: Own Your Intelligence — Garry Tan, "Own Your Intelligence," YC Startup School 2026 (2026-08-06, practitioner-opinion, no measurement, accelerator-president COI): the objection section — "the models will improve and make the harness obsolete" answered with the driver-and-map argument and "a free upgrade to a workforce I already own." The corpus's only source that reads this page's premise as a reason to accumulate context rather than prune scaffolding
• Fable's judgement — Simon Willison, "Fable's judgement," 2026-07-03 (practitioner-opinion, 460 words): Cat Wu and Thariq Shihipar's AI Engineer World's Fair advice to let the model use its own judgement rather than dictating how it works, the automated-testing example, and Willison's own self-delegated model-routing prompt. Second-hand for the team's advice (Willison hosted the fireside; no transcript in the corpus), first-hand for the prompt, and unmeasured for the outcome