I keep hearing some version of the same complaint. It still produces slop. My job is clearly safe for a while longer. It couldn’t handle the simplest request. Some days it just seems… off.
The easy conclusion is that the model isn’t good enough yet. A better one is coming, and it’ll finally get out of its own way. I don’t think that’s what’s happening, at least not most of the time. I think a lot of this is an AI agent communication problem wearing a capability costume.
The Obvious Thing Is Never the Obvious Thing to Say
Specifying software intent is hard, and it’s hard for a specific, boring reason: stating the obvious doesn’t feel natural. It feels like wasted breath to say something that seems self-evident to the person asking. Worse, “obvious” is personal. After enough time inside a problem, the assumptions and half-made decisions along the way stop registering as information at all. They just become “how things are.”
The AI agent never took that journey. It didn’t sit with the problem, rule out three other approaches, or absorb the constraints nobody wrote down because nobody had to. All it has is what made it into the request. Every unstated assumption is a small gap, and small gaps compound. That compounding is what produces slop. The bridge is just shorter than it needed to be. The model was never the weak link.
This Already Has a Name: Curse of Knowledge and the Illusion of Explanatory Depth
It turns out psychology already has vocabulary for exactly this, and it didn’t need AI to discover it.
The first is the curse of knowledge, a bias where deep expertise makes it genuinely hard to imagine what it’s like not to know what you know, so you skip context a less-informed listener needs. There is a classic demonstration from a Stanford experiment in 1990. People tapped out the rhythm of a well-known song and predicted that half their listeners would recognize it. In reality, only 2.5% did. The tapper couldn’t help hearing the song in their own head and overestimated how much of it was actually conveyed. Chip and Dan Heath describe a version of this in Made to Stick. In their telling, becoming an expert means becoming more fascinated by nuance, and that is exactly when you start forgetting what it is like not to know what you know.
Requirements-gathering work documents this directly too. Analysts and PMs under the curse of knowledge unintentionally assume the client already understands technical concepts. They skip clarifying questions and interpret vague statements through their own mental model. The result is false alignment, where everyone believes they agree and nobody does.
The second is the illusion of explanatory depth. This is the belief that you’ve understood something more thoroughly than you have. It’s usually invisible until someone has to explain the thing in full, and the gaps in their own account show up for the first time.
Neither of these needed a chatbot to exist. They’re just newly visible, and together, they’re most of what people mean by an AI agent communication problem.
We’ve Been Doing This to Each Other All Along
Picture an expert briefing a colleague on a piece of work. It feels complete, clear, thorough, nothing left out. The colleague comes back with questions anyway, sometimes several rounds of them. The expert isn’t being careless. They just have more history in the area. They know which pitfalls to avoid and carry around a set of hidden processes, so internalized they no longer register as things that need to be said out loud. The curse of knowledge doesn’t feel like a flaw from the inside. It feels like common sense.
Now flip the seats. The same person, now on the other side of the table, working with a client. The client hands over what feels like an exhaustive brief. Both sides walk away believing they’d thoroughly drilled down the requirements. But the client assumed the team already understood certain edge cases, because from where they were sitting, those cases seemed self-evident. The team never even learns those edge cases exist. Nobody had a reason to say them out loud. That’s the illusion of explanatory depth, live.
In both directions, nobody has bad intentions. Both sides want the same outcome. The failure is that communication across two different vantage points is hard in a way that doesn’t announce itself while it’s happening.
Working with an AI agent surfaces a third instance of the exact same pattern, not a new failure mode the technology invented. Call it the AI agent communication problem. A person is simultaneously the expert colleague, holding tacit project history the agent never lived through, and the client, believing their own prompt was more complete than it was, until the output exposes the gap. The fix professionals already use for the human version of this problem is the same fix that works here. Treat your own ignorance as a tool. Ask naive and discovery-oriented questions instead of leading ones. Surface assumptions explicitly and clarify progressively instead of trying to deliver a complete brief in one pass.
The Fix for the AI Agent Communication Problem Has a Name
It’s called dialog. Crucial Conversations: Tools for Talking When Stakes Are High, by Patterson, Grenny, McMillan, and Switzler, defines dialog as the free flow of meaning between two or more people. That flow builds what the book calls a “pool of shared meaning”: the combined facts, feelings, and assumptions each party is holding, made visible to everyone in the exchange. The bigger and more shared that pool gets, the better and faster the resulting decisions, because more of what any one person knows is now available to all of them.
The book contrasts real dialog with two default failure modes people fall into when a conversation feels risky or like more effort than it’s worth. The first is silence — staying vague, understating, withholding what you actually mean. The second is violence — forcing your view through unilaterally, without checking whether the other person shares it. Neither adds anything to the pool. Both feel efficient in the moment and cost more later.
Mapping Silence, Violence, and Dialog onto AI Prompting
Map that directly onto how most people “talk” to an AI agent today:
| Mode | What it looks like with an agent | Effect on the pool of shared meaning |
|---|---|---|
| Silence | The vague, under-specified prompt — “add error handling,” “clean this up” | The obvious goes unsaid because it never registered as information worth stating |
| Violence | The exhaustive, one-shot brief — every requirement dumped in a single pass | Feels thorough, but it’s one-directional. No room left for the agent to surface what it doesn’t know |
| Dialog | Back-and-forth — the agent asks what it doesn’t know, the human clarifies what they’d assumed was obvious | Builds an actual shared pool of meaning before anyone commits to output |
Real dialog isn’t just the human clarifying for the agent’s benefit. It includes letting the agent take its own journey of discovery (asking questions, investigating, iteratively building up its own understanding) instead of expecting either side to show up with the full picture already assembled. That back-and-forth is the whole mechanism. It’s not a nice-to-have layered on top of “real” prompting. It is the fix.
What This Looks Like in Practice
I once needed to extend a configuration system to support a new set of values, in a piece of work that was partially built already and sitting safely behind a feature toggle. Asked to just implement the extension, the agent did exactly that. It widened the set of allowed selections and wired the new values through to the backend. The unit tests passed. The system-level tests didn’t — and neither of us yet knew why.
The second time, I asked differently. I told it to explore the area first and understand what already exists before then coming back with a plan for how the new requirement fits. That was enough. The agent’s own exploration surfaced something neither of us had gone looking for the first time: a completely different, tangential handler that was allowlisting configuration values based on that same feature toggle. Nobody had mentioned it, because nobody (including me) knew it was there. The plan that came back included updating it, and the fix landed correctly the first time. It was the same requirement, same codebase, and same agent. The only thing that changed between the two sessions was whether it was invited to look before being told to build. That’s become my default now. For anything touching more than a couple of files, explore first, build second.
The Industry Is Already Converging on This
If parts of this sound obvious in hindsight, that’s because they already are, in scattered form, and yet the same complaints about slop keep circulating anyway. That’s the more interesting problem. The fix for the AI agent communication problem already exists, distributed across different names and different corners of the industry, but rarely connected into one plain habit anyone can carry into their next prompt. That back-and-forth is where the field’s own vocabulary has been heading too, even in places that never use the word ‘dialog.’ It goes well beyond anyone’s personal preference for how to prompt well.
Anthropic has been writing about “context engineering” as the successor to prompt engineering, saying it is less about finding the right words, and more about answering what configuration of context is likely to produce the behavior you want. They name the exact failure mode described above almost word for word, calling it guidance that “falsely assumes shared context.” That’s the curse of knowledge, in engineering language. GitHub has made a similar case. The fix means giving an agent persistent, structural ways to receive background information, so re-typing it every session isn’t necessary. Cleverer one-off phrasing was never the point.
The Catch: Over-Specifying Is Its Own Failure Mode
There’s a matching warning worth taking seriously: over-specifying is its own failure mode, just as real as under-specifying. Anthropic describes engineers hardcoding brittle logic into prompts at one extreme and vague, high-level guidance at the other, with the useful zone sitting in between. Context is a finite, attention-degrading resource. Front-loading every possible detail just trades one failure (missing context) for another (diluted signal, buried priorities). Dialog isn’t free either. Every round of clarification spends the same limited attention budget. The point was never that dialog is costless. It’s that it spends that budget far more efficiently than either silence or violence do.
A Document Written Once Can’t Keep a Promise Forever
Context engineering named the failure mode and pushed for structural, persistent ways for an agent to receive context — not necessarily freezing that context into a single file and calling it finished. That further step is one people often take on their own anyway, and it’s exactly what deserves a closer look. If dialog spends a limited attention budget, why not skip the ongoing cost and just write one really good context file instead? It’s a tempting instinct… write the perfect instructions file, capture everything the agent needs to know, done.
That works fine for stable, narrow facts. It works much worse for anything about the system itself. Complex, long-lived projects aren’t static. Requirements evolve, and change requests arrive that nobody anticipated at design time. The human doesn’t know the system’s future any better than the agent does. Nobody is withholding information; it simply doesn’t exist yet. Dialog is the only mechanism that stays synchronized with a system as it changes, because it happens the moment new information exists, not months earlier when a document was written.
Software Already Learned This Lesson
None of this is new to software either. The Agile Manifesto made the same case for working software over comprehensive documentation decades before agents existed.
One recent benchmark makes the point concretely: a 2026 ETH Zurich study tested coding agents against repositories with and without context files like AGENTS.md, and found automatically generated files actively hurt success rates (roughly 3% worse) while increasing inference costs over 20%. Even carefully hand-written files only produced a marginal 4% gain (summarized here, based on the original paper).
In this study, static documentation wasn’t a reliable win even at its best. Agents turned out to be too obedient to whatever a file said, following stale instructions instead of catching that they no longer matched reality. The reasoning held up fine. The information didn’t. The agent wasn’t there when the fact changed, so it had no way to know the file was wrong. That’s the same communication gap showing up as blind trust instead of a blind spot. What held up was a small, deliberately curated set of non-obvious, slow-changing facts, not comprehensive documentation.
People forget to say the obvious, but that’s only part of it. Some of what an agent needs is genuinely unknowable in advance, on any system complex enough to keep changing. Static artifacts can only ever encode what was true and known the day they were written. Dialog is what keeps pace with what’s true now. Call it the AI agent communication problem again, just wearing a documentation costume this time.
The Industry’s Structural Answer
So if a single static document can’t carry that weight, and ongoing dialog is what actually works, what does that look like as a real process instead of just a good attitude? A growing part of the industry has started building formal structure around exactly this idea, usually under the name spec-driven development. Instead of treating a short problem description as the green light to start coding, it makes clarifying that description its own explicit phase, done before any code gets written and revisited whenever requirements shift. That phase happens thoroughly, through back-and-forth, with assumptions surfaced and edge cases raised.
GitHub’s own Spec Kit is a concrete example of what that looks like in practice, and it says the idea outright: define what to build before building it. Its workflow moves from specifying what and why into a step it names directly as “clarify” before any planning happens. Later, it includes a checklist step described as “unit tests for English.” That’s a direct acknowledgment that the specification itself needs verifying too, alongside the code that comes out of it.
That’s exactly the shape the second attempt at the configuration fix took, even without a formal name for it at the time: explore first, surface what’s actually there, form a plan, then build.
Full tooling like this is real overhead, and it isn’t always warranted. Plenty of work is a small change that doesn’t need a formal spec process. But the underlying shape still works as a default habit, with none of the tooling. Solve the problem in English first, through dialog, before ever asking for code. Over time, this becomes the normal shape the work takes, rather than a gate you have to remember to open.
What AI Is Actually Good At
All of this reframes what dialog is actually for. An agent can’t know your project’s requirements, its edge cases, or the domain rules that feel obvious to your team, because it was never trained on your specific system. It has no way to be. What it’s genuinely, remarkably good at is translation. Andrej Karpathy said it plainly back in 2023: the hottest new programming language is English.
None of this claims a model never hits a real ceiling. Sometimes a problem genuinely exceeds what a given model can reason through correctly, no matter how well it’s briefed. I can’t tell you what fraction of “slop” is that versus a communication gap, and I don’t think anyone honestly can yet. What I can say is that communication is the lever available to pull, today, on every project, regardless of where that ratio sits, and in practice, it’s the one most people haven’t tried pulling yet.
The highest-leverage use of an agent isn’t handing it a problem it doesn’t have the information to solve. It’s working with it, in plain language, to pin down the requirements, the boundaries, and the plan, and only then asking it to translate an already-solved problem into code. The hard thinking happens up front, before any translation starts.
That’s also the real relationship between dialog and the industry’s push toward more autonomous agents. The two aren’t in tension. Front-loading the dialog is what earns an agent full control of the wheel once implementation starts. Less hand-holding during the build is the payoff of more communication before it.
Naming the Gap Is the First Step to Closing It
Closing that gap means giving the agent room too. Not with silence, not with violence, but with the back-and-forth that builds a shared pool of meaning. Let it ask. Let it investigate. Give it room to build its own understanding a step at a time, instead of expecting either side to show up with the complete picture already in hand. That’s less a model limitation than a configuration one. An agent can already ask clarifying questions and flag its own assumptions today, but usually only when the prompts, tools, and harness around it are built to invite that behavior. Left to a bare, unguided exchange, most don’t volunteer it on their own, in my experience. That’s not a capability we’re waiting on. It’s a design choice most setups haven’t made yet, which is, once again, an AI agent communication problem wearing a capability costume.
The field is already converging on this from more than one direction — context engineering, spec-driven development, all of it circling the same fix for the same AI agent communication problem that’s always worked between people. None of it requires waiting on a new model release. Next time you open a chat with an agent, ask it to explore and report back before it changes anything. That one habit is the whole argument.
✨ AI Post Recap
Most complaints about AI agent “slop” come from missing context, not missing model capability. People skip the details that feel too obvious to state, which psychology calls the curse of knowledge, and agents rarely ask for what they are missing. The fix is dialog: have the agent explore the relevant code and report back with a plan before it builds anything. Static context files like AGENTS.md do not replace this, because they only capture what was true the day they were written.
Why does my AI coding agent produce bad code? Usually because the prompt left out context that felt too obvious to state, not because the model cannot do the work. The agent never saw the constraints, prior decisions, and edge cases that live only in your head.
What is the best way to prompt an AI coding agent on an existing codebase? Ask it to explore the relevant area and report back with a plan before it writes any code. That exploration surfaces things neither of you knew to look for, and the change usually lands right the first time.
Do AGENTS.md or CLAUDE.md context files fix AI agent output? Only partly. A 2026 ETH Zurich study found automatically generated context files reduced success rates by about 3% and raised inference costs over 20%, while hand-written ones gained about 4%. A short set of non-obvious, slow-changing facts beats comprehensive documentation.
