Context Engineering

The practice of giving AI the surrounding context it cannot sense on its own.

You ask the AI to write a login endpoint (the function that logs users in). It delivers generic boilerplate — wrong framework, wrong folder, wrong error format. The AI is not stupid. It simply does not know your project.

Context Engineering is the discipline of giving the AI exactly the right information so it produces code that fits your codebase — not just any code that runs without errors. By the end of this article, you will understand how Context Engineering differs from Prompt Engineering, what belongs in a rule file, and how to decide which information the agent needs and when.

From Prompt to Context

Context Engineering is like onboarding a new team member. A good prompt is a well-asked question. Good Context Engineering is a complete onboarding package — architecture diagram, team conventions, build commands, typical workflows. Without onboarding, even a brilliant hire will make mistakes that any team member would have avoided.

Analogy:

Definition:

Context Engineering curates the entire set of information an AI model receives during a session — system instructions, tools, external data, conversation history. Anthropic describes Context Engineering as the natural evolution of Prompt Engineering because modern agents do not just answer a single prompt; they work across many interactions with growing context.

The onboarding analogy has a limit: a new hire learns and remembers permanently. An AI agent has a finite context window and may lose information when it overflows. The analogy does not capture the forgetting problem.

Prompt Engineering

You optimise the individual question. "Write a login endpoint" becomes "Write a login endpoint with NestJS in src/modules/auth/ using absolute imports." Quality depends on how detailed you are each time.

Context Engineering

You optimise the working environment. Through a rule file, the AI already knows your project uses NestJS, where services belong, and which error conventions apply. "Write a login endpoint" is enough — the context provides the rest.

"A better prompt fixes everything." — Even a perfect prompt cannot compensate for missing project context. You could write "use NestJS, absolute imports, put it in src/modules/auth/" every single time — but that means repeating your entire project setup in every conversation. Context Engineering externalises this into a persistent file so the agent starts informed without you repeating yourself.

The Rule File — Persistent Project Context

A rule file is a project-level configuration that your AI coding tool reads automatically on every interaction. The content is natural language: architecture overview, coding standards, build commands, anti-patterns, workflows. Anthropic recommends keeping it concise and well-structured — not a dump of everything, but a curated set of what the agent needs most.

Claude Code CLAUDE.md — Lives in the project directory, loaded automatically at every session.

GitHub Copilot .github/copilot-instructions.md — Repository-wide instructions in natural language.

Cursor .cursorrules / project rule files — Rule types like Always, Auto Attached, Agent Requested.

Like a cockpit checklist for pilots: the rule file does not teach the AI to fly — it ensures it consistently runs the same checks and avoids errors from carelessness.

Good content: Architecture overview (framework, folder structure), coding conventions (import style, error handling, naming conventions), build and test commands (npm run dev, npm test), anti-patterns (things the agent should never do), git workflow (commit format, branch strategy).

Bad content: Passwords, API keys, or credentials (security risk), the entire codebase (floods the context), information that changes constantly (belongs in task-specific files).

## Architecture
- Framework: NestJS 10
- All imports: absolute (never relative)
- Folder: src/modules/[domain]/

## Coding Standards
- Error responses: always use AppException class
- Tests: Jest, one spec file per service
- Never use console.log — use LoggerService

## Build & Run
- npm run dev (port 3000)
- npm test (all specs)

"Write it once and forget about it." — Anthropic explicitly describes CLAUDE.md as an ongoing practice. When the AI repeatedly makes the same mistake — placing services in the wrong directory, using the wrong test command, leaving unwanted comments — that mistake becomes a new rule. The file improves over time through real friction, not upfront planning alone.

Context Hierarchy — Less Is More

LLMs have a finite attention budget. As context grows, precision when retrieving and connecting information tends to decrease. The central question is therefore not "How do I fit everything in?" but "How do I load the right information at the right time?"

Permanent Project Rules CLAUDE.md, copilot-instructions.md — Architecture, standards, workflows. Always loaded.

Task-Specific Files Relevant source files, examples, documentation for the current task.

Conversation History The conversation so far with the agent — decisions, results, feedback.

Tool Results Search results, file contents, test outputs — loaded on demand, just in time.

Think of a surgeon's instrument tray. The operating room has thousands of instruments available, but only a small tray with the instruments needed for the current step is within reach. More instruments on the tray means more clutter, slower decisions, higher error risk. The surgeon asks for specific instruments when needed — just in time.

The analogy has a limit: a surgeon knows exactly which instrument they need. An AI agent must often discover what it needs during execution, using search and reading tools.

