How do an inline completer, an in-editor agent, a terminal agent and a hosted agent differ in what they can see and reach?
answer
- Compare shapes, not brands
- Two properties, both about boundaries
- One concerns the material it had
- The other concerns what it could touch
basics
~20 sFour shapes, two axes: what each can read, and what each can act on. A completer writes at one point; an in-editor agent edits an open project; a terminal agent also runs commands; a hosted agent changes only its own copy.
solid answer
~40 sAsk two things of any of them: what can it see, and what can it reach. An **inline completer** sees a narrow window around where you are typing and can only put text there. An **in-editor agent** sees the project as the editor models it and edits across files, usually for you to accept in place. A **terminal agent** sees a working copy on disk and can also run things — a build, the tests, a search — so it reacts to real output rather than only to text. A **hosted agent** works on a copy elsewhere and hands back a proposed change, so it cannot touch your machine and you were not watching while it worked. Review size, blast radius and what you can reconstruct later follow largely from those two answers.
go deeper
Be able to name the shapes and say, for each, what it can look at and what it can change. You are not expected to have operated all of them; you are expected not to treat them as one thing.
Explain why those two axes produce the behaviour differences you have seen: a tool that never opened a file cannot be relied on to honour what is in it, and one that can run a command has evidence where the others have only text.
Show that you pick a shape per task and can say what each choice costs in review size and in how far a mistake travels. Name a case where you deliberately chose the smaller reach.
Own the argument for what the organisation standardises on and, more importantly, what it leaves to the engineer. Be able to say which property of the work the standard keys on, rather than which product.
## Two questions you can ask of any tool Products here are renamed, merged and relaunched constantly, so a memorised feature list answers a question that expires. Two properties do not. **What a tool can see** is the material it is able to bring into a decision: the fragment around an insertion point, an editor's model of an open project, a working copy on disk, a checkout it was handed when it started. **What a tool can reach** is what it is able to change or invoke: an insertion point, files across a project, commands in an environment, or nothing outside a copy of its own. Interviewers are rarely testing whether you know four brand names; they are testing whether you can reason about a tool you have never used. ## The four shapes, side by side | shape | what it can see | what it can reach | what arrives for a human | |---|---|---|---| | **inline completer** | a window around the insertion point, plus whatever the editor supplies | the insertion point | a small unit, offered while you type | | **in-editor agent** | the project as the editor models it, plus files you point it at | files across the open project, sometimes a way to run them | a set of edits to accept in place | | **terminal agent** | a working copy on disk, plus the output of whatever it runs | files, and commands in that environment | a change, and a trail of what was run | | **hosted agent** | a checkout of the repository, as of when it started | its own copy, not your machine | one proposed change, complete, after the fact | Read that as a gradient, not four species: moving down it, the material available grows, the reach grows, and the unit arriving for a human decision grows with both. ## What it could see decides what it could get right The most reliable sentence on this subject is that **a tool cannot reliably account for what it never saw**. When a generated change contradicts a rule that is written down somewhere in the repository, the useful first move is not to ask why the model reasoned badly. It is to ask whether that file was inside what this shape could see for this change. A convention recorded in a document the tool never opened is a reach problem, and its fix — put the rule where the tool reads — looks nothing like the fix for a reasoning problem. The diagnostic order is worth memorising: 1. Was the material it needed inside what this shape could see at all? 2. If it was, did it arrive in the request, or only somewhere the tool would have had to go and find it? 3. Only then ask whether it reasoned badly about material it demonstrably had. The same logic runs the other way, and this direction is the one candidates miss. A shape that can run a command obtains something no amount of reading provides: **the result**. Text about what the code does is a claim; a command's output is evidence. That is the substantive difference between shapes that can only propose and shapes that can execute — not speed, and not the model behind them. How you then use a failing result to steer a session is a separate discipline with its own rules. ## What each shape trades - An **inline completer** produces the smallest unit per human decision, so its mistakes are individually cheap and each one is looked at — and its ceiling is correspondingly low. - An **in-editor agent** keeps a human in the room while the change is still small, and is bounded by whatever the editor exposes to it. - A **terminal agent** can check its own work against real output, and can also change things nobody asked it to; the same reach produces both of those. - A **hosted agent** leaves your machine untouched and lands nothing until a person accepts it, and concentrates the entire result into one review that happens after every decision was already made. - No row is strictly better than another. Wider reach raises the ceiling and the cost of a mistake at the same time, which is why *which of these is the best tool* is a weaker question than *which shape does this task deserve*. ## Where the boundaries blur, and why that is fine Real products mix shapes, and one often offers several. That does not break the analysis, provided you apply it to the **session you are in right now** rather than to the name on the invoice. A tool offering both a completer and an autonomous mode is two shapes, and the right answer changes when you switch. What a given shape is *permitted* to reach is a further question again, belonging to how teams sandbox and permission these tools. ## Answering this in an interview Name the two axes, place the shapes on them, then show the derivation: review unit, how far a mistake travels, and what you can reconstruct afterwards all fall out of see-and-reach. Finish with a preference expressed as a fit for the work in front of you rather than as a brand. An informed comparison is what is being asked for; brand loyalty is what is screened out.
- A tool made a change that contradicts a convention written down in the repository. What do you check first?Whether it could see the file that states the convention. A rule living in a document the tool never opened is a reach problem, not a reasoning problem, and the fix is to put the rule where the tool reads or to state it in the request — not to switch tools.
- Does a shape with wider reach always produce better changes?No. Wider reach raises the ceiling and the cost of a mistake together. On a change you can specify precisely and check cheaply, a narrower shape gets you the same result with a smaller review and less that can go wrong unnoticed.
It is the difference between asking a contractor to quote from a photograph of one wall and handing them the keys to the building. The photograph bounds what they can judge; the keys decide what they can change and what they can try out on site.
saying these in an interview costs you the question
- Ranks the tools by which model each uses, and stops there
- Treats every AI coding tool as one thing behind different interfaces
- Assumes an agent can see the whole repository whenever it wants
- Explains every wrong change as hallucination, never as missing context
- Says a tool that cannot run commands is just a worse version of one that can