For a while, the conversation around getting better results from AI agents centered on two things: choosing the right model and writing cleverer prompts. Both still matter, but practitioners who have been building with agents long enough are converging on a different answer. The real bottleneck is communication — and not just with the model.
The gap models cannot close
No model reads your mind. Every agent starts a session knowing almost nothing about what you care about, what constraints exist in the codebase, what language your team uses for the domain, or what “good” looks like in your context. The practitioner’s job is to surface that context clearly and repeatedly.
This matters more than raw model capability for a simple reason: a capable model operating on incomplete context will confidently produce the wrong thing. Getting the right thing depends on context having been transferred successfully. That transfer is a communication problem, not a capability problem.
The best practitioners producing strong results with agents share a common trait: they are outstanding communicators. Their clarity of thinking shows in what they produce. This is not a coder-versus-non-coder divide — it holds equally for knowledge workers who have never written a line of code.
Unknown unknowns are the real obstacle
The harder part of communication is not expressing what you know — it is surfacing what you do not know you do not know. Agents, left to their own devices, fill context gaps with reasonable-sounding assumptions. Those assumptions are usually wrong in ways that are hard to catch until the work is already done.
One approach worth naming: before starting a complex task, have the agent interview you relentlessly about what you are building. The agent asks clarifying questions; you answer them. This process surfaces gaps in your own understanding that would otherwise become gaps in the agent’s output. A refinement of this technique also builds a shared vocabulary — consistent terms across code, database schema, user interface, and client conversations — that keeps a project coherent as it grows. Domain-driven design (a software practice that emphasises agreeing on a common language across a whole team) called this a “ubiquitous language,” and it turns out to be just as valuable when half the team is an AI agent.
The environment matters more than the model
There is a tendency to attribute output quality to the model — newer, more capable, more expensive. The evidence from practitioners suggests the environment the model operates in matters at least as much.
“Garbage in, garbage out” applies at the codebase level. An agent working in a disorganised mess of inconsistencies compounds those inconsistencies over time. An agent working in a clean, well-structured, easy-to-change codebase produces results that stay coherent. The question worth asking is not “which model should we use?” but “if a hundred new developers joined this project tomorrow, what would we do to raise the floor?” Tests, standards, clear separation of concerns — the answers are the same as they were twenty years ago.
This insight prompted a course correction that is worth paying attention to: treating specs as a layer of code that agents execute against seemed promising but degraded code quality in practice over months of real use. Pivoting back to focusing on the code itself — keeping it clean and easy to change — produced better results. The operating environment is the agent’s leverage point.
Starting slow is not timidity
A common piece of advice in agent adoption circles is to give AI the most ambitious tasks first — that is where the leverage is. The counterargument is more practical: start with boring, menial, measurable work. Drafting replies. First-draft writing. Tasks where it is easy to verify whether the output is correct.
The reasoning is not about caution for its own sake. Watching an agent closely on low-stakes work teaches us where it is reliable and where it needs supervision. Scaling before that understanding is in place leads to compounding errors that are expensive to unwind. Learn the brake before the accelerator.
Where this is heading
The practitioners most excited about the next few years are not excited about better models per se. They are excited about agent systems that improve codebases over time on their own — automated processes that catch and fix technical debt, enforce standards, and keep the operating environment healthy without requiring a human to direct every step. The aspiration is an agent that behaves like “the developer who insists on doing it the right way” — one that prioritises long-term quality, not just task completion.
We are still early on that curve. Multi-agent orchestration has not yet produced an approach that holds up at scale. But the direction is clear: teams that invest now in clean environments, shared vocabulary, and honest communication about context will be the ones whose agent systems compound most effectively as the tooling matures.
Text summarized and optimized using Anthropic’s models and reviewed by a human.