The 100x Engineer Is a Harness

The 10x engineer was always half myth — a rare person who fit a problem so well they outran a team. The 100x engineer is something else, and more reachable: an experienced engineer with agents doing the volume. A better model helps at the margin, but it is not what produces the multiplier. The harness does, along with the judgment that goes into building it. The expertise did not disappear when the model started writing the code — it moved. What used to be an engineer writing the right thing is now an engineer telling the agent how: use this library, not that one; structure it this way; here is the constraint that is not up for renegotiation.

I have spent the last while building agent-heavy systems, with agents doing a real share of the writing. The setup that produces the multiplier is not a framework and it is not clever. It is a small set of living documents the agent works from, a feedback loop that keeps the result honest, and the discipline that ties them together: every plan and every change flows back into the documents, and every model release is a chance to tear part of them out.

There are plenty of good harness guides by now, and this is not another one. It is an account of what is working for me — built around the idea most of those guides state once and move past: every piece of scaffolding you build is a bet about something the model cannot do well on its own yet, and the model keeps getting better at doing things on its own. A harness is never a setup you finish; it is a position you hold against a moving target, and holding it well means building and dismantling in roughly equal measure. What follows is what I build. The part that separates leverage from cruft is what I tear out.

The context contract

I do not start a complex project by writing code. I start by writing the documents the agent will live inside, and I keep them small enough to stay true.

The set is consistent across projects. AGENTS.md is the contract: how to work in this repo, the commands that are not guessable, the conventions to match, the architectural decisions that look like mistakes and are not. It is the closest thing the field has to a portable standard for this — Claude Code, Codex, Cursor and the rest read it natively, and CLAUDE.md is the same idea by another name. DESIGN.md holds the shape of the system: where state lives and why, the boundaries that are not allowed to drift. Then a /docs folder carries the product itself — spec.md first, a deliberately minimal product spec I iterate on before and during the build, then whatever the project needs around it: who it is for, the features broken down, the roadmap. The exact list is project-dependent and beside the point. The point is that what the agent is building is written down, at a level it can reason over, living next to the code instead of in my head.

AGENTS.md does not repeat what the other files say — it routes to them. It is the first thing the agent reads, and a good part of its job is simply to point: the architecture is in DESIGN.md, the product scope is in docs/spec.md, the current priorities are in roadmap.md. Each document stays the single source of its own truth; that separation is what keeps the set maintainable as the project moves, because the same fact never lives in two places drifting apart. On a larger codebase the file nests — a subtree with its own conventions gets its own AGENTS.md next to the code it governs, and the agent reads the nearest one when it works there.

This is the move that makes agents work on complex apps instead of just on snippets. Hand an agent a task and a bare codebase and it infers intent from the code — and on anything non-trivial the code under-determines the intent. A spec it can read closes that gap. I point the agent at spec.md and DESIGN.md before it touches a feature, and the work comes back aligned with what I asked for instead of a plausible guess at it. When the result is wrong, the spec was usually wrong first.

Each of these files is a contract, not a readme. A readme explains the project to a human who reads it once and builds their own mental model. These files are the mental model, handed to an agent that starts every session with amnesia. So the test for every line is not "is this true?" but "will the agent do the wrong thing without it?" If the answer is no, the line is noise — and noise is not free, it dilutes the lines that carry weight.

What earns its place in AGENTS.md, concretely:

• The commands that are not guessable. pnpm, not npm. The build step that has a non-obvious flag. The test command that only works from a subdirectory. The agent will guess npm install and be wrong, and the guess costs a round trip and a polluted context window.
• The architectural decisions that look like mistakes. Why state lives where it lives. Why this thing that looks duplicated is duplicated on purpose. An agent that does not know the reason will "fix" it.
• The conventions it should match without being told each time. Match the surrounding file's naming and idiom. Server components by default. Where the path alias points.

Here is the top of a real one, from a production app I work in. Notice how little of it is rules, and how much is just routing — pointing the agent at the document that owns each answer:

# Agent Guidelines

Repo entry point for coding agents. Keep context small: load the
narrowest file that applies, make the smallest useful change, and
verify against the goal.

