{"slug": "the-agentic-development-lifecycle-the-four-pillars", "title": "The Agentic Development Lifecycle - The Four Pillars", "summary": "A developer's analysis of AI coding agent context management cites a SWE-agent experiment in which showing a relevant file in a 100-line window yielded an 18.0% success rate, while showing the entire file dropped success to 12.7%. The writeup distinguishes context starvation from context dilution, notes that the two require opposite remedies, and recommends halving the context payload as a diagnostic when an agent performs poorly. It also references Chroma's Context Rot study of 18 models, which reported declining reliability as input length increased.", "body_md": "Why giving your AI coding agent more context can make it perform worse\n\nWhen an AI coding agent gets stuck, the instinct is usually to give it more context.\n\nMore files. More documentation. More conversation history. A longer CLAUDE.md or AGENTS.md. Maybe the entire repository.\n\nThe assumption is simple: if the agent knows more, it should make better decisions.\n\nBut experiments suggest otherwise.\n\nIn one SWE-agent experiment, showing the agent a relevant file in a 100-line window produced an 18.0% success rate. Showing the entire file dropped that to 12.7%.\n\nThe agent had more information. Its performance got worse.\n\nThis is one of the most important lessons in building reliable AI coding workflows:\n\nYour context window is a budget, not a bucket.\n\nThe goal isn't to give an agent as much information as possible. It's to give it the right information at the right time.\n\nShowing too little information can hurt performance. But showing everything can hurt, too.\n\nThis is not an argument for always using shorter prompts. It's an argument for being deliberate about what goes into them.\n\nContext has two failure modes\n\nWhen an agent performs poorly, context problems generally fall into two broad categories.\n\nContext starvation\n\nThe agent doesn't have enough information to complete the task.\n\nFor example:\n\n• It edits a function without seeing its callers.\n\n• It changes an API without seeing the expected response format.\n\n• It modifies a test without understanding the production behavior.\n\n• It follows a coding convention that the repository no longer uses.\n\nThe solution is to provide the missing information.\n\nContext dilution\n\nThe agent has the necessary information, but it is surrounded by so much unrelated material that the relevant details become harder to use.\n\nFor example:\n\n• A simple bug fix comes with the entire conversation history.\n\n• A small refactor includes documentation for unrelated modules.\n\n• A coding task begins with thousands of tokens of general instructions.\n\n• Tool output overwhelms the actual error or result the agent needs to inspect.\n\nThe solution is to remove noise and make relevant information easier to find.\n\nThese problems need opposite remedies. Adding more context may fix starvation while making dilution worse.\n\nA practical diagnostic\n\nWhen an agent produces a poor result, try a simple experiment:\n\nReduce the context payload by roughly half and rerun the task.\n\n• If performance improves or stays about the same, the original context may have contained unnecessary information.\n\n• If performance gets worse, the removed information may have been important.\n\nThis isn't a universal benchmark or a substitute for controlled evaluation. It's a useful debugging technique for understanding whether your agent needs more information or better information selection.\n\nBigger context windows don't eliminate the problem\n\nModel context windows have grown significantly. That makes it possible to include more code, documentation, tool output, and history in a single request.\n\nBut greater capacity doesn't guarantee that every additional token is useful.\n\nResearch into long-context behavior has documented limitations commonly described as the lost-in-the-middle effect: information can be harder to use when it appears in certain positions within a long input.\n\nChroma's Context Rot study examined 18 models and reported declining reliability as input length increased across several tasks. The study is useful evidence of the problem, although it comes from a company that sells vector database technology and should be considered alongside other evidence.\n\nThe practical takeaway is straightforward:\n\nA model's maximum context length is a capacity limit, not a recommended prompt size.\n\nThink of it like memory in a software system. Having more available memory doesn't mean every object should remain in memory forever. Good systems still manage what they load, retain, cache, and discard.\n\nThe same principle applies to AI agents.\n\nFour ways to manage context\n\nIf context is a budget, how should we spend it?\n\nThere are four useful techniques.\n\nA. Compact the context\n\nLong-running agents accumulate information:\n\n• Previous decisions\n\n• Intermediate reasoning summaries\n\n• Tool results\n\n• Failed attempts\n\n• Old instructions\n\n• Repeated descriptions of the task\n\nSome of that information is valuable. Some is no longer relevant.\n\nCompaction means preserving the important state while removing unnecessary detail.\n\nFor example, instead of retaining a long debugging conversation, keep a concise summary:\n\nTask:\n\nFix incorrect pagination in the customer API.\n\nFindings:\n\nFiles:\n\nNext step:\n\nAdd a regression test for page 2, then correct the offset calculation.\n\nThis gives the next model call a useful starting point without carrying every previous interaction forward.\n\nThe key is to preserve facts, decisions, constraints, and next steps—not every detail of the journey.\n\nB. Offload large tool outputs\n\nTools can return far more information than an agent needs.\n\nA repository search might return hundreds of matches. A test command might produce thousands of lines. A log file might contain one useful error buried in repetitive output.\n\nInstead of inserting everything into the model's context, keep the full output outside the conversation and expose a smaller, relevant result.\n\nFor example:\n\nTest suite: 248 tests\n\nPassed: 247\n\nFailed: 1\n\nFailing test:\n\ntests/customers.test.ts::pagination_returns_second_page\n\nRelevant error:\n\nExpected customer ID 21, received customer ID 1.\n\nIf the agent needs more detail, it can fetch the relevant section.\n\nThis is the principle behind tool-output offloading: store the full result, but bring only the necessary portion into context.\n\nC. Use progressive disclosure\n\nDon't load every instruction, document, or tool description at the beginning of every task.\n\nStart with a small amount of general guidance. Let the agent discover more specific information when the task requires it.\n\nFor example, a repository might contain:\n\nAGENTS.md\n\ndocs/\n\n  architecture.md\n\n  testing.md\n\n  deployment.md\n\n  database.md\n\nThe root AGENTS.md can explain the project's structure and point the agent toward specialized documents.\n\nA database task can load database.md. A deployment task can load deployment.md.\n\nThis keeps the initial context focused while making deeper information available on demand.\n\nThe distinction matters: good context engineering doesn't mean hiding information forever. It means avoiding unnecessary information before it becomes relevant.\n\nD. Reset the context when the task changes\n\nLong-running conversations can accumulate outdated assumptions, completed work, failed experiments, and irrelevant details.\n\nSometimes summarizing the existing conversation isn't enough. Starting a fresh model call with a concise handoff is cleaner.\n\nThink of an engineer handing work to a teammate at the end of a shift.\n\nThe handoff should include:\n\n• What has been completed\n\n• What remains unresolved\n\n• Which files have changed\n\n• What has been tested\n\n• Which decisions must not be revisited\n\n• What the next step should be\n\nThe new agent doesn't need the entire history. It needs the current state of the work.\n\nReset the conversation, not the project's knowledge.\n\nKeep durable information in files, tests, issue descriptions, and other artifacts that survive the context reset.\n\nThe takeaway\n\nA bigger context window gives your agent more room. It doesn't automatically give the agent better judgment.\n\nReliable agentic development requires deliberate choices about what enters the context, what stays outside it, what gets retrieved on demand, and when the agent should start fresh.\n\nDon't ask how much context your agent can hold. Ask which information deserves to be there.\n\nHow long is your CLAUDE.md or AGENTS.md today—and when was the last time a human actually edited it?\n\nThis post is based on Chapter 6 of The Agentic Development Lifecycle.\n\nRead the full chapter: Context Engineering — The Budget, Not the Bucket", "url": "https://wpnews.pro/news/the-agentic-development-lifecycle-the-four-pillars", "canonical_source": "https://dev.to/praveen_govi_ai/the-agentic-development-lifecycle-the-four-pillars-1a00", "published_at": "2026-10-27 17:34:08+00:00", "updated_at": "2026-10-27 17:42:40.319846+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-research"], "entities": ["SWE-agent", "Chroma"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-agentic-development-lifecycle-the-four-pillars", "markdown": "https://wpnews.pro/news/the-agentic-development-lifecycle-the-four-pillars.md", "text": "https://wpnews.pro/news/the-agentic-development-lifecycle-the-four-pillars.txt", "jsonld": "https://wpnews.pro/news/the-agentic-development-lifecycle-the-four-pillars.jsonld"}}