Part of the Level 2 core path · Lesson 3 of 7
Pre-Load the Context
After this, you'll know how to arrange open files before you start completing, so the model has the types and patterns it needs to produce usable suggestions.
Before you start
Before diving in, complete Read Before Tab so you can immediately evaluate whether your pre-loaded context improved the completion quality.
The idea
Inline completion models do not read your whole project. They see the current file and a limited window of related files, usually the ones currently open in your editor tabs. Your architecture, your type definitions in other directories, your utility functions in other modules: none of that exists to the model unless you put it in the window.
- ContextStart with the task, constraints, and current state.
- Pre-Load the ContextApply the lesson move to the work.
- ProofKeep the result only when the check passes.
Here is the before and after: This has a concrete practical consequence. If you open a call site and start completing a function call without having the interface or type definition visible, the model will invent plausible-looking argument shapes. If you open the interface file first, then switch to the call site, the model has that type definition in its context window and will complete against your actual API, not an invented one.
The pre-load habit: before you complete at a call site, open the file that defines the type, interface, or function you are calling. Before you complete a database query, open the schema file. Before you complete a component's props, open the props type definition. One or two extra file opens, done before you start typing, change the quality of completions dramatically.
Try it (15 min)
Watch out for
- Completing against an interface you have not opened and trusting the result. The model will invent plausible argument names that do not match your actual API.
- Assuming the model knows your project because you have been in this codebase all day. Each completion is stateless. It sees only what is open.
- Opening the wrong version of a file. If you have a local override or a generated file next to a source file, open the one the editor will actually use.
- Pre-loading too many files at once. Two or three focused files beat ten loosely related ones. More open files means more noise in the context window.
- Forgetting that context windows reset on editor restart. Re-open your key files at the start of each session.
Paste this into Claude
I want to test pre-loading. Pick a real call site in your project where you need to call a function or use a type defined in another file. Do the completion twice: (1) Close all related files and complete from scratch. Note what the model generates. (2) Open the file that defines the function signature or type, then switch back to your call site and complete again. Note what the model generates this time. Paste both completions here and tell me: what changed? What did the model get wrong in the first attempt that it got right in the second?
What a good response looks like
Here is the side-by-side comparison for completing a `createUser` call site in your API service:
Without pre-load (no files open except the call site): The model completed with `createUser({ name: data.name, email: data.email, role: 'user' })`. It invented `role: 'user'` as a default, which is not a field on your `CreateUserDto`. It also missed the required `organizationId` field entirely. The completion would have compiled but thrown a runtime validation error.
With `user.dto.ts` and `user.service.ts` open first: The model completed with `createUser({ name: data.name, email: data.email, organizationId: data.organizationId, createdAt: new Date() })`. It used your actual DTO fields, included `organizationId`, and correctly added `createdAt` which it saw in the service definition.
What changed: opening `user.dto.ts` gave the model your exact field names. Opening `user.service.ts` showed it the full method signature including required fields. Two extra tabs open, zero invented fields.
For your project: before completing any DTO call site, open the DTO file first. Before completing any service method call, open the service interface. This is the pre-load rule for your specific stack.What good looks like
- You ran both completions (without and with the pre-loaded file) and compared the outputs
- The pre-loaded completion used your actual types or parameter names rather than invented ones
- You can describe in one sentence what file to open before completing at a specific kind of call site in your project
- You identified at least one case where the model invented a plausible but wrong argument in the no-context version
- You now have a consistent pre-load habit for at least one common completion pattern in your project
When this breaks
- Breaks when types are spread across many files with no obvious entry point, because pre-loading two or three related files cannot represent a deep dependency graph and the model still has to guess.
- Breaks when you flood the window with too many tabs, because more open files dilute the relevant signal and the completion regresses to generic patterns instead of locking onto your actual API.
AI can help with this
Describe what you are about to complete in chat and say: 'What files should I have open in my editor before I start completing here?' Claude will tell you exactly what to pre-load for your specific call site.
You can now
Run the same completion twice (once without and once with the relevant type file open) and demonstrate that the pre-loaded version uses your actual field names instead of invented ones.
Key takeaways
Open the type definition or interface file before you complete against it. One extra tab open, substantially better completions.
- Inline completion only sees the current file and a few open tabs, not your whole project
- Open the type, interface, or schema file before completing at the call site that uses it
- Two or three focused files beat ten loosely related ones; more tabs add noise, not signal
- Editor restarts reset the context window, so re-pre-load your key files each session