The More Context You Give Your AI Coding Agent, the Worse It Can Get

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. The Assumption: More Context = Better AI 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: - 400 files - 12 architecture documents - 8 old incident reports - 3 outdated migration plans - 6 instruction files - 40 pages of logs - previous agent memory - the current task 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. Context Has Quality, Not Just Quantity Not all context is equally useful. Some context is: Relevant Some is: Outdated Some is: Conflicting Some is: Wrong Some is: 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. Example: The Old Architecture Doc 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. Stale Context Is Worse Than Missing Context 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. Conflicting Instructions Create Quiet Problems 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. Separate Permanent Context From Task Context I think teams should split context into two categories. Permanent Things that should almost always be true: - coding standards - architecture boundaries - security rules - naming conventions - ownership rules Task-specific Things relevant only to the current job: - one bug report - one feature requirement - one set of logs - one module - one incident Mixing both into one giant blob makes reasoning harder. Keep Permanent Rules Short 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. For example: text id="w7h7wu" - Business logic stays in services. - Repositories only handle persistence. - Do not add dependencies without approval. - Do not modify auth rules without explicit request. - Tests must cover changed behavior. Clear. Short. Hard to misinterpret. Context Should Have an Expiration Date Some context should not live forever. For example: - temporary migration rules - incident-specific workarounds - old feature flags - deprecated API behavior - one-off implementation notes 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. Make Sources Visible Another good habit: Do not let context appear as one anonymous blob. The agent should know where information came from. For example: 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. More Context Can Increase Hallucination Too 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. Context Is Part of the Architecture Now We usually think architecture means: - services - databases - queues - APIs - boundaries But in AI-assisted development, context becomes part of the system too. Because context influences: - what the agent believes - what it changes - which patterns it follows - which assumptions it preserves That means context needs engineering discipline too. A Simple Context Checklist Before giving an AI agent more information, ask: Is this relevant? If not, leave it out. Is this still true? If you are not sure, verify it. Does it conflict with another source? Resolve that first. Is there a newer source? Prefer the newer one. Does the agent need this now? Maybe later is better. Will this context still be valid next month? If not, do not treat it as permanent memory. My Preferred Workflow Instead of: 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. The Bigger Lesson 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. Final Thought 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. Top comments (0)