How to 8x Your Code Output Using Context Engineering

Anthropic’s engineers merge 8 times more code per day than in 2024. The context engineering playbook everyone is copying explains almost none of it.

Anthropic’s Engineers 8x Their Output

In June 2026 Anthropic published a report on its own engineering organisation called “When AI Builds Itself”, and the headline finding travelled a great deal further than the document did.

By the second quarter of the year, the typical Anthropic engineer was merging 8 times as much code per day as in 2024.

AI coding agents helped push Anthropic’s code output per engineer to 8× its pre-2025 average. (Image source: Anthropic)

But the explanation was mostly misread.

The foundational model did not change. The team did not change. The face behind the company didn’t change. It all came down to “context engineering”.

That version sends people off to build enormous scaffolding that makes their agents slower and less reliable. Almost everything that genuinely works here is smaller and duller than the posts suggest, and most of it sits in documentation nobody reads.

So what follows is the version I would hand a friend who asked me to set this up on their repo over a weekend.

What context engineering means, which files load at which moment, and which parts of it are worth your Saturday.

---

together with TrueForge:

Everything below is context engineering for your sessions.

TrueForge is the same discipline built into an agent harness: open source, vendor-neutral, benchmarked against Claude Managed Agents on the same model and tools

▫️ Same score (11/14), 62% fewer tokens, 30% lower cost per run

▫️ Compaction instead of replaying, the discipline this article teaches

▫️ Any model, any MCP server: $0.25 vs $1.10 per correct answer on the open-model config:

---

Table of Contents

1. Context Engineering Is Budgeting, Not Collecting

2. The Four Layers and When Each One Loads

3. Writing an Instructions File Claude Will Follow

4. The Memory Layer, and What Survives a Compaction

5. Fetching Context Instead of Front-Loading It

6. Turning All of This Into Actual Output

---

1. Context Engineering Is Budgeting, Not Collecting

The name makes it sound like the job is gathering everything relevant and handing it over. The job is closer to the opposite.

A definition worth actually using

Anthropic’s Applied AI team published a piece on this in September 2025, and the premise is the part worth keeping.

A model works inside a finite attention budget, and every token you put in front of it spends from that budget whether it earned its place or not.

Good context engineering, by their definition, means finding the smallest set of high-signal tokens that make your desired outcome likely.

In other words, editing rather than collecting.

Prompt engineering was about how you worded one message. This is about what the model can see across an entire task, and most of the craft turns out to be about what you leave out.

(Image source: Anthropic)

Why loading more makes agents worse

You can watch this happen in a long session. Quality drops well before you hit any hard limit, and once compaction fires near the ceiling your history gets rewritten into a summary that keeps whatever the summariser thought mattered.

The costs add up fast. Every MCP server you connect spends tokens on tool definitions before you have typed a character, and a 400-line instructions file does not get followed twice as reliably as a 200-line one. Anthropic’s documentation says the reverse happens.

So before you add anything, work out whether it needs to sit there for the whole session. Useful is not the bar.

From human-built AI to AI that could eventually build itself. (Image source: Anthropic)

---

2. The Four Layers and When Each One Loads

Most people organise context by topic. Sorting it by load time tells you far more, because when something arrives decides whether it will still be there an hour later.

ENFORCED      settings and hooks            always, and not context at all
RESIDENT      CLAUDE.md, rules, MEMORY.md   from disk, every session start
CONDITIONAL   path-scoped rules             when a matching file is opened
FETCHED       skills, sub-agents, MCP       only when something asks for it

The two layers that are always there

The enforced layer barely counts as context, which is exactly why it goes first. A deny list in your settings file blocks tools, commands or paths and the client honours it whatever the model concludes, while hooks run as shell scripts at fixed lifecycle points and can stop an action outright.

This is where a never-touch list belongs. Writing never read .env into a markdown file buys you a strong hint and nothing more, because the documentation is explicit that instructions are context and not enforced configuration.

The resident layer is your CLAUDE.md files, any rules without path scoping, and the top of Claude’s own memory index. All of it comes off disk at the start of every session, and all of it costs you window space for the entire run.

