Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
🗓 Join our live research panel on September 24 as we introduce CAFE(S), a framework for improving AI agent effectiveness through better context. Register here.
Some of the most publicized AI failures of the last few years came from the legal profession. Lawyers have now been sanctioned, more than once, for filing briefs containing citations to cases that did not exist. It is tempting to blame these hallucinations entirely on model failure, but that offers an incomplete picture.
A brief was drafted, reviewed, and filed. Somewhere along that chain, an unsupported claim produced by a probabilistic language model became something a human was willing to represent as fact. The hallucination was the visible failure, but the root cause was the information environment surrounding the model.
A better model might hallucinate less often, but it won’t eliminate the need for the information and safeguards required to separate the plausible from the true.
That distinction is critical, and it’s showing up everywhere software gets built.
Picking up where the code left off
Recently, I wrote about what AI is doing to software quality, using a definition of quality that some colleagues and I developed back in 2020. The conclusion I landed on was that code is becoming a late place to look. More of what determines quality is settled before any code exists.
I ended that piece with five sentences that have stuck with me since:
Reuse requires knowing what already exists in the codebase. Review requires knowing what a change was meant to accomplish. Evolvability requires knowing why the system is structured the way it is. Handoff requires knowing what the previous person was thinking. Serving user needs requires knowing what problem the software was supposed to solve in the first place.
None of that knowledge necessarily lives in the code. It lives in tickets, design docs, runbooks, architecture decision records, and Slack threads. A fair amount of it lives nowhere at all except in somebody’s head.
When we hand a task to an agent, we hand over some representation of that knowledge with it. That representation is the context. And when context fails, it does not fail randomly, the same shapes keep recurring.
We have a vocabulary for this, just not for context
Software engineers have a rich language for recurring problems in code. Say code smell and everyone knows you mean something that isn’t a bug, but reliably signals trouble ahead. Long method. Feature envy. Shotgun surgery. Those names are useful precisely because they convert a vague unease into something you can point at in a review.
We have almost nothing equivalent for context when working with agents. When an agent produces something wrong, the diagnosis usually stops at “the model got confused,” which explains nothing and suggests no action.
So let me offer a starting vocabulary. Call them context smells. Here are six I keep running into. None of them are model limitations, and all of them survive a model upgrade.
Confident hallucination. The model asserts something untrue with exactly the fluency it uses for things that are true. We treat this as a model defect, and partly it is. But a model can only separate supported claims from unsupported ones if something in its context gives it a way to do that. The sanctioned lawyers weren’t undone by fabrication alone. They were undone by a workflow in which nothing downstream of the fabrication was designed to catch it.
Specification ambiguity. This is the one I find most underappreciated. Faced with an obviously underdetermined request, an agent will often stop and ask for clarification. Faced with a semi-ambiguous request, it does something considerably more dangerous. It picks an interpretation and proceeds. If that first read is wrong, every subsequent step compounds it, and the work looks confident the entire way down. Nothing was missing from the context. It simply admitted more than one reasonable reading, and nobody noticed which one got chosen.
Stale guidance. Context that accurately describes a system that no longer exists. The runbook that was correct two migrations ago. The architecture doc written before the service was split. A human reading these usually senses the mismatch and goes looking for why. An agent has no such reflex, and treats them as current.
Lost in the middle. More context is not reliably better. Model performance degrades as input grows, and it degrades unevenly, with material buried in the middle of a long context getting overlooked in favor of what sits at the edges. This one is genuinely counterintuitive, because nothing is missing. The agent has everything it needs and still fails, because the signal is competing with too much else for attention. Agents, like people, can get distracted.
Lost in the details. Context that supplies plenty of implementation detail and none of the reasoning behind it. The agent optimizes local mechanics beautifully while losing track of what the task was actually for. Margaret-Anne Storey calls the underlying condition intent debt, the gradual disappearance of recorded rationale from the artifacts a system leaves behind. It’s the difference between knowing that a timeout is set to 300 milliseconds and knowing whether that number came from a benchmark, a support incident, or somebody’s afternoon guess.
Weekend runaway. An agent given a task with no definition of success may never discover that it’s finished. So it retries, widens scope, and keeps exploring an objective that may not even be achievable. The result is consumed time, consumed tokens, and occasionally a genuinely startling bill on Monday morning. This may be the least intellectually interesting failure on the list, but maybe the one most likely to get a leader’s attention.
None of these are new
Read that list again and notice how little of it is actually about AI.
Ambiguous specifications have been the central concern of requirements engineering for decades. Documentation that drifts out of sync with the system it describes is one of the oldest complaints in software maintenance. Signal drowning in noise is the founding problem of information retrieval. Rationale vanishing from the artifacts a team leaves behind is what knowledge management has always been about.
None of these challenges are new. Bad context has always been a normal fact-of-life for software organizations. What kept it from being catastrophic is that humans quietly repaired it, constantly, without anyone noticing.
A new engineer handed an ambiguous ticket walks over and asks what it means. Handed a runbook that doesn’t match production, they notice the discrepancy and go find someone who knows. Handed two documents that contradict each other, they work out which one smells current, or they ask in a channel and get an answer in four minutes. Every organization I’ve studied runs on documentation that would fail inspection, and it works anyway, because a layer of human judgment sits between the bad context and the actual work.
Agents don’t reliably have that same repair loop, especially as we race to make them more autonomous. Handed the same ambiguous ticket, the same stale runbook, the same contradictory pair of documents, they proceed. Confidently, quickly, and at a scale that used to be impossible.
I don’t think AI created a context problem. I think it withdrew the error correction that had been hiding one. The information environment we’ve been tolerating was always this bad. If that’s right, it may also help explain one of DORA’s more interesting findings about AI adoption. Their 2025 research describes AI as an amplifier. It tends to magnify the strengths and weaknesses of the systems already surrounding agents. That’s usually framed as an organizational capability problem, but I wonder if part of it is an information problem. Teams with clearer specifications, better documentation, and more accessible organizational knowledge may simply have less damage for the human buffer to absorb in the first place.
What you can do
Most of what I’ve described sounds like it needs instrumentation we don’t have yet. It doesn’t (at least not to start).
Before handing a task to an agent, ask whether a competent new colleague could complete it with what you’re making available. Not a senior engineer who already knows your system. A capable person with no additional access to what’s in your head.
That test is deliberately low-tech, and it catches a surprising amount. The specification that admits two readings. The runbook describing last year’s architecture. The fifty-page dump with the one important constraint on page thirty-one. The task with no stated definition of done.
A competent new colleague would probably stop at each of those. Which interpretation did you mean? Is this runbook still current? Which of these fifty pages actually matters? What does done look like? Those questions are the human repair loop in action. The more autonomous we make agents, the less we should assume that loop will save bad context.
Naming these patterns is a start, but only a start. Context smells give us a vocabulary for recognizing trouble. They don’t give us a systematic way to evaluate the quality of context before an agent starts working. That second problem is considerably harder, and it’s where I’ve been spending most of my time lately. Over the coming weeks, I’ll be publishing a framework describing the dimensions of context quality, followed by an approach to measuring those dimensions.
For now, though, the question I’d put to any team frustrated with their agents isn’t which model they should be using.
It’s whether they’d have given the same task to a new hire and expected them to get it right.
That’s it for this week. Thanks for reading.
-Brian
This is bang on and why spec driven development works so well with agents. Give an agent a well specified task with clear expectations of architecture and the output is pleasing. A vague prompt without context just brings frustration. All that remains is verification, the other tricky problem!