Inline Edit solves a narrow task: change the selected fragment from a short instruction without raising a full agentic loop. You select the code, open the edit box, write what is needed - and get a suggestion right there. The point of the tool is that the context is already visible to both of you: there is no need to explain where the code is and no need to pay for a search across the repository. The saving is not only in seconds and money. The selection works as a ready and precise statement of the task boundary: the model does not guess what you meant - you showed it.
Naive use looks like this: since it is a convenient box, let it do everything. After a few attempts you discover that instructions such as find all the places, update the dependencies or run the tests either do not execute or execute partially and oddly. That is not a shortcoming: a local edit works by definition with what is selected and is not responsible for the consistency of changes across the tree. Partial execution is more dangerous than a refusal: a refusal is visible at once, while half a change looks like a result and travels into the commit with everything else.
The boundary runs along the word distributed. As long as the task fits into the visible fragment - change a signature, simplify a condition, add handling for an edge case, rewrite a message - Inline Edit is faster and more precise than the agent: less context, less freedom, fewer chances to wander off. As soon as the wording mentions several modules, a search, the terminal or verification, that is work for the agent or for a plan. Pretending you are looking at a local edit is harmful for a concrete reason: the small box shows exactly the piece you selected and by that very fact hides the real size of the change.
It helps to see once what a good instruction for that box looks like. Below is an example: preserve the public signature, remove duplication inside the function, do not change the error format and add a test only for the new edge case. It is short, but it has everything needed: the goal, explicit boundaries and a criterion that makes excess visible.
Boundaries in such an instruction are not a formality but a way to keep the edit local. The phrase do not change the error format costs one line and saves you from untangling a diff where a contract change arrived alongside the useful edit. It is the same task contract as in large work, only compressed into two sentences: the smaller the box, the more important it is to name what should not be done. The reason is an asymmetry of attention: you look for the useful part of the edit and find it immediately, while the excess is noticed later, when something already leans on it.
Two neighboring gestures stand nearby and are worth distinguishing. A quick question about the selection does not change code by itself - it explains, and that is the right first step when a fragment is unclear; the edit it proposes is applied by a separate short command. Sending the selection to the agent, on the contrary, admits that the task has outgrown the box: a search, the terminal or several files are needed. Moving deliberately between those three modes is the actual skill: first understand, then fix locally, and only raise the agent when necessary. The reverse order costs the most: editing code you have not understood produces a diff you then have to explain to yourself after the fact.
A typical case looks like this. A condition inside a function has grown: four branches, two of which differ by a single check. The task is read in full within one screen, the public contract does not need to change, the calling side is untouched - exactly the size the box was made for. The instruction here takes one line: merge the branches while preserving behavior on all inputs. A neighboring wording about updating everyone who calls that function moves the task into another class, because the call sites are not selected and you do not see them.
The edit box is also worth distinguishing from a suggestion while typing. A suggestion guesses the continuation of your action and needs no wording; the edit box carries out a named intent and is therefore appropriate where you already know what you want but typing it by hand takes longer than explaining it. There is one sign in real work that the tool was chosen wrongly: you open the box a second and a third time on neighboring fragments, adding the same thing each time. That means the change is not local by nature and should be posed as a whole task.
The engineering conclusion is simple: Inline Edit is a tool of precision, not of power. Its value lies in being limited, and that limit should not be given up for convenience. Every time your hand reaches to type a large task into the small box, it is worth asking whether everything that will change is visible - if not, this is work for another mode.
The typical failures are predictable. Asking the local box to coordinate several modules and getting half a change. Not naming boundaries and finding a contract change next to the useful edit in the diff. Using an edit where a question was needed: the code changes before you understand why it is the way it is. And the reverse - raising the agent to rename a variable inside the selected block.
Preserve the public signature. Remove the duplication inside the function,
do not change the error format and add a test only for the new edge case.