AI Agents Keep Losing the Plot on Your Codebase

There's a diagnostic failure mode that radiologists have a name for: satisfaction of search. You're reading a scan, you find one suspicious region, your brain registers "found it," and you stop looking. The other indicators—the ones that would have changed the diagnosis—go unread.

Peter Werry, co-founder of Unblocked, walked an AI Engineering conference audience through why this is also an exact description of what your coding agent does to your codebase. It finds something plausible. It stops. It builds on that. And if it found the wrong thing first, every subsequent step compounds the error.

The argument Werry makes in his talk is sharper than the usual "agents need more context" framing that's been making the rounds. His actual claim is that access to information and understanding are not the same thing—and that almost everything the industry is currently selling (bigger context windows, MCP connectors, wiki integrations) addresses the first problem while leaving the second untouched.

The new employee who never stops being new

The analogy Werry reaches for is a good one. Think of your coding agent as an expert software engineer who's perpetually on their first day. They're technically capable. They can read your code. But they don't know why that module is structured the way it is, what the team decided against six months ago in a Slack thread, or that the reason your deploy pipeline looks weird is because of a production incident in Q3 that left everyone gun-shy about a particular dependency.

"Agents are like new employees," Werry says. "They reset their knowledge every time you start a new task."

What's actually getting lost between tasks isn't code—it's organizational sediment. The intent behind architectural choices. Team conventions that exist because someone got burned. Past decisions that aren't documented anywhere except in the memory of three engineers who were in the room.

Before agents, a human engineer accumulated that sediment over time. They were, as Werry puts it, the context layer. The agent replaces them on tasks but can't replicate what they carried around in their heads.

Why throwing more tokens at it doesn't work

The obvious rebuttal is: fine, just give the agent everything. Dump the whole codebase, all the architecture docs, the Confluence wiki, into a million-token context window and let it reason over everything at once.

Werry's pushback on this is practical rather than theoretical. First, organizational context—the real stuff, not just code—doesn't fit even in a large window. Second, and this is the part that gets underappreciated, a bloated context window doesn't make agents smarter. It makes them distracted.

"When you're working on a task, you want task-specific flow," he says. "Your agents will get distracted easily if you give them things that cause them to look this way and that way."

The Unblocked blog makes a related point about MCP connectors specifically: giving an agent a connection to your data sources isn't the same as synthesizing that data into understanding relevant to the current task. A connector says "here's the door." A context engine says "here's what matters on the other side of it, for this specific thing you're doing right now."

This maps to a broader pattern in AI coding agent adoption: agents tend to underperform not because they lack raw capability, but because they lack the scaffolding that tells them what to ignore.

What a context engine actually does

Werry's demo showed the system answering a question about an internal component called the source mark engine. The response included an architecture diagram that didn't previously exist—generated from how the code actually operates, with sources attached so a human could verify or correct it. That "show your work" feature matters more than it might seem: it's the difference between a system you have to trust blindly and one you can audit.

The agent comparison was more instructive. Werry ran the same optimization task in Claude Code twice—once with Unblocked's context engine feeding it, once without. Without the context engine, the agent had to discover things on its own. Werry reported the cost at under a dollar and the run time at roughly a minute with context. Without it, roughly double the time and more cost—because the agent had to explore, found some things wrong, and later steps ran on bad assumptions.

But Werry was explicit that the headline numbers aren't the point. "The real value of a context engine is not the upfront cost on these short tasks. It's the compounding effect." An agent operating on a wrong assumption in step three doesn't just waste step three—it potentially invalidates steps four through eight and forces a loop. The divergence between "agent with good context" and "agent without it" widens on every multi-step task.

The review agent section of the demo illustrated a different dimension of this. Unblocked's system surfaces code review comments weighted by the commenter's seniority and expertise—essentially asking, "what would your senior engineers say here?" based on their actual historical comments. One engineer, Richie, saw the agent produce a comment and recognized it as something he himself would have said. Because it was: the system had surfaced a pattern from his previous reviews.

When the volume of flagged review issues dropped sharply, Richie debugged it with Unblocked and traced the drop to a Slack conversation about a model switch. The context engine connected the operational symptom back to the organizational decision that caused it. That's the kind of institutional memory that usually lives in one person's head until they leave.

The demo problem, and what to do about it

Werry ran his demo on Unblocked's own repository. That's the standard move—you demo what you know—but it's also where evaluation gets hard. A system that knows your codebase intimately will look impressive on your codebase. The question worth asking any vendor in this space: can you run the same demo on a repo you've never seen before, with someone from my team driving?

There's also a distinction worth pressing on: "we surface relevant context" and "we surface the right context for this task" sound similar but aren't. Relevant context is a recall problem. Right context is a judgment problem. A system that retrieves plausibly related information is useful. A system that synthesizes which of that information actually governs this specific task is what Werry is describing—and it's a harder bar to clear. Ask any vendor to show you their sources, and watch whether those sources actually explain the task at hand or just gesture at the general neighborhood.

Werry's case that context is the bottleneck in agent-driven development is broadly consistent with what practitioners are finding. Where it gets genuinely interesting is his argument about the shape of the failure: not that agents have insufficient access to information, but that they don't synthesize it into understanding the way a tenured engineer would. Human oversight remains load-bearing not just as a safety net, but as the thing that catches exactly the compounding errors Werry is describing—the ones that start small and ramify.

The two open-source tools Werry mentioned—a query engine that runs over your GitHub pull request history, and a social graph that visualizes review coverage by team—are worth a look if you want to probe the idea without committing to a product. Thin review coverage and knowledge silos are problems most engineering teams know they have and don't have great visibility into.

The practical test for any context engine, Unblocked's or anyone else's, is whether it shows its work. If a tool can surface a claim about your codebase or your team's practices and point you directly to the PR, the Slack thread, or the architecture doc that supports it, you can evaluate it. If it produces confident answers with no trail back to evidence, you're back to the satisfaction of search problem—except now it's your tool doing the stopping, not just the agent.

---

Rachel "Rach" Kovacs covers cybersecurity and digital safety for Buzzrag.