Choose the agent surface by feedback loop

Start with the shortest truthful feedback loop

The right surface is the one that lets a reviewer see the next consequential decision soon enough to correct it. An editor is strong when the work is exploratory and local: rename a symbol, inspect callers, adjust one test, and compare the diff while the relevant code remains visible. A terminal is strong when the task is naturally expressed as commands, such as tracing a failing build, applying a codemod, or checking generated files. A cloud agent is useful when the work can be specified in advance, run in an isolated environment, and return as a reviewable branch or pull request. GitHub's product guidance similarly distinguishes assistive editing, terminal command work, and remotely assigned repository tasks. That documentation describes available surfaces, not a universal ranking among them.

Match uncertainty to interaction

High requirement uncertainty favors a tight human loop. If an engineer is still discovering whether a bug belongs in parsing, storage, or presentation, an editor or interactive terminal keeps questions cheap. Once the behavior, owned paths, and checks are known, asynchronous execution becomes more attractive. The distinction is not task size alone. A ten-line authorization change can require continuous judgment, while a repository-wide formatting migration can be safe to delegate if the transformation and acceptance checks are mechanical. Before selecting a surface, write down how often the agent is expected to encounter a decision that cannot be derived from repository evidence. Frequent judgment points suggest synchronous work; long stretches of deterministic execution suggest a bounded cloud run.

Worked example: a hypothetical dependency migration

Suppose a team must replace a deprecated request library in a service with 140 call sites. This example is hypothetical. The editor is the best starting point for two representative call sites because an engineer can inspect type errors, cancellation behavior, and local conventions as they emerge. After the team writes an adapter pattern and focused tests, the terminal becomes useful for finding remaining imports and running a repeatable codemod. A cloud agent can then handle a bounded batch in an isolated branch, with network access limited to the package registry and no deployment credentials. The handoff should contain the changed paths, command transcript, failed cases, and a diff. The surface changes as uncertainty falls; choosing one interface for the entire migration would confuse consistency with efficiency.

Decide with four operational questions

Ask where the code executes, which credentials are reachable, how quickly a human can redirect the run, and what artifact returns for review. GitHub documents that local and cloud sandboxes can constrain filesystem, network, credential, and subprocess access, while unsandboxed local commands may inherit the user's authority. Treat those controls as configuration to verify, not protection implied by the word cloud or local. Prefer the editor when continuous inspection is the main control, the terminal when commands and outputs are the main evidence, and a cloud agent when isolation plus an asynchronous review artifact is the main advantage. If none provides an observable stop point before a dangerous side effect, redesign the task before selecting a surface.

GitHub: where to use Copilot ↗

GitHub: cloud and local sandboxes ↗

Keep the choice reversible

Record why the surface was chosen, which alternatives were rejected, and what signal would justify switching. This small decision log prevents convenience or temporary availability from hardening into architecture. Preserve the task contract and evidence when moving between surfaces so a handoff does not silently reset assumptions.