Context contamination is what wrecks AI coding
If you've used AI coding tools, you've probably had this experience. You wrote a clear set of requirements, yet the output is bizarre. It calls a function that doesn't exist, follows an old pattern instead of the approach you already switched to, or mimics the style of a completely unrelated file.
You didn't write a bad prompt. The information the AI referenced was contaminated.
The Vibe Mafia Club newsletter pinned down this problem under the name "context contamination." It's one of the most common reasons AI coding turns unreliable, yet most people fuss only over the prompt side and never give this any thought.
The problem is the reference files, not the prompt
An AI coding agent works in this order. It understands your requirements, searches for relevant files and instructions, and then starts implementing. The crucial part is step two. Before the AI writes any code, it digs through the files in your project to gather reference material.
If it references an irrelevant or poorly implemented file at this stage, that information contaminates the context. No matter how precisely you wrote your requirements, if the files the AI references have garbage mixed in, the result is contaminated too.
Data from Chroma Research puts numbers on this. When irrelevant information ends up in the context, output accuracy drops by roughly 10 percent. When incorrect information is included, it falls by more than 30 percent. The more complex the task and the more tokens it burns, the worse it gets — the drop can reach as much as 70 percent.
A bigger context window doesn't help. A large warehouse isn't the point; what matters is what's inside it.
First principle: give the AI a map
When an AI agent explores a codebase, it doesn't read every file. It searches for files that look relevant and goes to those. The problem is that this search isn't accurate. It often references the wrong files, or fails to find the ones it needs.
The fix is to document your folder structure. Create an AGENTS.md (or CLAUDE.md) file in the project root and write down the role of each major folder and how the files relate to one another.
This isn't a plain list of folders. You need relationship-level explanations, like "the components folder holds reusable UI components, which pages imports and uses." Just write down what you'd tell a new hire who asked, "How is this project structured?"
This document acts as a map for the AI. Just as wandering a city without a map sends you down the wrong alleys, an AI exploring a codebase without a structure document drags in irrelevant files.
Second principle: understand how the AI searches
Internally, an AI agent explores files through string search. It finds relevant files based on the words written in your prompt.
So you should use, verbatim, the same terms your actual code uses.
If you write "change what happens when the button is clicked," the AI searches with generic words like "button," "click," and "action." Plenty of unrelated files get pulled in along the way — there might be dozens of files in your project containing the word "button."
If you write "modify the onClick handler in the SubmitButton component," the AI hunts for files using the exact identifiers SubmitButton and onClick. The search narrows, the odds of an irrelevant file slipping in drop sharply, and it runs faster too.
Make a habit of naming variables, classes, functions, and files directly in your prompts. That alone changes the quality you feel. It's the easiest way to raise the AI's search accuracy.
Third principle: you must delete the code you no longer use
This is the principle most often broken in real-world projects.
What happens when unused files, commented-out old code, and code written against an old version of a library are left lying around in a project? The AI treats all of it as valid reference material. It generates code that follows outdated API patterns or calls functions that no longer exist.
One moment is especially dangerous: right after a major library update. If you bumped Next.js from 14 to 15 but the 14-style code is still in your project, the AI will, with high probability, follow the 14 approach — because it references whichever pattern appears more often in the project. The build breaks or you hit runtime errors, and you waste time fixing them.
"Let's keep it around, we might use it later" is the most expensive habit of the AI era. Your entire history is in Git. Code you aren't using right now should be deleted without hesitation.
Code that's good for humans is good for AI
To recap the three principles:
Document your folder structure to give the AI a map. Use your actual code terms in prompts to sharpen the AI's search accuracy. Delete unused code so there's no garbage for the AI to reference.
In the end, it all comes down to keeping the AI from getting lost and from stepping on bad information.
What's interesting is that these principles were good development practice long before AI. Documenting folder structure was always something you should do for onboarding new teammates. Clear naming was forever a point hammered home in code reviews. Deleting unused code was the basics of managing technical debt.
Adopting AI tools doesn't call for new rules. The rules you were supposed to follow all along have simply become more important in the AI era. A codebase that's easy for humans to read is easy for AI to read too. A codebase that confuses humans confuses AI too.
If you want to use AI well, tidy up your codebase before you dig into agent settings or prompt techniques. It's the simplest move, and the one with the biggest payoff.