## Working Rules
- Build only what was asked for; avoid speculative abstractions.
- Touch only required files; do not refactor unrelated code.
- Verify with the narrowest useful check. Run `pnpm lint` before commits.

## Commands
- Dev: `pnpm dev` · Build: `pnpm build` · Lint: `pnpm lint`

## Context Routing
- Canonical product scope → docs/product-spec.md
- Current priorities → docs/roadmap.md
- UI design rules → DESIGN.md
- Agent runtime rules (nested) → lib/agents/AGENTS.md

Half the file is a table of contents. That is the file working as designed: it is small, it sets the few rules that are not negotiable, and then it gets out of the way and tells the agent where to look.

The test I actually apply to a candidate line is one branch:

for each line in AGENTS.md:
    if agent does the wrong thing without it      ->  keep
    elif agent can fetch it in ~2 tool calls      ->  cut (it's free elsewhere)
    else                                          ->  cut (it's noise, and noise dilutes)

The things that fail it are the obvious ones — directory structure, the dependency list, the framework's defaults. The agent can fetch all of that for free; putting it in the contract just crowds out what it cannot.

Brevity is the discipline that keeps all of it working. A 400-line AGENTS.md is worse than a 60-line one: the agent weighs every line against every other line, and the constraints that matter drown in the ones that do not. I treat these files like config, not prose — every line has to displace its own weight in usefulness, or it comes out. The same goes for the spec: it earns its keep by being current and tight, not by being exhaustive.

Of everything in the harness, this is the part that ages best. Models change; what your product is and how this codebase is meant to work do not. Effort spent getting these documents right is not at risk the way the rest of the scaffolding is.

Context is a budget, not a backstop

The context window is a budget I spend, not a safety net that catches everything.

On a small change this does not matter. On a complex app it is the whole game. The moment the agent has read six files, run four searches and printed three stack traces, the signal I actually care about is buried under transcript. Performance degrades not because the model got worse but because the relevant facts are now a small fraction of what it is holding.

So the discipline is keeping the main thread clean and pushing the messy, high-volume work somewhere else. The pattern that does the most work for me: fan out the searching. When the question is "where in this codebase does X happen" and I expect to read twenty files to answer it, I do not want those twenty files in my main context — I want the conclusion. A subagent reads the excerpts in its own isolated window, throws away the dead ends, and hands back the three locations that matter as a short summary. The main thread stays focused on the work instead of the search for the work. This is the same move Anthropic's own multi-agent setups make — subagents with separate context windows returning condensed summaries — and in their internal research evals that architecture beat the single-agent version of the same model by a wide margin. Isolation is not overhead. It is what keeps each context dense with signal.

There is a related instinct worth naming: when a long session starts to wander, the right move is often not to compact it but to reset it. Compaction tries to summarise a polluted window in place and keeps some of the rot. A fresh agent, handed a clean statement of where things stand, starts dense again. The skill is in the handoff — write down the state worth keeping, then start over — rather than nursing a context window past its useful life.

None of this is about doing less. It is about deciding what belongs in the expensive, focused context and what should happen out of sight and come back as a summary.

Be honest that most of this is rented. The fan-out, the reset, the careful budgeting — they exist because the model's working memory is finite today. As context windows grow and models hold a long thread without losing the plot, some of this scaffolding becomes dead weight, and I fully expect to delete it. So I build it to work, not to last, and I do not fall in love with how elegant it is.

Skills: expertise the agent loads on demand

The context budget has a second lever besides subagents, and it is the one that scales best: skills. A skill is a self-contained package of expertise — how to integrate Stripe correctly, how to review a UI surface, the conventions of a particular framework — that lives outside the always-loaded context and gets pulled in only when the task calls for it.

This is the discipline of the context contract applied to knowledge instead of rules. I do not want two hundred lines of Stripe guidance sitting in AGENTS.md, weighed against every other line on every task that has nothing to do with payments. I want it absent until the agent touches billing, and complete the moment it does. A skill is how you get both.

The mechanism is progressive disclosure. Each skill is a SKILL.md with a short frontmatter description that states when it applies:

---
name: stripe-best-practices
description: Use when building, modifying, or reviewing any Stripe
  integration — payments, subscriptions, Connect, webhooks, key handling.
---

Latest API version: 2026-03-25. Always use the latest SDK unless told otherwise.

## Integration routing
| Building…          | Recommended API   | Details                |
| One-time payments  | Checkout Sessions | references/payments.md |
| Subscriptions      | Billing + Checkout| references/billing.md  |
...read the relevant reference before writing code.

The agent reads only the descriptions — they are cheap — decides which skill matches the task in front of it, and loads the body, and the body's own reference files, only then. The expensive detail stays out of context until it earns its way in, which is the same rule the rest of the harness runs on.

And because skills are just files with a defined shape, they are dependencies, so I treat them like dependencies. They are pinned in a lockfile, pulled from shared sources — Stripe's own skill, Vercel's, shadcn's — and content-hashed so one cannot drift underneath me. Expertise that used to live in a senior engineer's head, or in a wiki nobody opened, becomes a versioned artifact the agent loads at the moment it is relevant. And the harness can wire a skill into the workflow directly: AGENTS.md can tell the agent to run a ux-review skill before it touches an important product surface, so the standard gets applied without me remembering to ask for it.

Skills fall on both sides of the line. The mechanism is the temporary half — a model that already knows this year's Stripe API needs less of it spelled out. The curation is the durable half: which sources I trust, which practices are house style, is judgment that does not expire when the model improves.

The documents are the memory

The agent forgets everything between sessions, and that is fine, because I do not ask it to remember — I keep the knowledge in the documents. There is no separate memory store in my setup. The documents are the memory; the only trick is keeping them current.

So when a decision gets settled, it does not stay in my head or buried in a chat log — it gets written back into the document that owns it. An architecture call goes into DESIGN.md. A product decision goes into the spec. A "we always do it this way here" goes into AGENTS.md, or a short DECISIONS.md when it is the kind of thing that needs its reasoning attached. Next session the agent re-reads those files and starts from the settled state instead of relitigating it. That is the whole mechanism behind an agent that stops fighting you on things you already decided: not memory, just documents that did not lose the decision.

The catch is that documents only help if they stay ahead of the code, not behind it — and this is the part most people get backwards. A change does not start in the code; it starts in the document. When I plan a feature, or reverse a decision I made last month, the spec or DESIGN.md gets edited first, and the build follows from the new text. And a change is not done when the code works — it is done when the document that describes it is true again, in the same commit, not as a cleanup task for later. The moment a document lags reality — a spec for a feature you already ripped out, an AGENTS.md pointing at a file that moved — the agent is reading fiction, and every session after it builds on the wrong picture. A stale document is worse than no document, because the agent trusts it completely.

And this is the durable half of the harness. A model upgrade does not make a settled decision less true; the reason the receipt trail has to stay replayable does not expire because the context window got bigger. The documents are you, written down — which is exactly why keeping them honest is worth the discipline it costs.

The feedback loop closes the gap

The last piece is the one that separates an agent that looks productive from one that is: it has to be able to check its own work without me being the checker.

An agent writing into a void — no way to run the thing, no test it can read, no lint that bites — is guessing, and guesses on a complex app are expensive because the failure surfaces three steps later. The fix is to wire the loop so the agent gets the signal directly. The build runs. The test runs and the agent reads the failure. The lint fires. Where it is safe, the agent runs the actual app and looks at the actual behaviour instead of asserting that the change "should" work.

The feedback has to come from outside the agent doing the work. An agent grading its own output is a weak check — it tends toward declaring victory, because the same context that produced the code is now judging it. Anthropic's harness experiments put a number-shaped intuition on this: they get noticeably better results from a generator-evaluator split, where one agent builds and a separate one tests against explicit criteria, than from a single agent asked to self-assess. External judgement catches the class of failure self-review is structurally blind to. In practice this is why I lean on a real test the agent did not write, a separate review pass, an actual run of the app — anything that is not the author marking its own homework.

This is also where I get to run looser. Hooks and a sensible permission allowlist mean the routine, safe operations do not stop to ask me, while the things that are hard to reverse still do. The combination — automated guardrails plus a real feedback signal — is what lets the agent do a meaningful stretch of work autonomously without me hovering, because the harness catches the class of mistakes I would otherwise have caught by hand. The agent that can see its own red test is dramatically more useful than the one that hands me code and a confident sentence.

The workflow is a pipeline, not a prompt

A feature does not go from one prompt to a finished PR in a single leap, and trying to make it is how you get plausible code that solves the wrong problem. The work moves through stages, and the point of the workflow is that each stage is a cheap place to correct before the expensive one.

The pipeline I run is consistent: the spec says what; a plan says how, and I approve it before any code exists; generation does the work, fanned out to subagents where the context would otherwise bloat; an external evaluator runs it and grades it against the spec; and whatever I learn gets distilled back into the documents so the next pass starts further ahead.

The two arrows that earn their keep are the cheap ones. Approving the plan before code is written catches a wrong assumption in five lines instead of five hundred. And distilling what I learned back into the documents is what closes the loop on the harness itself.

That last arrow is the one people skip, and it is the one that compounds. The prompts and instructions are not write-once. When the agent does the wrong thing, that is not noise to wave away — it is the most useful signal in the whole system, because it points at exactly the instruction that was missing or ambiguous. I read the run, find where it went off, and the failure becomes the edit: a tightened line in AGENTS.md, a decision recorded in DESIGN.md, a new check in the loop.

This gives a concrete test for whether a prompt is any good, which is otherwise a matter of taste. An instruction is working when the failure it was written to prevent stops recurring — not when it reads well, but when the agent's behaviour actually changes. I evaluate a change to AGENTS.md the way I evaluate a change to code: run it, watch what the agent does, keep it if the behaviour improved and cut it if it did nothing. That is the whole difference between a harness that gets better and one that just gets bigger. Every recurring mistake either sharpens an instruction, lands in a document, or becomes a check — and nothing holds a permanent place on vibes.

Every harness is a bet against the model

If there is a single point here, it is that the leverage moved off the model and onto the harness. A better model helps, but the gap between an engineer who ships with agents and one who fights them is a harness gap, not a model gap.

The trap is to read that as "build a good rig and sit on it." The harness is not a setup you finish — and that is the easy thing to forget once you have one that works. Every piece of it encodes an assumption about something the model cannot do well on its own. The verbose context file assumes it will not infer the convention. The reset ritual assumes it cannot hold a long thread. The external evaluator assumes it cannot judge its own work. Each was true when I built it — and each quietly stops being true as the models improve. A release lands, and half a page of careful instructions is suddenly doing nothing, because the model now does that part unprompted.

So the assumptions sort into two piles, and the entire skill is telling them apart.

Some are temporary: scaffolding for whatever the model is currently weak at — holding a long context, planning before it codes, checking its own work. These are rented. Every model release threatens to turn them into dead weight, and a harness no one prunes becomes a cage built for a weaker model than the one you are running. I have learned to read each upgrade as an invitation to delete, not only to gain: pull out the load-bearing pieces and see what the model no longer needs held up.

Some are durable: the things the model will never know however good it gets, because they were never in the weights and never will be. What this product is for. Why the receipt trail has to stay replayable. Which of two perfectly reasonable libraries you standardised on, and why. Your taste. That is not scaffolding for a weak model — it is the part of the harness that is really just you, written down. It compounds, and it is safe to invest in without limit.

That distinction is the discipline, and it is the one a checklist cannot hand you, because a checklist treats every part of the harness as permanent. Build the rented half as cheaply as you can — you are going to throw most of it away — and pour yourself into the half that lasts.

Which is what the 100x number actually means, once it stops being a slogan. A better model does not erase your advantage; it erases your scaffolding, and hands back the attention you were spending on it. The multiplier is not a rig you build once and sit on. It is a position you re-earn on every release: prune what the model made obsolete, push your judgment one level higher, and let the part of the harness that is really you compound while the rest gets cheaper. That is how you ship like a 100x engineer — not by building a clever rig, but by being the one who keeps deciding, release after release, what still needs building at all.