Here is a pattern I have seen on multiple teams. First month of agent-assisted development: output is fast, patterns are consistent, the team is impressed. By month six: the agent is producing subtly wrong variations of patterns that worked at the start. Nothing catastrophic – just a slow drift. Decisions that don’t quite fit the architecture. Code that’s almost-right-but-not-quite. Reviews taking longer because something feels off but is hard to pin down.
The agent didn’t get worse. The context it’s working from did.
In the previous article I argued that vibe coding breaks because the agent makes locally reasonable choices on incomplete context, and those assumptions accumulate until the system stops cohering. The fix was decision ownership – the developer stays in the loop on intent, planning, and review.
But ownership actually starts earlier. Reviewing what the agent produced is half the job. Owning what it reads before it produces anything comes first – and it’s where the practice has to start.
This article diagnoses that side: what the agent assembles to work from, where each piece of it fails, and why those failures compound the longer the project runs.
How the agent builds its picture
Every session starts with a clean context. The token window is empty, and the working picture has to be reassembled from scratch – from whatever the agent can read in the moment.
That assembly happens in a specific order. It starts with your prompt – the goal you set. Then it pulls in configured context: project instructions, skills, accumulated memory, whatever your tool persists between sessions. Then it looks for documentation: READMEs, architectural notes, anything that explains intent. Only after that does it read implementation code, framed by everything collected so far. If something feels ambiguous enough, it may surface the questions. Then it decides it has enough to proceed.
That last step matters more than most people realize. The agent stops when it is *confident enough* to act, not when it is *fully informed*. The gaps it filled with guesses look identical in the output to the things it actually knew. A confidently wrong model is harder to catch than an obviously broken one – everything looks plausible until it isn’t. By the time you notice, multiple decisions have already been stacked on a flawed foundation.
Five sources feed that picture. Each one shapes the output. Each one fails in its own way.
The prompt
The prompt starts the session. It’s the only input the agent treats as ground truth – everything else gets read through it. Name the goal precisely and the agent assembles the rest of the context toward what’s relevant. Frame it wrong and the agent guesses – and that guess shapes every decision downstream.
Vagueness makes the agent guess. There’s a failure mode that’s harder to catch than that: not giving the agent room to push back. Specify an approach without asking for evaluation and the agent runs with it – no alternatives surfaced, no flaws flagged, no mention that it might not fit. State something you’re not sure of as fact and the agent reads everything it finds through that lens – rationalizing ambiguous evidence as consistent with your premise rather than stopping to question it. It’s trying to complete your task, not audit your assumptions. In both cases it works inside whatever you gave it, and it won’t tell you that’s what it’s doing.
The fix isn’t to avoid being specific – it’s to match the prompt to what you actually know. When you’re uncertain, describe the goal and ask for a recommendation: “I need request-level caching on the user lookup endpoint, scoped per tenant – what’s the right approach here?” When you know what you want, state the goal and the approach – but ask the agent to evaluate it: “I want to add caching using a Redis decorator on the service layer – does that fit, and is there a better option?” The second version gets you the implementation you’re thinking of plus any reasons not to do it.
Worth doing now: The agent needs explicit permission to push back. Without it, it won’t. Make that explicit in every non-trivial prompt.
Configured persistent context
Configured context is what the tool loads before the agent reads anything else: project instructions, custom rules, accumulated memory. Different tools call it different things – CLAUDE.md, Cursor rules, Copilot instructions. The role is the same: standing orders for this codebase, loaded before the agent has looked at a single file.
Done well, this is high leverage. A few hundred lines covering naming conventions, listing tools, marking the parts that need careful handling. Past decisions and established patterns carried forward – every session starts coherently framed without re-explaining the same context from scratch.
Done badly, it works in reverse – and it keeps doing so. Rules written eighteen months ago for a stack that’s been replaced. Memory entries from a confusion that got resolved but never cleaned up. Neither gets flagged as stale: both load every session, treated as authoritative, shaping everything the agent reads after. The longer it goes unchecked, the more sessions it has already framed incorrectly.
Some tools include an automatic memory feature on top of configured rules – if yours does, that layer has an extra problem. Unlike the instructions you write deliberately, it populates on its own. You didn’t choose what got saved and may not know what’s in it. Old entries don’t expire. It often captures the state of a confusion rather than its resolution: written when something was unclear, not after it got fixed. If you’ve never opened it, there’s a reasonable chance it has been working against you for longer than you think.
Worth doing now: Treat configured context like code. Review it on a schedule – your project instructions and, if your tool has one, the automatic memory file. Prune what’s no longer true. It takes fifteen minutes and it changes what every future session starts from.
Documentation
Documentation does something the other sources can’t: it explains the *why*. The reasoning behind decisions, the constraints that drove a specific design, the business rules that predate the code. This is what makes documentation uniquely valuable – and uniquely fragile. It fails in three distinct ways, and they’re worth separating.
The first is absence. Decisions get made in Slack threads, in meetings, in engineers’ heads – and never written down. As the team turns over, that knowledge leaves with the people who held it. The agent has nothing to fall back on except inference from the code, and the *why* is gone for good.
The second is maintenance drift. The system evolves, the docs don’t, and the gap widens with every unrecorded decision. A refactor, a pivot, a team handover – any of these can turn accurate-last-month docs into actively-misleading-today docs. This is worse than absence. Missing docs force inference from current code, which is at least grounded in current reality. Stale docs override that inference with confident misinformation the agent has no reason to question. And the gap doesn’t stabilize: eventually someone updates the docs against the current confused state and encodes that confusion as the record. The misinformation stops being a gap. It becomes authoritative.
The third is reachability. Docs that exist in Confluence, Notion, or Google Drive but aren’t accessible to the agent might as well not exist. The gap gets filled with inference, even though the answer was sitting in a wiki the whole time.
Worth doing now: If your documentation lives outside the codebase, list what exists and where in your project instructions file. If your tool supports MCP connectors for that system, the agent can fetch on demand – but it has to know to look.
The codebase
The codebase is the agent’s primary inference engine. It reads existing code to reconstruct patterns, naming conventions, module responsibilities, and the business rules implicitly encoded in implementation. Clean, consistent code gives reliable signal. Fragmented code gives noise that the agent has to pattern-match across.
Code is also the only source that captures current reality without translation. Docs can be stale, instructions can be wrong, but the code is the code. That’s the codebase’s strength and its limit. It shows the agent *what* the system does today. It cannot show *why* it was built that way, where it’s heading, or what edge case forced a specific design. Those answers have to come from somewhere else, or they don’t get included in the picture at all.
The agent’s output goes back into that pool. Code it writes today becomes part of what it reads tomorrow – treated as existing pattern, not as its own prior work. What you accept without review becomes signal; what you accept without understanding becomes noise. And noise compounds: a slightly-off implementation today becomes a template tomorrow. On a healthy project the loop runs in your favor – clean patterns stay clean. On a degrading one it accelerates, and the rate of decline tracks exactly how rigorously you review what gets merged.
Worth doing now: Don’t skip code review – but don’t do it line by line looking for bugs. Look for oddness: files that shouldn’t have been touched, changes that don’t fit the shape of what was asked, patterns you didn’t expect. When something feels off, stop and ask the agent for clarification before accepting. Oddness almost always means the agent misunderstood something, or your own picture of the system was incomplete. Either is worth fixing before the output becomes input.
Interactive clarification
When the tool supports a planning phase, the agent surfaces questions before it proceeds. The prompt lets you set intent before the agent reads anything; clarification lets you correct what the agent has already inferred. It’s the one point where you can see a specific assumption and catch it before it becomes code.
The catch is that you only see what the agent thought to ask. It surfaces what it noticed was ambiguous; everything it felt confident about gets folded into the plan silently. That selection bias is where the worst failures hide. The questions tend to be tactical – which library, how to handle an edge case. The structural assumptions – is this even the right architecture for what you’re building, is this module the right place for this responsibility – rarely become questions. The agent decides those quietly. You answer the small ones, the plan looks good, and you ratify it because you participated. Three weeks later you discover the foundation was wrong, and that wrong foundation has already become pattern in the codebase, read as the norm by every session since. Without a planning phase the problem isn’t gone, it’s invisible – the agent just makes those decisions and writes the code.
Worth doing now: When a plan lands, don’t just review the steps – ask the agent what it assumed to get there. *What are you uncertain about? What did you assume that could be wrong? Where are the tradeoffs?* Push for it. Don’t approve the plan until you understand the assumptions behind it and you’re comfortable with each one.
Why it gets worse over time
We’ve walked through the five sources and how each can fail in a single session. Two patterns sit on top of that, and together they’re what makes the drift chronic.
The first is that the sources don’t fail in isolation. Each one shapes what the agent does with the next. A vague prompt makes the wrong parts of configured context look relevant. Wrong configured rules bias how docs get read. Wrong docs frame how code gets interpreted. Wrong code inference shapes which assumptions become questions – or don’t. By the time the agent produces output, every step has been bounded by the quality of the step before it. A bad input doesn’t stay localized; it cascades through the rest of the picture.
The second is that the failure doesn’t stay inside the session it happened in. Three of the five sources persist between sessions – the codebase, documentation, and configured context – and what gets produced today becomes what gets read tomorrow. Code the agent writes goes back into the pool. Stale docs that didn’t get updated still don’t. Configured rules carry forward, including the ones that should have been pruned months ago. Each session starts with a slightly more degraded input than the one before, and the cascade above runs on it again, producing a slightly more degraded output.
This is why the drift is hard to catch in real time. There’s no single session where things visibly slipped. The agent reads context the way it always did, applies it the way it always did, produces output the way it always did. What changed – and what keeps changing, in the same direction, session by session – is what it’s reading.
Where to start
We’ve covered how the agent builds its picture, what each source contributes, and why the failures compound. The mechanics are clear enough now to talk about fixes.
There isn’t one place to fix. The agent reads from five sources, the failures cascade through every one, and the compounding runs through the artifacts that persist. Patching any single layer in isolation leaves the rest of the cascade running on the same inputs as before. Fixing this is a process, not a setting change.
Instructions and documentation are where to start. They’re what every session reads before it touches code, and what frames how the agent interprets everything that comes after. Get this layer right and every later phase – prompting, planning, review – has something stable to build on. Get it wrong, or skip it, and every later practice spends energy compensating.
You could argue prompts come first – they start every session, and a bad one poisons everything downstream. That’s true. But prompts are phase-specific. A planning prompt isn’t a review prompt, and a review prompt isn’t a refactor prompt. There’s no single “fix your prompts” practice – each phase defines its own. Prompts come up in every later piece, not in one of their own.
In the next article, I’ll cover how to structure instructions and documentation so the agent actually uses them, how to evaluate what you already have, and how to keep them in sync as the project moves – without turning it into a second job.