Cybersecurity

Prompt Engineering vs Context Engineering

Python JavaScript TypeScript LLMs RAG Prompt Engineering Prompt Injection MCP AI Agents Authentication JWT Databases CSS Java Transformers

1,434 words Includes Code

Context engineering showing the difference between what a user sends (6 tokens) and what the model actually sees (15K tokens), context components grid, and polluted vs curated context comparison

📌 Key Takeaway

Prompt engineering controls what you ask. Context engineering controls what the model sees. When a 6-token user message triggers 15,000 tokens of system instructions, documentation, retrieved data, and tool definitions, the quality of that context determines the quality of the output — far more than the prompt alone.

You write a prompt: "Explain this code." The model sees much more than those 4 words. It sees system instructions, project documentation, relevant source files, retrieved examples, tool definitions, and conversation history. The prompt is 6 tokens. The context is 15,000 tokens.

Prompt engineering teaches you to ask better questions. Context engineering teaches you to build better environments for the model to answer in.

This article explains what context engineering is, why it matters, and how to practice it — with a practical coding project example.

Prompt Engineering vs Context Engineering
What Is Context Engineering?
The 8 Context Components
System Instructions
Project Documentation
Relevant Files
Examples
Retrieved Data (RAG)
Tool Definitions (MCP)
Memory and State
Context Pollution
Context Overload
Context Selection Strategies
Practical Example: AI Coding Project
FAQ
Conclusion

1. Prompt Engineering vs Context Engineering

Dimension	Prompt Engineering	Context Engineering
Controls	What you ask the model	What the model sees
Scope	User message (1–500 tokens)	Entire context window (1K–200K tokens)
Who controls it	The user	Application developer + user
When it matters	Every interaction	Agent and RAG systems
Skill level	Beginner-friendly	Intermediate to advanced
Impact	Improves answer quality	Determines answer quality

The Analogy:

Prompt engineering = asking the right question to a librarian.
Context engineering = ensuring the librarian has the right books on the desk before you ask.

Even the best question fails if the librarian has the wrong books.

Read our Prompt Engineering Complete Tutorial for foundational prompting skills.

2. What Is Context Engineering?

Context engineering is the practice of designing everything the model sees — not just the user's prompt, but the entire information environment.

WHAT THE MODEL ACTUALLY PROCESSES:

System Instructions     2,000 tokens  (1.6%)

Project Documentation    5,000 tokens  (3.9%)

Relevant Files           3,500 tokens  (2.7%)

Examples                  1,000 tokens  (0.8%)

Retrieved Data (RAG)      1,500 tokens  (1.2%)

Tool Definitions            500 tokens  (0.4%)

Conversation History      2,000 tokens  (1.6%)

User Message                  6 tokens  (0.005%)

TOTAL:                   15,506 tokens (12.1% of 128K)

Remaining:              112,494 tokens (87.9%)

The user's prompt is 0.005% of the context. The other 99.995% is context engineering.

3. The 8 Context Components

Component	Purpose	Example
System Instructions	Rules, persona, behavior	"You are a senior Python developer"
Documentation	Project context	README, API docs, architecture
Relevant Files	Source code for the task	app.py, models.py, routes.py
Examples	Demonstrations of desired behavior	Existing code patterns in the project
Retrieved Data	Relevant knowledge from RAG	Flask auth documentation chunks
Tool Definitions	Available tools and schemas	MCP server tools, file operations
Memory	Session-level state	"We decided to use JWT, not sessions"
State	Persistent information	User preferences, project config

4. System Instructions

System instructions define the model's behavior, expertise, and constraints. They are the foundation of context engineering.

BAD (generic): "You are a helpful assistant."

GOOD (specific): "You are a senior Python developer with 10 years of experience. Follow PEP 8, use type hints, write docstrings, prefer pathlib over os.path, and always handle exceptions gracefully."

Key principle: The more specific your system instructions, the more consistent and predictable the model's behavior.

5. Project Documentation

Including relevant documentation helps the model understand your project's architecture, conventions, and constraints.

Document	Include?	Why
README.md	✅ Yes (summary)	Project overview, setup, conventions
API documentation	✅ If relevant	Endpoint schemas, expected formats
Architecture docs	✅ If available	Design decisions, component relationships
Deployment guide	⚠️ Only if relevant	Environment-specific details
Changelog	❌ Usually no	Too detailed, low relevance

6. Relevant Files

AI coding agents select which files to include based on the task. The goal is to include files that are directly relevant to the current task.

The Golden Rule of File Selection:

Include every file the model needs to understand the task.
Exclude every file that is not directly relevant.

More files ≠ better context. Relevant files = better context.

See How AI Coding Agents Actually Work for how agents automatically select relevant files.

7. Examples

