What Happened

The terminology shifted.

In June 2025, Andrej Karpathy (former Tesla AI lead, OpenAI co-founder) said:

When people hear "prompt," they think of a short instruction passed to an LLM. But what really matters in production-grade LLM applications is the art and science of filling the context window with exactly the right information for the next step.

This triggered an industry-wide shift from "prompt engineering" to "context engineering." In September 2025, Anthropic (the team behind Claude) systematized the concept in their official engineering blog. By July 2025, Gartner predicted that "by 2028, 80% of AI application building tools will incorporate context engineering capabilities."

In the Japanese-language ecosystem, "prompt engineering is outdated" became a standard headline in the second half of 2025, with explainer articles proliferating across Qiita, Zenn, note, and Forbes JAPAN. As of mid-2026, the terminology shift is essentially complete.

Runtime Focus

What the industry is discussing.

Nearly all context engineering discussion focuses on runtime — what to pack into the context window at the moment AI runs.

System Prompt System prompt design Role definitions, output format specifications, constraint declarations.
RAG External knowledge retrieval Which documents to pull, which chunks to inject.
Tool Definition Tool definition design When and which tools to expose to the AI.
Token Budget Token budget management Strategies for summarizing, compressing, and truncating stale context.

These are all important techniques, no argument there. But there is a hidden assumption: that high-quality context already exists, ready to be managed.

The Missing Layer

What is not being discussed.

Context does not fall from the sky. Someone has to create it.

Consider working with an AI agent like Claude Code or Codex. Tell it "build me an English learning app" and it will generate some code. But there is no guarantee that what it builds is what you actually want. The AI does not know the requirements inside your head.

What you need here is not runtime context management. It is the act of authoring the context itself.

Design-Time Context

What it means to "create" context.

One method we teach in our corporate training is document-first development. Before writing a single line of code, you write design documents as files.

Design documents are "context injection for AI." By writing your
intent in a format AI can read, implementation accuracy improves dramatically.
— From the Learn Premium curriculum

In practice, before writing code you create design documents in a docs/ folder:

concept.md What and why The core of the product. Articulating the design's Why — e.g., "a closed learning loop."
architecture.md How to build it Layer structure, dependency rules, integration policies with external services.
data-schema.md Data shapes Key type definitions and concrete sample data (JSON examples).
CLAUDE.md Project rules Constraints and conventions the AI agent always references. Persistent context.

These files persist even when conversations grow long and older context gets compressed. The AI can always re-read them. Context window contents are volatile, but filesystem context is persistent — this distinction matters.

Furthermore, these documents are not written alone. They grow through back-and-forth with AI.

Design documents are not "written by AI" but "written with AI."
You convey what you want to build and why.
AI structures it — this collaboration produces good documents.
— From the Learn Premium curriculum

Research, spar with AI, revise the document. Each iteration raises the quality of context. Before deciding what to "pack" into the context window at runtime, there is a process of "refining" context worth packing.

In our corporate consulting, we take this further: treating document authoring as the primary phase of development. Coding is the step that compiles precisely written design documents into machine code. As AI agents improve, this compilation gets more accurate. The only differentiator is the quality of the source design documents.

Two Layers

Two layers of context engineering.

Context engineering has two layers.

Runtime Context management At the moment AI runs, what goes into the context window and what stays out. System prompts, RAG, tool definitions, token budget optimization. The industry discussion is concentrated here.
Design-Time Context creation Before collaborating with AI (and during the collaboration), the process of authoring the context itself. Design documents, rule files, data schemas, explicit constraints. Systematization of this layer has barely begun.

Runtime-layer technology is advancing rapidly. RAG accuracy is improving, tool definition design patterns are maturing, and automatic token budget management is reaching production readiness.

But no matter how far you push runtime optimization, if the high-quality context to inject does not exist, the optimization spins in place. If the documents RAG retrieves are poor, better search precision will not improve output. If the constraints in your system prompt are vague, polishing the phrasing will not help.

The design-time layer is a prerequisite for the runtime layer.

Prompt Engineering Is Not Dead

Prompt engineering is not dead.

"Prompt engineering is outdated" — this headline is everywhere. It is half right and half misleading.

What became outdated: the hunt for "magic phrases" that boost scores. Model evolution commoditized that.

What did not: the design skill of what to tell AI and how. Making constraints explicit. Structuring requirements. Verifying AI's assumptions. These remain the core of prompt design and are constituent elements of context engineering.

Prompts did not become unnecessary — they were subsumed into the higher-order concept of context. A prompt is part of context; from the perspective of designing context as a whole, it is one element.

The prompt-as-code syntax standard that this lab has been developing treats prompts not as throwaway text but as executable code. This direction is becoming more relevant in the context engineering era. As the number of prompts injected at runtime grows — system prompts, tool definitions, inter-agent instructions — the need for a discipline governing their syntax and quality grows with it.

In fact, prompt-as-code v0.3.0 (published December 2025) already describes key context engineering components. Section 5 (Structuring Patterns) covers context structuring patterns, Section 6 (Structured Reasoning) covers verification loop design such as Chain of Verification, and Section 7 (Prompt Chaining) covers context management and data dependency tracking across multi-step prompts. These were systematized from a prompt syntax perspective before "context engineering" became an industry term.

What We Teach

What the Lab teaches.

In our Learn Premium program and corporate consulting, we cover both the runtime and design-time layers. The emphasis, however, is on the design-time side.

We teach patterns, not terminology.

Write documents before code Create context before execution
Ask AI "did you actually check?" Verify the quality of context
Stop AI from going off the rails Guard context boundaries (scope)
Humans design the tests Set verification criteria as context
Research, spar, re-research Iteratively refine context

These are skills for "using AI," but they are also universal skills that apply to managing people, steering projects, and ensuring decision quality. Terminology changes. Patterns endure.

The phrase "context engineering" may eventually be replaced by yet another term. But the core question — who decides what the AI knows and does not know, and how — will not disappear as long as we work alongside AI.

The answer to that question cannot come from runtime optimization alone. Before the techniques for manipulating context window contents, there is the quieter work of carefully crafting what belongs there.

The Lab teaches that work.