Every major editor now ships some version of "describe the change, get a diff." The marketing language is nearly identical across all of them. What actually differs is where the agent's context comes from: some re-read the whole open file on every request, some maintain a persistent index of the repo, and a few send far more of the codebase to the model than their docs let on.
The other real difference is failure behavior. When an agent gets something wrong, does it silently apply a bad edit, or does it stop and ask first? Tools that ask more questions feel slower turn-by-turn but tend to produce fewer edits you have to manually revert later.
Where the Context Actually Comes From
Re-reading the whole open file on every request is the simplest strategy — it works fine for small files but breaks down once a change genuinely needs context from other files the agent hasn't opened. Building a persistent index of the repo (an embeddings or symbol graph) lets an agent find relevant code across the whole project without you manually opening every file first, at the cost of needing to keep that index in sync as the codebase changes. A third approach — retrieval over a vector index — trades precision for scale, useful once a codebase gets too large to index exhaustively.
Autonomy vs. Confirmation
Some agents apply a multi-file edit immediately and expect you to review it afterward in the diff or git history — fast iteration, but a wrong edit is already on disk before you've seen it. Others stage the change and wait for explicit approval before writing anything — slower per turn, but nothing lands until it's actually been reviewed. Neither approach is objectively better; it's a real tradeoff between iteration speed and review overhead, and it matters most on larger, riskier changes.
The Diff-Application Problem
Once a model decides what to change, actually applying that change to a real file is its own hard problem. Line-number-based patches break the moment a file has changed since the model last saw it, which is why more robust tools match on surrounding context — fuzzy patching — instead of exact line numbers. It's part of why some agents fail more often specifically on files that were recently edited elsewhere.
A coding agent's context strategy and its diff-application method are usually the two most consequential architecture decisions a tool makes — and neither shows up in marketing copy, since "describe the change, get a diff" looks identical from the outside regardless of which choices a tool made underneath.
Does a bigger context window mean a better coding agent?
Not by itself. A huge context window filled with irrelevant code — because the tool doesn't retrieve well — can perform worse than a smaller, well-targeted context. The retrieval and indexing strategy matters more than raw window size.
Why does an agent sometimes fail on a file I just edited manually?
It's usually a diff-application mismatch — if the tool patches based on exact line numbers or a stale in-memory copy of the file, a recent manual edit can shift everything just enough to break the patch.