Teams spend a lot of energy on phrasing and very little on what the model actually has in front of it. The second one is where the results are.
What "context" means in practice
For a coding task it means: the relevant files, the types, the conventions document, the failing test, and the constraints. Not the whole repository — the relevant slice, chosen deliberately. A model given fifty files reasons worse than one given five of the right ones.
Curate, don't dump
- Include the module being changed and the one it most resembles.
- Include the type definitions and the schema. These are the contract.
- Include the test that must pass.
- Exclude generated files, lockfiles and vendor code — they consume attention and teach nothing.
Write the conventions down once
A short document describing how the codebase does error handling, naming, data access and testing pays for itself every time. It is also the artefact that helps human joiners fastest, which is a good sign it was worth writing.
If a new engineer would need the file to do the task well, the model needs it too. The reverse is also true.
Keep sessions short and scoped
Long, meandering sessions accumulate contradictions: an early decision that was reversed, a file that has since changed. We restart with a clean context per task and keep the durable knowledge in the repository, not in the conversation.
The measurable part
The two changes that moved our numbers were writing the conventions file and committing the failing test first. Neither is a prompting technique.