From Prompt Engineering to Context Engineering
Large models have outgrown prompt wordsmithing. Prompt engineering studies phrasing tricks to elicit better behavior; modern models neither need nor benefit from such manipulation. What they need is information in the Shannon sense — signals that collapse uncertainty. Even though they already possess all the knowledge humans have ever generated, they still need information as a filter that narrows the boundless corpus to the task at hand, ensuring decisions are made correctly within the specific scenario. That is the mindset of context engineering.
But context engineering isn’t new. Decades of software engineering have taught us how to break big problems into manageable pieces that fit within a human brain’s context window. We don’t have to start from scratch — software engineering already provided the foundations.
Static & Dynamic Parts of Software Engineering
In agile discourse we often conflate two very different ideas: practices like Scrum and XP that help teams adapt through process, and design techniques like SOLID that help systems adapt through structure. This is a useful fault line. Let’s call the first the dynamic side (people, cadence, and collaboration mechanisms) and the second the static side (architecture and interfaces that localize change).
In the AI era, much of the dynamic guidance that centers on meetings and rituals matters less; what endures is iterative design discipline (we will talk about it in depth in the next article). This article therefore focuses on the static side.
At the core of static design is the interface: the contract that bounds knowledge, hides implementation, and lets components and agents cooperate safely at minimal context cost.
SOLID Context Engineering
Interfaces sit at the heart of agile design because they bound context. They define what a component must know, what it promises, and what it can safely ignore. Read through a context lens, each SOLID principle is guidance on how to manage context pressure so change stays local and reasoning stays cheap.
Single Responsibility (S)
- Interface view: One reason to change per component means one coherent interface surface. The context required to understand or modify it remains small and focused.
- Context effect: Limits the blast radius of updates. Agents and people load less background to act correctly.
Open/Closed (O)
- Interface view: Keep interfaces stable, extend behavior via new implementations or composition.
- Context effect: New capabilities attach at the edges without reshaping prior knowledge. Historical context stays valid; only deltas need to be learned.
Liskov Substitution (L)
- Interface view: Subtypes must honor the contract. Callers reason only about the base interface.
- Context effect: Call sites carry minimal assumptions. Replacements don’t force re-reading the system; context is portable.
Interface Segregation (I)
- Interface view: Prefer many small, client-specific interfaces over one fat interface.
- Context effect: Each consumer depends on a narrow slice of knowledge. This shrinks token budgets and human attention, improving precision for both.
Dependency Inversion (D)
- Interface view: Depend on abstractions, not concretions. High-level policy exposes contracts that low-level details implement.
- Context effect: Business intent becomes the canonical context. Infrastructure details fall out of the primary reasoning loop and can change independently.
Putting it together
Interfaces compress context legally, not heuristically. They express invariants, pre/post-conditions, and data shapes so humans and agents can operate with bounded knowledge and predictable outcomes.
SOLID is a context-management playbook: constrain what must be known (S, I), preserve prior knowledge under change (O, L), and root reasoning in policies rather than mechanisms (D).
For agents, interfaces are the safest API to the codebase and the spec. Make them typed, testable, and injectable so the same contracts drive generation, verification, and runtime execution.
Conclusion
Starting from established software engineering practice, we split context engineering into a static side (architecture and interfaces) and a dynamic side (process and collaboration). At the center of the static side is the interface — the contract that bounds and manages context so change stays local and reasoning stays cheap. Read this way, the traditional SOLID principles remain highly relevant today: they are a proven playbook for context management, turning specifications and code into stable, composable contracts that both humans and agents can rely on.
The next article will explore the dynamic side. AI agents offer rapid execution and immediate feedback, allowing us to collapse traditionally complex, multi-stage processes into a simple Plan–Execute–Verify loop that mirrors how humans naturally think and work.