The context an agent does not have and will not ask for

A principal engineer at a payments company told me about a change an agent made that looked like an improvement and caused an outage. There was a piece of code that handled a payment edge case in a way that looked wrong, an odd workaround with a cryptic comment. It was there for a real reason, a quirk in a downstream provider that would fail in a specific, painful way if you did the obvious thing. An engineer asked the agent to clean up the surrounding code, the agent saw the odd workaround, concluded it was a mistake, and removed it, replacing it with the clean, obvious version. A human teammate would have looked at that strange code and asked why it was there. The agent did not ask. It assumed, acted, and undid a decision the team had paid for in a past incident.

Codebases carry context that is not written down

Every real codebase is full of decisions that look wrong until you know why they were made. The strange workaround for a broken dependency. The seemingly redundant check that exists because of a bug that took a week to find. The unusual structure that accommodates a constraint from three systems over. This context is often not written in the code, it lives in the team’s memory, in the story of the incident that led to it, in the tribal knowledge that a new human teammate absorbs over time by asking questions. When a person sees code that looks wrong, their instinct, if they are any good, is to ask why before they change it, because they have learned that odd code often encodes a reason they do not yet know.

An agent has the code and not the context, and crucially, it does not ask. It sees the strange workaround, applies its general knowledge of what good code looks like, concludes the workaround is a mistake, and confidently fixes it, undoing the deliberate decision along with the reason it existed. It has no memory of the incident that caused the workaround, no awareness that the obvious version was tried and failed, and no instinct to ask the team why the code is shaped the way it is. It treats the codebase as if its current state were an accident to be improved, rather than the accumulated result of decisions, some of which look wrong precisely because they solved a problem that is not visible in the code. The missing context is invisible to the agent, and the agent’s confidence means it acts on the absence instead of noticing it.

This is a different risk from the agent writing buggy new code. Here the agent breaks working code by removing the parts it does not understand the reason for, and it does so while looking like it is cleaning up. The change reads as an improvement, it passes review if the reviewer also lacks the context, and it undoes hard-won knowledge that the team can only recover by having the incident again.

Supply the context or protect the decision

The lesson is that agents lack the undocumented context behind a codebase and will not ask for it, so the team has to either supply that context or protect the decisions that depend on it. The agent’s willingness to confidently change what it does not understand is the hazard to design against.

What teams do to keep agents from undoing hard-won decisions.

Document the why behind non-obvious code, so the reason a workaround exists is visible to an agent that will never ask.
Mark deliberate decisions that look wrong, so an agent, and a reviewer, know to leave them alone or ask before changing.
Review agent changes against the team’s context, so someone who knows why the odd code exists catches its removal.
Be cautious handing agents cleanup tasks on code with history, since cleanup is where they most confidently undo decisions.
Keep the tribal knowledge somewhere the agent can see, since an agent cannot absorb it the way a human teammate does over time.

The agent will improve code toward what looks right, and some of your code looks wrong for reasons it cannot see and will not ask about. Those reasons have to be made visible or protected.

How we approach it at Density Labs

The agent that removes a workaround it does not understand is a specific and dangerous pattern, because it wears the disguise of an improvement. The agent lacks the context that a human teammate would have sought by asking, and it does not ask, so it acts on its confident but incomplete picture and undoes decisions the team paid for in past pain. The change looks like cleanup, which is what makes it slip through.

Our AI Opportunity Assessment is a fixed two-week engagement, priced at $2,500, that scopes the real work of shipping AI-assisted, including how agents interact with a codebase that carries undocumented history. Part of that is making the why behind non-obvious decisions visible, so an agent that will never ask cannot confidently undo them.

A good teammate asks why the strange code is there before changing it. The agent will not ask, so the why has to be written down or the code has to be protected.