# The More Context You Give Your AI Coding Agent, the Worse It Can Get > Source: > Published: 2026-10-03 03:52:59+00:00 We keep hearing the same advice: **Give the AI more context.** Add the README. Add `AGENTS.md`. Add architecture docs. Add logs. Add previous decisions. Add the whole repository. Add memory from previous sessions. Sounds reasonable. But there is a problem: **More context does not always mean better understanding.** Sometimes it means more noise. More stale assumptions. More conflicting instructions. More irrelevant files. And more chances for the agent to focus on the wrong thing. That is the part I think developers need to pay more attention to. It makes sense at first. If the agent knows more about the codebase, it should make better decisions. Right? Sometimes. But imagine giving a developer: and then asking: “Fix this bug.” That is not automatically helpful. That is a lot of information to sort through. The same problem can happen with AI agents. Not all context is equally useful. Some context is: **Relevant** Some is: **Outdated** **Conflicting** **Wrong** **Technically correct but irrelevant to the current task** If you give all of it equal weight, the agent has to figure out what matters. And that is where mistakes start. Suppose your current system uses: ``` text id="ixn1f3" Controller ↓ Service ↓ Repository ``` But an old architecture document still says: ``` text id="8ylsl1" Controller ↓ Data Layer ``` You ask the agent to add a feature. Now the agent has two sources of truth. Which one should it trust? Maybe it follows the code. Maybe it follows the documentation. Maybe it blends both. And now you get a new pattern that never existed before. The problem was not lack of context. The problem was **bad context hygiene**. Missing context usually creates uncertainty. Stale context can create confidence in the wrong direction. That is more dangerous. For example: Three months ago: “All payments go through Provider A.” Today: Half the system has moved to Provider B. But the agent still carries the old rule in memory. Now it confidently implements the wrong integration. That is why persistent memory can be useful and dangerous at the same time. Imagine the agent reads: ``` text id="hp3on9" AGENTS.md: Use service classes for all business logic. ``` Then another file says: ``` text id="x68ti8" README: Keep business logic inside route handlers. ``` Then an old task note says: ``` text id="14479z" Avoid adding new service layers. ``` All three may have been correct at different times. Now they coexist. The agent has to resolve the conflict. That is not a safe default. --- # More Tokens Do Not Mean More Attention This is another important point. A bigger context window gives the agent access to more information. It does not guarantee equal attention to every piece of information. If you include: - hundreds of files - long logs - old discussions - huge docs the important detail may become harder to surface. The real problem becomes: > **Can the agent find the right context at the right moment?** That is different from: > **Can the agent fit everything into the prompt?** --- # The Goal Should Not Be Maximum Context I think the better goal is: > **Minimum sufficient context.** Give the agent enough information to make the right decision. Not everything you have. For example, if the task is: > “Fix a validation bug in checkout.” The agent probably needs: - checkout flow - validation rules - related tests - relevant data model - current architecture constraints It probably does not need: - email service docs - analytics history - unrelated migration logs - old design discussions - every frontend component More is not automatically better. --- # Use Progressive Context A better pattern is: ``` text id="k7ov9i" Start small ↓ Give relevant files ↓ Let the agent inspect ↓ Add more only when needed ``` Instead of: ``` text id="dxypv0" Dump everything ↓ Hope the agent finds what matters ``` This is basically progressive disclosure for coding agents. Let the agent earn more context as the task requires it. --- # Ask the Agent What It Needs This is surprisingly useful. Instead of giving the whole repo immediately, ask: ``` text id="wd8gzg" Before changing anything: 1. What information do you need? 2. Which files are likely relevant? 3. What assumptions are you currently making? 4. What context would reduce uncertainty? ``` Now the agent tells you what it is missing. That is much better than blindly adding more. I think teams should split context into two categories. Things that should almost always be true: Things relevant only to the current job: Mixing both into one giant blob makes reasoning harder. This is important. Your agent instructions should not become a novel. If your `AGENTS.md` is 5,000 lines long, developers probably do not read it carefully either. The best permanent rules are usually simple. ``` text id="w7h7wu" Clear. Short. Hard to misinterpret. Some context should not live forever. If the agent can remember something forever, someone needs to decide when that memory stops being valid. This is why I think agent memory needs something humans already understand: **Lifecycle management.** Context should be: **created** **reviewed** **updated** **expired** **deleted** Just like code and documentation. Another good habit: Do not let context appear as one anonymous blob. The agent should know where information came from. ``` text id="l6tqad" Source: current code Source: AGENTS.md Source: architecture decision record Source: incident from June Source: previous agent memory ``` Why? Because source matters. Current production code should probably outweigh a two-year-old planning document. Without provenance, everything can look equally trustworthy. --- # Ask the Agent to Surface Conflicts Before implementation, try: ``` text id="gprxfr" Review the available context. Identify: - conflicting instructions - outdated assumptions - duplicated rules - unclear sources of truth - anything that may no longer be valid Do not change code yet. ``` This is a very useful step for large codebases. You want context conflicts visible before they become code. This sounds backwards. But imagine the agent sees 10 partial references to a system behavior. None gives the complete picture. It may combine them into a plausible explanation. That explanation can sound very confident. And still be wrong. The issue is not always missing information. Sometimes it is **too many incomplete signals**. We usually think architecture means: But in AI-assisted development, context becomes part of the system too. Because context influences: That means context needs engineering discipline too. Before giving an AI agent more information, ask: If not, leave it out. If you are not sure, verify it. Resolve that first. Prefer the newer one. Maybe later is better. If not, do not treat it as permanent memory. ``` text id="5axqqf" Load entire repo ↓ Load all docs ↓ Load memory ↓ Ask agent to work ``` I prefer: ``` text id="d6w46d" Define task ↓ Give core constraints ↓ Agent identifies needed context ↓ Load only relevant files ↓ Check for conflicts ↓ Implement ↓ Verify ``` The difference is simple: **Context becomes intentional.** AI coding agents do not just need more information. They need: **the right information** **from the right source** **at the right time** That is a much harder problem. But it is also where developers can add real value. We keep trying to make AI coding agents smarter by giving them more context. Sometimes that works. Sometimes it makes things worse. Because: **More context can mean more noise.** **More memory can mean more stale assumptions.** **More instructions can mean more conflicts.** The goal should not be: **Give the agent everything.** The goal should be: **Give the agent exactly what it needs to make the right decision.** Because the best context window is not the biggest one. It is the one with the **least irrelevant information and the clearest source of truth**.