Last Tuesday, a senior engineer watched their AI assistant produce a fix that imported async_timeout in a Python codebase that had never heard of that package. The model was confident. It even left a comment explaining the import's timeout behavior. The engineer checked the repo. The file didn't exist. The AI had "remembered" it from a different project or, more likely, fabricated it from a training pattern.
The problem wasn't the model. It was context management. The assistant had been given the entire repository in its prompt: dozens of files, hundreds of functions, and a ten-thousand-line token budget. In that sea, one import statement looked like every other import statement. The model did what probabilistic models do. It produced the most statistically plausible token sequence, truth value be damned.
This is the setup for a 90-minute workshop that teaches a simple discipline called context budgeting. Participants build a small reviewer that sends only the files relevant to a change, then measure how much more accurate that reviewer becomes. The workshop uses MonkeyCode's free tier, which currently includes 10 million tokens and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free server is what makes the workshop viable for people without a Linux box under their desk; every command runs in the same remote environment that also powers MonkeyCode's free models. No GPU, no local inference, no six-hour CUDA installation.
The first ten minutes are setup. Each participant clones a sample repository containing one deliberately planted bug: a function called retry_fetch that imports async_timeout, a module that does not exist in the repo. The repo also contains three candidate files that look plausible, each with its own unrelated imports. The workshop provides a small CLI skeleton with a token counter, a file picker, and a wrapper function named call_reviewer that sends a prompt to a model endpoint. Participants run the CLI against the sample directory. The commands are simple: git clone, python review.py --mode baseline, and later python review.py --mode budgeted. That is the entire setup.
The next fifteen minutes are dedicated to the core concept. The token counter in review.py uses a rough heuristic. In practice, many teams use exact tokenizers, but a character-based estimate is enough for this workshop. The code is short.
def tokens(text):
return len(text) // 4
The point is not precision. The point is that every file appended to the prompt costs tokens, and the cost is roughly linear. Ten files at two thousand tokens each is twenty thousand tokens. Most free tiers will not blink at that number, but the model's attention blinks. It cannot attend to everything. When twenty thousand tokens are pasted in, the model's effective focus spreads thin, and the import that matters gets the same weight as the import that does not.
Exercise one takes twenty minutes. Participants run the baseline review. The CLI reads the entire repository, concatenates every file into a single prompt, and asks the model to find the bug. The output is predictable. The model identifies the missing async_timeout import, but it also flags two other files for issues that do not exist. It reports a memory leak in a file that already calls gc.collect(). It suggests a rename for a function that is only used in one place. These are false positives born of broad context.
Then the same review runs with a surgical context. The file picker in the CLI looks at the changed file, extracts its import lines, and selects only those files whose basenames match those imports. It also always includes the project's README.md as a minimal anchor. The prompt is now three files instead of ten. The model finds the missing import and nothing else. It takes half the time, and the token count drops to less than a third. The false positives disappear.
Exercise two takes twenty-five minutes. Participants replace the file picker with their own heuristic. The workshop provides a stub that currently returns the changed file and the README. The task is to extend it to parse from x import y statements and map them to matching local files. The sample contains a hidden wrinkle: the missing import is mentioned in old_legacy.py as a comment, not an actual import, and a naive picker might include that file. That is intentional. The exercise forces participants to inspect the imported symbol, not just the string, and to skip files where the symbol appears only in comments. By the end, the picker chooses one file: the one that defines retry_fetch and references async_timeout in a broken way.
The worked example takes fifteen minutes. Participants run the final reviewer on the fixed prompt and compare it with the baseline output. The results are stark. The baseline hallucinated two extra changes and one possible security issue. The budgeted reviewer returned a single line suggestion: remove the bogus import and use a retry helper from the standard library if available. That second suggestion is also questionable, but it is the kind of questionable you can verify quickly, because the prompt is small enough to read end to end. That is the real payoff. When context is small, every model output is auditable.
The last five minutes cover limitations. Context budgeting is not a panacea. It fails when the relevant file is not import-referenced, or when the codebase relies on dynamic dispatch and service locators where any file could be relevant. It also fails in monorepos where the changed line's dependencies are spread across hundreds of packages. For those cases, a proper index and retrieval system is needed, not a heuristic picker. There is a second limitation: the 10-million-token free tier is real but not unlimited. A class of thirty running multiple exercises will spend a meaningful portion of that allowance. It is still less than what a local run would cost in electricity, but it is not zero.
Who should not use this approach? Teams that work with protected health data or proprietary code that cannot leave their network should not send code to any external API, free or paid. Teams that need deterministic token accounting should replace the / 4 heuristic with a real tokenizer. Teams already using a retrieval-augmented review pipeline will see no benefit.
The workshop ends with a single assignment. Run the final reviewer on a small pull request from a real repo. Then cut the prompt to only the changed file and its imports. Measure the false positive rate for both runs. That number, more than any demo, will sell the idea. A bigger model is not required. A smaller context is. The free tier from MonkeyCode is enough to prove it, and the free server means the proof can be held from any machine with a browser.
Top comments (0)