WHERE CLAUDE.MD FILES LIVE

  managed policy   /Library/Application Support/ClaudeCode/CLAUDE.md
  user             ~/.claude/CLAUDE.md
  project          ./CLAUDE.md   or   ./.claude/CLAUDE.md
  local            ./CLAUDE.local.md        (gitignore this one)

Files above your working directory load in full at launch, concatenated from the filesystem root downward, so whatever sits closest to where you started gets read last. In a monorepo where other teams’ files keep getting swept in, claudeMdExcludes drops them by glob.

The two layers that come and go

A rule carrying paths frontmatter costs you nothing until Claude opens a file that matches the pattern.

Nested CLAUDE.md files in subdirectories behave the same way, which makes both of them a good home for API conventions you do not want resident while working on the frontend.

The fetched layer is everything Claude goes out and retrieves. Claude skills load when you invoke one or when Claude judges it relevant, sub-agents hand back results from a separate window, and MCP calls pull in the ticket or the incident or the schema.

Working out which layer something belongs to answers most of the questions people ask about this, including the one where an instruction seems to disappear halfway through a task.

How nested claude.md files provide better context. (Image source: Raul Junco)

---

3. Writing an Instructions File Claude Will Follow

Everyone starts here, and almost everyone writes too much.

Name it CLAUDE.md, then check it loaded

Claude Code reads CLAUDE.md. It does not read AGENTS.md, and no fallback exists, so a repository holding only an AGENTS.md hands Claude nothing at all.

A lot of guides get this backwards, and it matters because AGENTS.md is a real convention that most other coding agents do look for. Running a mixed toolchain, put a single @AGENTS.md import at the top of your CLAUDE.md, or symlink one to the other and move on.

Then confirm it worked. Run /context and look for the file under memory files, because skipping that check is how people spend a fortnight convinced their instructions are being ignored.

Start with /init, which reads your codebase and drafts something for you. Then cut it hard, since what it produces is a description of your repo and what you need is a set of corrections to it.

Stay under 200 lines, and know what to cut

The documentation targets under 200 lines per file and says plainly that longer ones eat more context and get followed less often. Treat the file as a budget line with a hard ceiling rather than a wiki page.

The /doctor checkup proposes trims along a principle worth stealing outright. It strips anything Claude can work out by reading the repo and keeps the pitfalls, the reasoning, and any convention that contradicts what your tools do by default.

WORTH THE SPACE

• build, test and lint commands

• conventions that contradict the framework default

• where things live when the folder tree does not say

• the failure that already cost somebody an afternoon

• what to do when a requirement is ambiguous

NOT WORTH THE SPACE

• directory listings

• dependency lists

• architecture overviews

• anything Claude can read off the repo in 10 seconds

Write rules you could check against. Use 2-space indentation works, while format code properly does nothing at all. Anywhere two rules contradict each other across the tree, Claude may pick one arbitrarily, so a periodic read-through pays for itself.

Add to the file on a trigger rather than on a schedule. Claude repeats a mistake, a review catches something it should have known, or you notice yourself retyping a correction you already typed last week.

---

4. The Memory Layer, and What Survives a Compaction

Most playbooks tell you to hand-build a memory file that the agent reads at the start of a session and updates at the end. That feature already ships, switched on.

Claude keeps its own notes now

Auto memory is enabled by default and Claude decides what to keep based on whether it would help a future conversation.

So you should build commands it worked out the hard way, a debugging pattern that keeps recurring, a preference you corrected twice, the reason a particular test stays skipped.

~/.claude/projects/<project>/memory/
  MEMORY.md            index, first 200 lines load every session
  debugging.md         read on demand
  api-conventions.md   read on demand

Only the index loads at startup, capped at the first 200 lines or 25KB, whichever arrives first. Everything past that gets dropped without warning, which is why Claude keeps pushing detail out into topic files and reading them when needed.

Open it now and then with /memory. It is plain markdown you can edit or delete, and a stale note does more damage than a missing one because Claude will act on it with total confidence.

