Context Engineering Explained in 5 Minutes

You've likely heard of vibe coding, a term Andrej Karpathy coined for a practice developers had been using for months. Now, history repeats itself. Karpathy, a founding member at OpenAI, has inadvertently named another emerging practice: context engineering.

Just like vibe coding, context engineering isn't new. Many in the development community have been applying its principles for some time. However, Karpathy is right about one thing: this approach is absolutely necessary for the future of coding with AI.

This article is more than just an explanation. We will go hands-on with the principles of context engineering, showing you not only how to prepare the necessary context but also how to properly use it—a step that many developers are currently missing.

From Prompt to Context Engineering

First, it's essential to understand that all language models operate within a "context window," which is the amount of text they can remember at any given time. With traditional prompt engineering, we carefully phrase requests to get a single, high-quality answer from the LLM.

Context engineering is different. Instead of a single prompt, we fill the model's context window with all relevant facts, rules, tools, and information for a given task. This drastically reduces the chance of hallucination and ensures the model has a complete understanding of what it needs to do. We are actively shaping what the model needs to remember to achieve our goals.

This represents a fundamental shift. Context engineering is a broader discipline that encompasses various techniques, including Retrieval-Augmented Generation (RAG), memory management, and even prompt engineering itself. It's the art of creating a comprehensive environment for the AI to operate within.

The Role of Modern LLM Apps

The application you use is just as important as the context you provide. An LLM app is no longer just a simple wrapper for a chat interface. Modern tools provide the necessary components, workflows, and utilities for effective context engineering.

Applications like Cursor and Claude Code are prime examples. They have evolved beyond basic chat functionality to become critical components in the context engineering toolkit. While both have their strengths, and are continuously adding new features, the workflow described here is adaptable to either platform.

A Practical Workflow for Context Engineering

You might be tempted to simply give the model every piece of information you have. However, this can be counterproductive. Once a model's context window fills up, the risk of hallucination actually increases. Efficient management of the context window is crucial. You can't just dump everything into one file; you must break it down and provide context strategically.

Here is a workflow I've refined over time, inspired by best practices from across the community, including the idea of incorporating external documentation.

1. The Project Requirement Document (PRD)

We begin with a PRD, which lists the desired features for the project. As a developer, you can add specific technical requirements here. For instance, I might specify that I want to use Next.js for the front end and FastAPI for the back end. Even if you don't specify a tech stack, this workflow can help the model configure an appropriate one.

2. The Documentation Folder

This folder contains the core context for the AI model. It includes four essential files:

• Implementation Plan: A step-by-step guide for building the project.
• Project Structure: Defines the file and folder layout (initially empty, generated by the AI).
• UI/UX Documentation: Contains guidelines for the user interface and experience.
• Bug Tracking: A log for tracking and resolving issues.

These files provide the different components of context the AI needs to complete the project.

3. The Guiding Rules

The model also needs to know how to use this context. For that, I use two simple rule files:

• The generate rule: This is a one-time instruction that tells the model to convert the PRD into the four documentation files listed above. It generates the complete context required for the development process.
• The work rule: This is a small, persistent file that is always included in the context. It instructs the AI on how to use the documentation files during implementation. For example:
  • When implementing a feature, refer to the Implementation Plan.
  • When working on the UI, consult the UI/UX Documentation.
  • Before creating a file or running a command, check the Project Structure for consistency.
  • If an error occurs, check the Bug Tracking file to see if it's a known issue.

This workflow rule is kept intentionally small to occupy minimal space in the model's limited context window.

Executing the Plan

The Implementation Plan contains high-level task lists, which are then broken down into subtasks. While tools like Cursor and Claude have built-in task list features, this approach allows the model to decide whether a subtask is simple enough to execute directly or complex enough to require its own new task list within the LLM app.

For example, a task like "Design and implement the database schema" would be broken down into numerous smaller steps by the AI. This is where a capable LLM app becomes indispensable. Because the entire plan is documented, you can open a new chat—effectively resetting the context window—and the AI can pick up exactly where it left off by consulting the implementation file. That is the core idea of context engineering.

Important Considerations

1. Review Everything You must be meticulous and read everything you give to these AI models. They follow instructions blindly. If your documentation contains conflicting or contradictory information, the results will be unpredictable. Take the time to review all generated files to ensure they align with your goals before proceeding.

2. Decide on the Tech Stack Yourself While the workflow can suggest a tech stack, I recommend making this decision yourself. The AI might choose a technology that is technically compatible with the PRD but not with your own skills or resources. To avoid this, it's better to research and define the tech stack outside of the AI-driven context generation process.

The Workflow in Action

To start, I open a new chat and instruct the model to begin building the app according to stage one of the implementation plan. Even with no prior context in the chat, the model reads the plan and immediately understands the project, the tech stack, and the required steps.

It proceeds to create a to-do list and executes each item sequentially, installing dependencies and scaffolding the project structure. The backend, frontend, scripts, and shared folders begin to take shape. The model configures the Python backend, sets up the necessary APIs, and lays the entire foundation. This step-by-step process, while methodical, ensures that nothing is missed and the project is built on a solid foundation.

Final Thoughts

This documentation-based approach is far more effective for managing context than dumping everything into a single file. While the implementation files for this workflow can serve as a starting point, the real value comes from understanding the underlying principles.

With that understanding, you can build your own custom workflows and documentation structures tailored to your specific needs, whether you're using Cursor, Claude Code, or any other advanced LLM application.