You ask an AI coding agent to implement a change. It almost works. You tweak the prompt. It works better. You switch models. Now it works—but you have no idea why, no record of how you got there, and no reliable way to reproduce the result tomorrow without re-explaining everything from scratch. Meanwhile, as a code reviewer, you’re staring at pages of AI-generated code that looks confident but ignores architectural decisions, violates coding guidelines, and quietly ships bugs under a layer of verbosity.

These failures aren’t random, and they aren’t because the models are bad. They happen because AI agents are operating with incomplete, inconsistent, or transient context. When the system doesn’t understand your constraints, design intent, or prior decisions, hallucinations, slop, and irreproducible outcomes are the natural result—no matter how good the prompt sounds. A better model will not fix this—but better context will. Stop chasing better AI models and start building better context.

Context engineering is how you fix this. In this post, you’ll learn what context engineering really means, the core concepts behind it, and the practical patterns that make AI coding agents more accurate, consistent, and reviewable. We’ll keep tools lightweight and focus on ideas—then briefly show how these patterns apply in popular agents like GitHub Copilot, Cursor, and Claude.

Example 1: Consistent Feature Implementation Across a Large Codebase
An AI coding agent is given access to the project’s directory structure, coding conventions, approved libraries, and a short architectural overview. Instead of generating generic boilerplate, it produces code that matches existing patterns, respects internal abstractions, and integrates cleanly with surrounding modules—without repeated prompting or manual correction.

Example 2: Reviewable, Low-Slop Code Generation
By supplying context such as linting rules, formatting standards, and “do-not-use” patterns, the AI generates concise, idiomatic code rather than verbose or speculative implementations. Code reviewers can immediately trace assumptions and decisions back to documented context instead of reverse-engineering intent from the output.

Example 3: Architecture-Aware Design Suggestions
When designing a new service, the AI is provided with system constraints, scalability goals, and existing service boundaries. Rather than proposing a greenfield design, it recommends an approach that aligns with current architecture—reusing shared components, respecting data ownership & relationships, and avoiding known anti-patterns.

Example 4: Decision-Driven API Design
By feeding prior design decisions, trade-offs, and non-functional requirements into the context, the AI can propose APIs that reflect intentional choices (e.g., async vs sync, eventual consistency, backward compatibility). This prevents surface-level designs and ensures new interfaces fit naturally into the broader system.

Large language models can process vast amounts of text, but more context does not automatically produce better results. As the context window grows, models begin to lose precision—a phenomenon often called context rot. Research shows that adding more tokens reduces a model’s ability to accurately recall and prioritize relevant information. This effect appears across all models, even if some degrade more gracefully than others. Context is therefore a finite resource with diminishing returns, similar to human working memory. Every additional token consumes part of the model’s limited attention budget, making careful curation more important than sheer volume.

These limits stem from the transformer architecture itself. Because every token attends to every other token, the number of relationships the model must reason about grows quadratically as context increases, diluting attention and focus. This is further compounded by training data that favors shorter sequences, leaving models less optimized for long-range dependencies. The takeaway is clear: effective context engineering is not about maximizing context size, but about selecting and structuring the right information so attention is spent where it matters most.

As Andrej Karpathy notes, LLMs resemble a new kind of operating system: the model acts as the CPU, and the context window functions like RAM—its working memory. This memory is limited and must be carefully managed across competing sources of information. Just as an operating system decides what lives in RAM, context engineering determines what enters the context window.

At a high level, the context fed into an LLM falls into three categories: Instructions, Knowledge, and Tools.

Instructions define how the agent should behave and reason.

Knowledge defines what the agent knows.

Tools connect the agent to the external world.

Let’s go into detail.

If agents have the ability to save memories, they also need the ability to select only the memories relevant to the task at hand. This is critical for keeping context focused and avoiding noise.

Different types of memories serve different purposes:

A common challenge is ensuring the right memories are selected. Many agents address this by relying on a small, fixed set of files that are always injected into context. For example:

These files typically store procedural memories and, in some cases, curated examples.