Two limits are worth knowing. Auto memory lives on one machine and is shared across worktrees of the same repository, and sub-agents do not inherit what the main conversation learned.

Placement decides what comes back

Compaction fires as you approach the ceiling, summarises your conversation, and hands the model a compressed version of its own history. What makes it through follows one rule that is simple and not at all obvious.

SURVIVES     project-root CLAUDE.md, unscoped rules, MEMORY.md index
SUMMARISED   path-scoped rules, nested CLAUDE.md, everything you typed

Anything read off disk at startup gets re-injected afterwards. Anything that arrived through the conversation gets folded into a summary and stays folded.

A path-scoped rule therefore vanishes at compaction and will not return until Claude opens a matching file again. Where an instruction has to hold for a whole task, put it unscoped in the project root and stop repeating yourself in chat.

Two commands do most of the day-to-day work. Use /clear between unrelated tasks, which hardly anyone does often enough, and /compact followed by an instruction when you want to choose what gets preserved.

How Claude remembers your project.

---

5. Fetching Context Instead of Front-Loading It

Once you stop trying to preload everything, the interesting question becomes how Claude gets what it needs at the moment it needs it.

Skills carry procedures, sub-agents carry volume

Rules load every session or whenever a matching file opens, while skills load only when you invoke one or when Claude decides one applies.

A fact Claude should always hold belongs in a rule, and a procedure it should sometimes follow belongs in a skill.

Sub-agents are the strongest move available here and the one hardly anybody uses. A sub-agent explores inside its own clean window and returns a condensed summary, often 1,000 to 2,000 tokens, so your main session never sees the 80,000 tokens of search output behind the answer.

Worth saying plainly though. A simple loop often beats an elaborate multi-agent arrangement, so reach for this when the reading volume justifies it and not because the architecture diagram looks impressive.

How to Build Three AI Agents Without Writing Code

External systems, and what they quietly cost

MCP is how Claude reaches the ticket explaining why a feature matters, the incident showing how users are hitting a bug, and the schema the fix has to respect. That context is real, and it is frequently the piece that was missing.

The cost stays hidden until you look for it. Every connected server spends startup budget on tool definitions before you type anything, so a dozen connectors you rarely touch is a tax you pay on every single session.

Where the two overlap, there is a decent argument for skills over servers. You can read a skill and see exactly what it instructs Claude to do, whereas a server is a black box you have granted tool access to.

---

6. Turning All of This Into Actual Output

At the end of the day, code still has to be written.

Context work stops an agent making confident bad decisions, and by itself it produces nothing extra at all. The 8x came from somewhere else.

When your AI agent is confidently wrong.

Anthropic’s engineers stopped typing code and started directing and reviewing it.

The workflow the company recommends runs like this:

Explore → Plan → Code → Commit

The first two are the steps people skip on their way to a fast wrong answer.

Plan mode helps because it makes exploration read-only by construction instead of by request.

Then verify, which is where their guidance spends most of its attention.

An agent that can run your tests and read a real stack trace goes and fixes its own bugs, while an agent handed tests failed starts guessing, and guessing quickly is not productivity.

Everyone Is Talking About AI Agents. Most People Have No Idea How to Build One.

Their own security team reports that tracing control flow during an incident used to take 10 to 15 minutes and now takes roughly a third of that, because Claude could run things and read output instead of reasoning about code it had no way to execute.

So don’t focus on the headline.

Anthropic calls 8x almost certainly an overstatement of the true gain, cites outside research showing developers overestimate how much AI speeds them up, and when it polled 130 of its own research staff the median answer landed nearer 4 times.

What a weekend actually looks like

Set a deny list and one hook for whatever would ruin your week.

Run /init and then cut the result in half.

Make your test suite runnable in one command with failures a machine can read.

Then hand over a real ticket instead of a toy one, and watch what comes back.

After that it is maintenance.

You add a line when Claude repeats a mistake, delete a line when /doctor tells you it was derivable anyway, and keep the resident layer small enough that the model still has room to think.

The takeaway is that you don’t have to learn to describe what you want more precisely. You have to find the work you are willing to stop doing, then build enough checking that allows you to sleep comfortable at night.