How to keep Claude Code & Codex smart and fast

I spent the last 12months fighting my predisposition toward perfectionism and minimalism while trying to manage a pack of LLM coding agents: part brilliant engineer, part overexcited intern, part feral cat loose in a server room.

They are incredibly capable, speak fluent plausible garbage, and will happily consume every scrap of context you give them.

This is a self-reflection on what I learned while trying to tame that chaos, and how I finally started feeling on top of the agents instead of underneath a mountain of their context.

The 8 rules of code development with agents

1. Keep behavioral instructions to a minimum. Every permanent rule is another opportunity for ambiguity, contradiction and staleness.
2. Keep permanent agent context small. AGENTS.md and CLAUDE.md should be concise maps to knowledge, not knowledge dumps.
3. Put information where it naturally belongs. Keep project knowledge in documentation and teach the agent how to find it.
4. Prefer executable checks over prose. If a rule can be enforced by code, tests, linters, types or scripts, do that instead.
5. Give context a lifecycle. Long-lived knowledge belongs in the repository; temporary knowledge belongs with the work that created it.
6. Keep feature context ephemeral. Current implementation details should live in milestones, epics and tasks, not permanent agent files.
7. Make fresh agent sessions cheap. A new agent should need only the current task, its surrounding context and access to the repository.
8. Give the agent only the context it needs. Provide the smallest amount of accurate, relevant and current information required for the task.

Simple retrieval is getting very good. Reasoning over large amounts of noisy, competing or semantically similar information remains much harder.

The more permanent context we give coding agents, the more likely it is to become contradictory, stale or irrelevant. My approach is therefore to keep permanent agent context small and move temporary working knowledge into tasks, epics and milestones.

1. Keep behavioral instructions to a minimum

The larger the context becomes, the more likely it is to contain conflicting instructions.

Imagine AGENTS.md tells the agent to follow existing code conventions, while another rule says functions in .tsx files must always be named. Most of the codebase uses anonymous functions.

Which instruction wins?

The agent now has to reason about a conflict that should not exist.

We write code because code is precise. When we start using English prompts as code, we lose many of the checks programming languages give us. Natural-language rules are ambiguous, hard to validate and easy to leave behind after the code changes.

That is why I try to keep behavioral instructions to a minimum.

2. Keep project context factual

Different coding agents use different files. Codex and Cursor may use AGENTS.md, while Claude Code uses CLAUDE.md.

The filename does not really matter.

I keep these files factual, neutral and concise. Their job is to help the agent understand the repository and find information, not describe how it should behave in every possible situation.

For example:

• project architecture belongs in architecture documentation
• testing standards belong in testing documentation
• API requirements should preferably be encoded in schemas and tests
• architectural boundaries should preferably be enforced by linters or architecture tests
• AGENTS.md or CLAUDE.md should explain where to find these things

Do not put less knowledge in the repository. Put less knowledge in permanent agent context.

A useful rule is:

Put information where it naturally belongs, then teach the agent how to find it.

3. Prefer executable checks over prose

If something can be deterministic, make it deterministic.

Suppose every API change needs to:

• satisfy its Zod schema
• contain no floating promises
• pass the API test suite

I could write all three instructions into an agent file.

Or I could expose:

pnpm check:api

That command can run the schema checks, ESLint and tests.

Now the agent only needs to know how to verify its work. The actual verification remains deterministic.

If another requirement appears next month, I update the command rather than hunting through prompts and agent instructions.

The less procedural knowledge encoded in natural language, the less procedural knowledge can become stale.

4. Give context a lifecycle

Not all context deserves to live forever.

I roughly divide it by lifespan:

Project context
Languages, frameworks, architecture, repository structure and documentation locations. This changes slowly and belongs in permanent documentation.

Milestone context
The larger project, usually spanning multiple pull requests.

Epic context
A substantial unit of work, often corresponding to one pull request.

Task context
The individual piece of implementation work happening now.

The mistake I see most often is taking temporary feature context and putting it into AGENTS.md, CLAUDE.md or another permanent rules file.

That information may be useful today and wrong next month.

I instead keep temporary context in a structured task tracker. I use Beans, which stores milestones, epics and tasks as Markdown, but the specific tool is not important.

The important part is that temporary context remains temporary.

A task might matter for an hour.
An epic might matter for a few days.
A milestone might matter for a month.
An architectural decision might matter for years.

The information should disappear from active context roughly when it stops being useful.

5. Fresh agents should be cheap

This structure makes starting a fresh agent session inexpensive in the middle of work.

The new session does not need the previous conversation.

It needs:

• the current task
• the epic explaining why the task exists
• the milestone explaining the larger goal
• access to the repository

Everything else can be discovered when it becomes relevant.

The task tracker becomes shared working memory between me and the agent. I can see what is in progress, complete or still under review without depending on a giant conversation history.

It also makes context switching much easier. Instead of rereading pages of generated text, I can return to the relevant task and understand what happened.

References

• Rando et al. (2025), LongCodeBench: Evaluating Coding LLMs at 1M Context Windows
• Hsieh et al. (2024), RULER: What's the Real Context Size of Your Long-Context Language Models?
• Hong, Troynikov & Huber (2025), Context Rot: How Increasing Input Tokens Impacts LLM Performance
• Anthropic (2025), Effective context engineering for AI agents
• OpenAI (2026), Harness engineering: leveraging Codex in an agent-first world