Agents rely on tools, but too many tools can become a liability. Overlapping or poorly differentiated tool descriptions often confuse the model, making it harder to choose the correct tool.

One effective approach is to apply retrieval-augmented generation (RAG) to tool descriptions themselves. Instead of exposing all tools at once, the system retrieves only the most relevant tools for the current task and injects those descriptions into the context window.

RAG is a deep topic and one of the hardest problems in context engineering. Code agents are among the best real-world examples of RAG operating at scale.

A key insight from production systems is that indexing code is not the same as retrieving context. As Varun from Windsurf explains:

The takeaway is that retrieval quality—not retrieval volume—determines agent effectiveness.

Now that we’ve covered context engineering fundamentals and established project- or enterprise-level context, the next step is learning how to correctly specify feature- or task-level context. This is where many teams still fall back to ad-hoc prompting—and where most AI-generated code quality issues originate.

A simple but powerful pattern solves this: RPI — Research, Plan, Implement.

RPI enforces discipline in how context is created, refined, and consumed by coding agents. You can follow this pattern manually with any AI coding assistant, or adopt tools like Spec-It or Goose that operationalize RPI using custom slash commands, structured files, and automated branch management.

RPI is the missing pattern between raw prompting and scalable AI-assisted engineering.
Spec-Drive development (SDD) is the natural evolution once RPI becomes habit.

The RPI workflow breaks work into explicit, sequential phases. Each phase has a clear purpose and produces artifacts that become context for the next phase.

Document what exists today. No opinions.

The goal of research is to ground the agent in reality:

This phase prevents speculative design and reduces hallucinations before they happen.

Design the change with clear phases and success criteria.

Planning externalizes reasoning:

A good plan turns “do the thing” into a concrete, reviewable blueprint.

Execute the plan step by step—with verification.

Implementation becomes execution, not exploration:

Optional iteration loops allow refinement without collapsing back into chaos.

GitHub Copilot’s context engineering workflow in VS Code formalizes RPI and moves teams away from reactive prompting.

Before touching code, Copilot is given durable, high-value context:

These are typically captured in files like:

This ensures Copilot has persistent context across tasks—not just whatever happens to be open in the editor.

Instead of coding immediately, Copilot is asked to produce a plan:

Planning forces clarity and dramatically reduces rework.

With context and a plan in place, Copilot generates code that:

The result is less back-and-forth and more predictable outcomes.

RPI is not just a workflow—it is a gateway to Specification-Driven Development (SDD).

In SDD, specifications become the primary artifact:

Design, implementation, testing, and iteration collapse into a continuous loop.

SDD matters now because:

When specifications drive implementation, pivots become regenerations—not rewrites.

Spec-It operationalizes RPI and SDD through structured slash commands.

Create governing rules once—reuse everywhere.

Defines code quality, testing standards, UX consistency, and performance expectations.

Automatically:

Creates:

Executes tasks according to the plan, using specs as the guiding context.

Test-Driven Development (TDD) complements RPI and SDD, especially for verifiable changes:

With agentic coding, TDD becomes faster and more reliable—tests and implementation evolve together from the same specification.

Context engineering does the heavy lifting, but prompting still matters. Prompts form the task-specific context that activates the right parts of your engineered context at the right time.

The core rule is simple:
Don’t just state the action—state the intent, constraints, and references.

Good prompts reduce ambiguity, activate relevant context, and produce reviewable output.

High-leverage prompts typically include:

For non-trivial tasks, ask the model to plan before coding:

These inputs dramatically improve relevance and reduce wasted iterations.

Context is a finite resource.

Fresh context improves focus and accuracy.

Repetitive prompts waste time and introduce inconsistency.

Instead, define custom slash commands for common workflows (e.g., security review, performance analysis). Store them as markdown files (for example, in .claude/commands/) so they are reusable, consistent, and easy to evolve.

Resist the urge to create an exhaustive CLAUDE.md up front. Because it’s injected into context every time, keep it concise and high-signal. Break detailed guidance into separate markdown files and reference them selectively.

The goal is not more context—it’s the right context, activated by the right prompt.

-Sanjai Ganesh Jeenagiri