How to Give AI Enough Context Without Wasting Tokens

Context Is a Budget

Every AI coding session spends a finite resource: the context window. Prompts, file reads, tool output, and the model's own reasoning all draw from the same pool. Once that pool is full, something gets dropped, and the model does not stop to tell you what it lost. It just keeps generating from an incomplete picture.

That is why "just give it the whole repository" is the most expensive instinct in AI-assisted development. It feels safe, because more information sounds better than less. In practice it is the opposite: the model's attention is spread across thousands of lines that are irrelevant to the task, and the specific conventions you actually needed it to follow are now a few tokens among many. Treat context like a budget, and the questions become concrete: what is the smallest amount of information that lets the model do this task correctly, and how do I deliver exactly that?

Token cost is not an abstraction. Providers bill by the token, latency grows with prompt size, and — more subtly — the model's ability to follow one specific instruction degrades as the window fills with competing material. A prompt that includes the entire solution spends most of its budget re-describing code the model does not need for the task at hand. The most reliable sessions are usually the leanest ones, not the most stuffed.

The Two Failure Modes

Context problems fail in two directions, and both produce bad code. Knowing which one you are fighting determines the fix.

The opposite failure is subtler. When you paste too much — the whole solution, a dozen files, a full specification document — the model does not necessarily fail loudly. It produces something that looks reasonable but misses the detail buried in the middle of the dump. You also pay for every one of those tokens, both in money and in latency, and you make the session harder to reason about. Dilution and cost are real failure modes, not theoretical ones.

Feature Folders as Context Units

The single most effective way to control context is to make the codebase's folder structure match the model's unit of work. In a Vertical Slice Architecture, one folder contains an entire feature: the controller, the CQRS handlers, the Minimal API endpoints, the Razor views, and the collocated .cshtml.js files. That means "read the Currency feature" is a complete instruction, not the beginning of a scavenger hunt across five projects.

Feature folders turn context from a pile of files into a navigable unit. The model can be pointed at one directory and told to follow the pattern it finds there. A person reviewing the change can read the same directory and see the whole feature in one place. And when the next feature is generated, the previous folder becomes the template — so the context you provide is not just smaller, it is more consistent.

A concrete measure: when a feature is self-contained, the starting context for "add the Asset feature following Currency" is one reference folder plus one rules section — a fraction of the token cost of loading five project directories. That saving compounds across every feature in the build, and, more importantly, the model never has to decide which of several competing examples to imitate.

Reference Implementations as Few-Shot Examples

Showing the model one good example is worth more than describing the rules three times. Instead of pasting scaffolding or writing an essay about your conventions, point the AI at a canonical slice and let it read the whole thing. The reference implementation does the teaching.

A practical set of references covers the three structural cases you will hit most often:

• Country — Pure Master. No foreign key, no child collection. This slice demonstrates the simplest complete shape: list, create, edit, delete, and the AutoNumber pattern.
• Currency — Master with Lookup. Carries a string {X}Id plus a {X}? {X} navigation, and shows how a lookup endpoint (/api/{entitylower}/{lookupentitylower}-lookup) and the corresponding dropdown are wired.
• Todo — Master-Detail. Exposes ICollection<T>? Items and shows how parent and child records are created, validated, and displayed together.

These three examples are enough to generate a new entity's eighteen-plus files — controller, handlers, endpoints, views, and scripts — because every new feature is a variation on one of the three. The model reads one reference in full rather than sampling twenty unrelated files, which is both cheaper and far more accurate.

Scoped Skill / Rules Files

A rules file is essential, but a giant rules file pasted into every prompt is its own kind of context dump. The standards need to live close to the work, and the model should load the relevant section rather than the whole document.

SKILL-SOFTWARE-ENGINEERING.md is the authoritative technical standard, and it covers a lot: entity type detection, AutoNumber via IHasAutoNumber, soft delete with a global query filter, mandatory CancellationToken on every handler and endpoint, FluentValidation over data annotations, and the collocated JavaScript path convention. Not every rule matters for every task. When you are adding a lookup, the validation rules and the endpoint naming rules matter; the AutoNumber format may not. Scoping the rules to the task keeps the signal high and the token cost low.

The same principle applies to .ai-assisted/DATA-DICTIONARY.md. Read the one feature entry you are building, with its Group, SubGroup, and Stage enum, instead of loading the entire dictionary. The declaration for Currency does not help the model build Asset.

Progressive Context Loading

The most efficient sessions start narrow and expand only on demand. Give the agent the task, the feature folder, and the one reference implementation that matches. If it needs more — a shared base class, the global query filter, the AutoNumber service — it can ask for that specific file. Each additional read is justified by a concrete need rather than supplied up front just in case.

This works because modern coding agents can pull context themselves. Your job is not to pre-load everything they might touch; it is to make the right context easy to find and to keep the starting point small. A well-organized feature folder makes that trivial, because every related file sits in one predictable place, and the agent can widen its search deliberately instead of drowning in a full-repository dump.

A Practical Context Recipe

A short checklist that keeps a session lean:

1. State the task in one sentence, using the entity name from the data dictionary.
2. Point at the target feature folder, not the whole solution.
3. Point at exactly one reference implementation that matches the entity type (Pure Master, Master with Lookup, or Master-Detail).
4. Load only the rules sections the task touches, not the entire skill file.
5. Let the agent request additional files by name if it needs them.
6. Verify with dotnet build at zero errors before moving on.

None of this requires a special tool. It requires a codebase whose shape makes the smallest complete slice obvious — which is exactly what feature folders and reference implementations provide.

Key Takeaways

• Context is a finite budget; spend it on the smallest complete slice, not the whole repo.
• Too little context causes hallucination; too much causes dilution and needless cost.
• One feature folder is the ideal context unit — complete, small, and reviewable.
• Point the model at Country, Currency, and Todo instead of describing your conventions.
• Scope the rules file and the data dictionary to the task, and let the agent load more only on demand.