An example: a codebase with 50,000 lines. Bad approach: paste everything into the prompt. Good approach: CLAUDE.md provides the architecture overview, the agent uses search tools to find the specific files for the current task. Result: the agent works with 200 highly relevant lines instead of drowning in 50,000 lines of mixed relevance.

A good rule file is not written in one go but grows iteratively. The process: you start a task. You observe where the agent makes mistakes. You add a rule that corrects the error. Next time, the agent works closer to your project style. Example: the AI keeps placing services in src/services/ instead of src/modules/[domain]/. You add "Folder: src/modules/[domain]/" to the rule file. From now on, the agent uses the correct structure.

"The AI reads everything automatically." — It does not. Even models with large context windows lose focus when overloaded. Anthropic emphasises that the model's attention degrades with growing context. The discipline of Context Engineering is therefore about selection — choosing what goes in and what stays out — not about maximising input size.

Interactive: Why More Context Does Not Always Help

The article explains that precision decreases as context grows. Move the slider and observe how costs scale: loading the rule file is constant (green). Reading the entire context grows linearly (blue). But cross-referencing information — the agent's core job — grows quadratically (red). Beyond n=1000 information units, the difference becomes dramatic. This is why less relevant context beats more total context.

Input size n = 100

110000

Regeldatei laden1

Kontext lesen100

Infos verknüpfen (n²)10.000

Moderate Input

At n=100, the difference becomes visible: O(n²) requires 10.000 operations, while O(n) needs only 100. O(log n) needs just 6.6 — that's 15x less than O(n).

Ratio to O(n)

Complexity	Operations	Factor vs. O(n)
Regeldatei laden	1	100x faster
Kontext lesen	100	1x (Reference)
Infos verknüpfen (n²)	10.000	100x slower

Context Engineering shifts the bottleneck from prompt phrasing to information curation. Not how you ask, but what the agent already knows determines the quality.
A rule file (CLAUDE.md, copilot-instructions.md, .cursorrules) is the agent's onboarding package — architecture, conventions, commands — so it starts informed rather than from scratch.
More context is not better context. The agent needs the smallest relevant set at the right time — permanent rules on top, task-specific files in the middle, tool results at the bottom.

What is the main difference between Prompt Engineering and Context Engineering?

Prompt Engineering uses longer prompts, Context Engineering uses shorter ones.

Prompt Engineering optimises a single question; Context Engineering curates the agent's entire information environment.

Context Engineering only works with Claude, not with other models.

Prompt Engineering is for beginners, Context Engineering is for experts.

1. What is the main difference between Prompt Engineering and Context Engineering?

☐ A) Prompt Engineering uses longer prompts, Context Engineering uses shorter ones.
☐ B) Prompt Engineering optimises a single question; Context Engineering curates the agent's entire information environment.
☐ C) Context Engineering only works with Claude, not with other models.
☐ D) Prompt Engineering is for beginners, Context Engineering is for experts.

2. A developer notices their AI assistant always creates files in the wrong directory. What is the Context Engineering solution?

☐ A) Write a more detailed prompt each time specifying the directory.
☐ B) Switch to a different AI model.
☐ C) Add a rule to the project's rule file specifying the correct directory structure.
☐ D) Disable the AI assistant's file creation capability.

3. You have a 30,000-line codebase and want the AI to refactor a single service. Which approach follows the context hierarchy principle?

☐ A) Paste the entire codebase into the prompt for maximum context.
☐ B) Give the agent a rule file with architecture overview and let it use search tools to find the relevant files.
☐ C) Only provide the single file without any project context.
☐ D) Summarise the entire codebase in 500 words and paste that.

4. A team's CLAUDE.md file contains the database password, the full API key, and a list of all 200 microservice endpoints. Which statement best evaluates this setup?

☐ A) This is ideal because the AI has maximum information available.
☐ B) The credentials are a security risk, and the endpoint list likely exceeds the useful context — the file should contain architecture patterns and conventions instead, not secrets or exhaustive lists.
☐ C) Only the API key is problematic; the endpoint list is fine.
☐ D) The file is too short; it should also include the full database schema.

Answer Key: 1) B · 2) C · 3) B · 4) B

Checkpoint: Context Engineering

Explain the difference between Prompt Engineering and Context Engineering using the onboarding analogy.
What belongs in a rule file — and what should never be in one?
Why is it often worse to give the AI your entire codebase as context instead of only the relevant files?

Context Engineering

From Prompt to Context