Context engineering is the new schema design
Schema design has always been three decisions: how information is represented, at what grain it's stored, and who owns which part of it. Deciding what goes into a context window — in what structure, with what priority — is the same three decisions under a token budget. Teams doing "prompt engineering" by vibes are doing schema design without knowing it, and mostly doing it badly.
Take representation first. A production system prompt isn't a paragraph; it's a typed record. The compositional pattern that's emerged — persona, capability grants, output format, context injection, examples, each demarcated with explicit structure — is a schema with named fields, and each field even has an empirically settled size: 50–150 tokens for persona, 200–600 for constraints, 200–2,000 for examples. Data architects will recognize the move instantly, because it's conceptual-logical-physical modeling replayed: decide what the sections mean, then how they compose, then how they're physically laid out in the window. The data world has already said this out loud — the AI-ready-data literature's core claim is that AI has a context problem, not an intelligence problem, and that chunking everything into a vector store is a RAG-era reflex, not a design.
Grain and ownership, under a budget
Grain is where the budget bites. Aider's RepoMap compresses an entire repository into a default 1,000-token map — tree-sitter symbols, ranked by PageRank centrality — because the right grain for "repository awareness" is signatures, not source. A well-built coding assistant then layers grains deliberately: repo map, then git diffs at roughly 20% of the available window, then full file content, with the diff budget shrinking as conversation history grows. Compression research makes grain explicit policy: compress instructions barely, few-shot examples moderately, retrieved documents aggressively. Every one of these is the same call a modeler makes choosing between a fact table and an aggregate.
Ownership and priority complete the parallel. The trust hierarchy — system prompt outranks user turn, which outranks retrieved content wrapped in tags marking it as data rather than instruction — is a permissions model on information. Position is physical design: models attend worst to the middle of long contexts ("lost in the middle"), so where a fact sits in the window is as consequential as whether it's there. Even cache economics mirror storage layout: ordering sections by stability, static preamble first, yields 60–80% token-cost reductions purely from layout — the same reasoning that puts hot columns together on disk.
If this all sounds like over-formalizing, look at what small schema decisions do to outcomes. GitHub Copilot's "neighboring tabs" — including content from the files you have open — lifted suggestion acceptance by 5% in A/B tests. Fill-in-the-Middle, a pure representation change, added 10%. Iterative retrieval adds 10%+ over single-pass. These are the margins schema designers have always fought for, won by deciding representation and grain deliberately instead of pasting everything and hoping. The vibes alternative fails the way undesigned databases fail: slowly, then suddenly, with nobody able to say which field is load-bearing.
The disanalogy is worth conceding. A database schema is static and enforced — the engine rejects violations. A context window is assembled fresh per request, and nothing enforces your design; it's closer to a query plan or a materialized view than a table, and the "engine" interpreting it changes with every model release, so the schema needs revalidating each time. But that weakens the analogy's comfort, not its instruction. When nothing enforces the schema, discipline has to live in the assembly pipeline — budgets, ordering, provenance, explicit loss functions for what gets compressed — or it doesn't live anywhere. The teams treating context as a modeled artifact are the ones whose agents behave the same way twice.