Most engineers who decide AI assistants "aren't ready" got there the same way. They opened a chat, typed a vague request into an empty context, got a mediocre answer, and drew a conclusion about the model. The model wasn't the variable. The context was.

Context engineering is the discipline of shaping what an assistant knows before it generates anything. It's the difference between a tool that produces mergeable changes and an expensive autocomplete. I've been doing it long enough now, across my own repos and a team codebase at work, to have opinions about what actually moves the needle.

Rule files are contracts, not notes

On this site, CLAUDE.md is a contract. It says which runtime to use, how the two git repositories relate, that Playwright runs in batches and never as one bulk process, that the prismatic gradient lives in exactly one CSS file, that transition: all is banned, and that a bug gets a written diagnosis before it gets a fix. When a new session starts, the assistant already knows all of that. I never paste it.

The important part is that the file changes when the code changes. When I moved the model configuration into its own module, the rule file was updated in the same commit. When I found that the batch runner was hiding failures, the rule about running tests got more specific. A rule file that lags the code is worse than no rule file, because the assistant trusts it.

At work the same idea lives as version-controlled Rules, Profiles, and Prompts that the whole team reviews. Different format, same contract.

Skills encode the steps people skip

Some parts of a good workflow are easy to state and hard to keep doing at the end of a long session. Those became Claude Code skills. /diagnose refuses to fix anything until there's a ranked hypothesis list. /implement-plan finds the existing plan and executes it instead of writing a fresh one. /audit runs a checklist over the diff before a commit. A skill is context that arrives at the right moment instead of sitting in a file hoping to be remembered.

Server-side context control

Context engineering isn't only about what the assistant sees during development. It's also about what the model sees at runtime in a shipped feature.

Every AI Lab app sends a promptKey, never a prompt. The server resolves the key to a system prompt the visitor can't read or override. Each stage of Problem Solver has its own key with its own contract and a version suffix. That structure is what lets me change a prompt without changing the behavior of sessions created under the old one, and it's the reason a public chat can run without anyone being able to rewrite its instructions.

Memory that persists across sessions

The newest layer is a memory directory: one file per fact, with a short index loaded into every session. Not code structure, which the repo already records, and not past fixes, which git records. The things that aren't derivable: decisions I've made about how work should be done, constraints that came from a conversation, pointers to resources outside the repo. It's the same principle as the rule file, scoped to what only a person would know.

Patterns that pay off immediately

Three habits account for most of the improvement I've seen.

Scope with non-goals. "Change the rate limiter's memory behavior. Do not touch the Firestore path." The second sentence prevents more damage than the first one causes.

Exit criteria before starting. What test passes when this is done? If I can't answer that, the task isn't specified yet.

Read the minimum. The assistant reads the function and its callers, not the directory. Broad reads become broad edits.

Why this beats model selection

I've watched a mid-tier model with a precise rule file and a tight scope out-deliver a top-tier model with neither. Model quality sets a ceiling. Context decides how close you get to it. And context is the part you control, on every task, for free.

Where it goes from here

I built Context First as a presentation on exactly this idea, first as a job application and then generalized: context over control, decisions written down, small teams trusted with the final call. It's the way I want to work with people, and it turns out to be the way I have to work with assistants. If a company has written down how it operates somewhere I can check, I can be effective there on day one. The same is true of a codebase.