Examples in context show the model the exact pattern you want it to follow. They are especially powerful for maintaining consistency.

EXAMPLE IN CONTEXT:

Existing endpoint pattern in your codebase:

@app.route('/api/users', methods=['POST'])

def create_user():

    data = request.get_json()

    validate_input(data)

    user = User.create(data)

    return jsonify(user.to_dict()), 201

The model now knows to follow this exact pattern for new endpoints.

8. Retrieved Data (RAG)

Retrieved data comes from RAG (Retrieval-Augmented Generation) — searching a knowledge base for relevant chunks and including them in context.

WITHOUT RAG:

Load entire 100K-token documentation → 95% irrelevant → expensive, slow, confusing

WITH RAG:

Query: "Flask JWT authentication" → Retrieve top 3 relevant chunks (2K tokens) → focused, relevant, cheap

RAG is the primary mechanism for keeping context relevant when the knowledge base is larger than the context window.

Learn more in RAG Architecture Explained.

9. Tool Definitions (MCP)

When AI agents can use tools (file operations, terminal commands, APIs), those tools must be defined in the context. This is where MCP (Model Context Protocol) matters.

Tool Type	Token Cost	Context Impact
File read/write	~100 tokens	Low
Terminal execution	~150 tokens	Low
Web search	~200 tokens	Medium
Database query	~150 tokens	Low
MCP server (many tools)	500–2,000	Can be significant

Key insight: Every tool definition consumes context tokens. Too many tools reduce the space available for actual task content.

Learn more in MCP vs APIs.

10. Memory and State

Memory preserves information across conversation turns. State persists across sessions.

Type	Scope	Example
Short-term memory	Current conversation	"We decided to use bcrypt"
Long-term memory	Across sessions	User prefers TypeScript over JavaScript
Project state	Persistent	Current branch, recent changes, test results

11. Context Pollution

Context pollution is irrelevant, harmful, or contradictory content in the context window.

Pollution Type	Example	Impact
Irrelevant files	Including payment.py for an auth task	Dilutes attention, increases cost
Stale information	Old API docs when API changed	Wrong answers
Contradictory data	Two files with conflicting configs	Model confused
Excessive history	50 messages of old conversation	Lost in the middle
Noisy retrieval	RAG returns irrelevant chunks	Hallucination risk
Prompt injection	Malicious content in retrieved docs	Security risk

12. Context Overload

Context overload occurs when too much information overwhelms the model's ability to process it effectively.

RESEARCH-BASED THRESHOLDS:

< 4K tokens: Excellent attention across all content
4K–32K: Good, but middle content may be less attended
32K–128K: "Lost in the middle" becomes significant
> 128K: Careful curation required

See Tokens & Context Windows Explained for more on context limits.

13. Context Selection Strategies

Strategy	How It Works	Impact
Relevance Filtering	Only include files related to the task	High
Importance Ranking	Score and rank by relevance	High
Chunking	Split large docs, retrieve relevant chunks	High
Summarization	Compress old or less relevant context	Medium
Deduplication	Remove redundant information	Medium
Lazy Loading	Load context only when needed	Medium

14. Practical Example: AI Coding Project

Let us compare polluted vs curated context for a real task:

❌ BAD CONTEXT (polluted — 45K tokens):

System: "You are a helpful assistant" (generic)

Files: ALL 47 files in the repository (90% irrelevant)

History: 30 messages about unrelated CSS styling

Docs: Full README (mostly about deployment)

User: "Add authentication"

Result: 80% irrelevant context, slow, expensive, poor quality

✓ GOOD CONTEXT (curated — 8K tokens):

System: "Senior Python dev. Use bcrypt, JWT, follow Flask patterns."

Files: app.py, models.py, routes.py, requirements.txt

Docs: Flask auth docs (retrieved via RAG, 2K tokens)

Examples: Existing user registration pattern

User: "Add authentication to the API routes"

Result: 95% relevant, fast, cheap, high quality

15. FAQ

Is context engineering the same as RAG?

No. RAG is one technique used in context engineering. Context engineering is the broader practice of designing everything the model sees — including system instructions, files, examples, tools, memory, and retrieved data. RAG handles the "retrieved data" component.

How is this different from prompt engineering?

Prompt engineering focuses on crafting the user's message. Context engineering focuses on everything else — what documentation, files, examples, and tools are available to the model. A perfect prompt fails with bad context. Good context makes even simple prompts effective.

When does context engineering matter most?

It matters most in AI coding agents, RAG systems, and any application where the model needs to understand project-specific context. For simple chat interactions, prompt engineering is usually sufficient.

What is "lost in the middle"?

Research shows LLMs attend more to tokens at the beginning and end of the context window, and less to tokens in the middle. In long contexts, placing important information in the middle can cause the model to overlook it.