Context Engineering Is System Design: Why Prompt Engineering Fails at Codebase Scale
Every engineer who has shipped AI-assisted code reviews has hit this moment: the model returns a clean, test-passing pull request that uses a deprecated library or quietly violates a core architectural pattern. The code works — it just doesn't fit. That gap is the central problem the Kodus team dissects in a new piece that argues prompt engineering was always a local optimization, not a systems solution.
The core diagnosis is structural: no matter how carefully you craft a prompt, the model operates only within its context window. It has no visibility into your dependency graph, no awareness of the rationale behind past architectural decisions, and no access to the team conventions that experienced engineers carry in their heads. Tweaking prompts is a losing game because every model update and every codebase change breaks the brittle knowledge you embedded there. Context engineering proposes a different target: instead of optimizing the instruction, you design the environment the model works in — an infrastructure layer that selects, filters, and delivers exactly the right information at call time as structured JSON or YAML.
The practical principles are immediately deployable: keep context-fetching modules separate from prompt-formatting code so each is independently testable; use structured formats over unstructured text for deterministic model interpretation; version your context sources like API schemas so past generations are reproducible when debugging; and treat explicit versus implicit knowledge as a real architectural decision — your team's style guide must be injected deliberately, while basic Python syntax doesn't. The framing that anchors the piece — "the real intelligence is in the system that feeds the model, not the model itself" — is a useful corrective for any team still trying to solve reliability through prompt iteration alone.