Describe what a coding agent does that a code completion model (e.g. GitHub Copilot's inline suggestion) cannot. Which phases of the software development loop does a coding agent own autonomously?
A completion model predicts the next tokens in a static file. A coding agent reads files, edits, runs tests, reads the output, and repairs until the suite passes.
Imagine two helpers writing a letter for you. The first is a great autocomplete: you start a sentence and it guesses the rest, but it never reads the finished letter or checks if it makes sense. The second helper actually reads your whole desk of papers, writes the letter, mails a draft, waits for a reply, and rewrites it based on what comes back. A code-completion model is the first helper. It fills in the next few lines wherever your cursor sits. A coding agent is the second one. It opens the project files, makes a change, runs the tests, reads the errors that come back, and fixes them, looping until the tests pass. The loop and the feedback are the difference. One guesses once; the other tries, checks, and tries again.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
A coding agent and a code-completion model look similar from the outside, since both emit code from an LLM. Architecturally they are very different systems. A completion model is a single forward pass: it consumes a static context, usually the open file plus a little surrounding code, and predicts the next tokens at the cursor. It runs once, returns a suggestion, and stops. It never executes what it wrote and never learns whether the suggestion was right.
A coding agent is an LLM placed inside a loop with tools, and the tools let it act on a real project: read files, write edits, and run a shell or test runner. Because it can run the code and read the output, it can correct itself. That feedback loop is the whole difference, and it is why a coding agent can own an entire slice of the development cycle that a completion model never touches.
The interview point is to resist the temptation to frame this as a smarter model. The same model powers both products. What changes is the system wrapped around it: a static prompt and respond interface versus a runtime that gives the model tools, executes them, and feeds the results back. Once you see it as a systems question, the design choices that matter, repo navigation, grounding, sandboxing, and verification, fall out naturally.
Completion versus agent: a single pass versus a loop
A completion model is stateless across suggestions. Each request packs a static context, the open buffer and perhaps a few related files, and the model predicts a continuation. There is no notion of running the result, observing an outcome, or trying again. The model that produced a wrong function body has no way to discover the body was wrong, because nothing ever executes it. The interaction is one shot: prompt in, tokens out, done.
A coding agent inverts this. The model is the reasoning core, but the runtime around it owns the control flow. On each turn the runtime gives the model the current task state, the model emits a tool call such as a file read, a file edit, or a shell command, the runtime executes it, and the result is appended back into the context. The model then reasons over the enlarged state and emits the next action. The state is the running transcript of the goal plus every action and observation so far.
The headline capability that follows is execution feedback. When the agent runs the test suite, the pass or fail status, the assertion message, and the stack trace all return into the context as observations. The next edit is therefore grounded in what the code actually did, not in what the model guessed it would do. Completion can never close this loop.
This is also why a coding agent can fail in ways a completion model cannot. It can loop, retry a broken command, pollute its own context with megabytes of test logs, or declare success prematurely. Those failure modes are the price of autonomy, and handling them is exactly what separates a demo from a shippable agent.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- SWE-bench gives an agent a real GitHub issue and repository and scores whether its patch passes the hidden test suite, which is now the headline metric for coding agents.
- Cursor's agent mode and Claude Code both read files, apply diff-based edits, run the test runner in a shell, and loop on the failures until the suite is green.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a coding agent find the right files to edit in a repository far larger than its context window?
Describe retrieval as a tool: ripgrep or grep search, symbol or AST indexing, and embedding search over chunks. The agent issues search calls, reads only the top hits, and expands neighbours on demand rather than loading the whole repo.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Calling Copilot inline suggestions an agent. Completion is a single forward pass over a static buffer. It never runs the code or reacts to test output, so there is no repair loop.
60 second bullets to scan on the way to the call.
Contrast a single forward pass over static context with a tool-using loop.
Name the read, edit, run tests, repair cycle the agent owns.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.