An LLM predicts tokens; an agent executes tasks

One sentence appears to explain all artificial intelligence applied to code: a language model predicts the next token.

The sentence is technically useful. It can also be misleading when it is used to describe the complete product.

Autocomplete takes the context near the cursor and proposes a continuation. A coding agent can receive an objective, explore a repository, consult documentation, edit several files, run commands, observe errors, try again, and deliver a diff for review.

In both cases, a model is generating tokens. What changes is the system built around it.

That distinction matters because Cursor, Codex, Claude Code, and Google Antigravity create value through more than faster code generation. Their usefulness appears when they can participate in a larger part of the development cycle: recover context, make bounded decisions, use tools, verify results, and return reviewable work.

It also explains their limits. A model can produce convincing but incorrect code. An agent can turn that error into real changes. As execution capability increases, tests, permissions, isolation, observability, and human review become more important.

In summary

An LLM generates tokens. Autocomplete uses that capability to propose a local continuation. An agent places it inside a system that can observe an environment, select tools, execute actions, and correct itself from the result.

That does not make the agent an infallible developer or remove the need for an accountable person. It means that the unit of work can move beyond the next line and become a complete task, such as reproducing a bug, adding a test, updating a dependency, or preparing a pull request.

The real usefulness of these tools depends on five conditions:

1. The objective is sufficiently bounded.
2. The agent receives the context it needs.
3. Verifiable signals exist, such as tests, compilation, or visible behavior.
4. The change is reversible and reviewable.
5. The cost of controlling the result is lower than the work avoided.

The right question is not whether the tool “is autocomplete.” The question is which part of the work it can close in a verifiable way and within which boundaries.

An LLM can predict tokens without the product being only autocomplete

Base language models are trained to predict the next unit in a sequence. That unit is usually expressed as a token, not necessarily a complete word. From the preceding context, the model assigns probabilities to possible continuations and produces an output.

That is the generative mechanism.

A development product adds other layers:

Layer	What it contributes
Model	Interprets instructions, relates information, and generates code, plans, or tool calls.
Post-training	Adjusts behavior to follow instructions, use tools, and respect certain boundaries.
Context	Supplies files, repository rules, history, documentation, errors, and prior decisions.
Agent	Manages the work loop and decides which information or tool it needs next.
Tools	Enable reading, searching, editing, command execution, Git use, API access, or interaction with other applications.
Environment	Returns real signals: tests, compilation, logs, browser state, diffs, task state, or a service response.
Controls	Restrict the filesystem, network, secrets, commands, identity, number of attempts, and sensitive actions.
Human review	Checks intent, architecture, risk, and alignment with needs that are not always documented.

Reducing the whole system to token prediction is like defining a browser by saying it executes processor instructions. It is not false, but it does not distinguish it from a spreadsheet, a video game, or a server.

To evaluate an agent, we need to observe the behavior of the complete system.

Autocomplete, assistant, and agent are not the same unit of work

The evolution of these tools is not merely a scale of “more generated code.”

Autocomplete

It works near the cursor. It suggests how to continue a function, condition, test, or API call.

The person retains the complete loop:

think → write → run → interpret → correct

Autocomplete reduces part of the writing.

Conversational assistant

It can explain an architecture, propose a function, review a fragment, or answer questions about files supplied as context.

It expands analytical capacity, but the person often still copies information into the chat and moves the answer back into the project.

Coding agent

It receives an objective and can operate inside the environment:

objective
→ inspect the repository
→ formulate a plan
→ edit
→ run tools
→ observe the result
→ correct
→ verify
→ deliver for review

The difference is not just length. It is a difference in flow control.

An agent can choose which file to read, which command to run, and when the task needs another iteration. Under OpenAI’s definition, the LLM controls workflow execution and selects tools. Anthropic similarly distinguishes workflows with predefined paths from agents that dynamically direct their processes and tool use.

Environmental feedback changes the quality of the work

A model can generate a function that looks correct. The terminal can prove that it does not compile.

It can propose a migration. Tests can show that it breaks compatibility.

It can claim that it fixed a visual problem. A browser controlled by the agent can reveal that the component still overflows on mobile.

The model does not become deterministic as a result, but it becomes less dependent on a single plausible answer. The system can compare generation against external evidence.

This is why software development is particularly well suited to agents:

• structured code exists;
• many actions can run in an isolated environment;
• changes are represented as diffs;
• tests provide acceptance criteria;
• Git supports comparison, reversal, and review;
• compilers, linters, and analyzers produce concrete signals.

Automatic verification is still not sufficient. A test can be incomplete, a specification can be ambiguous, and a solution can pass the suite while degrading the architecture. The environment provides partial ground truth, not total judgment.

Human review does not mean there is no agent

A system does not need permission to publish code on its own in order to be an agent.

Suppose it receives this task:

Find out why checkout repeats a charge after a timeout, add a regression test, and prepare a reviewable change.

During execution, it can:

• find the retry logic;
• reconstruct the path across several modules;
• read existing tests;
• reproduce the failure;
• modify two or three files;
• run the suite;
• correct a secondary error;
• summarize the cause;
• present the diff.

If a person reviews that result before merge, the preceding work does not retroactively become autocomplete.

Review defines who has authority to accept the change. It also protects requirements the agent may not know: product decisions, tacit conventions, organizational dependencies, operational impact, or future priorities.

It is useful to separate capability from authorization:

Level	System capability	Reasonable authorization
Assistance	Explains or proposes code.	Can answer directly.
Investigation	Reads and diagnoses.	Read-only access.
Preparation	Edits in a branch or worktree.	Bounded write access and tests.
Delegation	Completes a task and prepares a PR.	Review before integration.
Automation	Runs from events or cron.	Policies by task type and volume limits.
Sensitive operation	Deploys, changes data, or uses secrets.	Explicit approval, separate identity, and audit.

Useful autonomy is not “all or nothing.” It is configured by action, environment, and risk.

What Cursor contributes

Cursor combines several surfaces within the same product.

Tab remains autocomplete: it proposes continuations while a person edits. Agent can search the codebase, read and modify files, use the terminal, and access MCP tools. Cursor CLI moves the agent into the terminal and scripts. Cloud agents can work in isolated machines, test changes, and produce artifacts such as screenshots, videos, or logs to accompany a pull request.

That combination offers a practical advantage: it lets the user change the level of delegation without leaving the workflow.

A person can:

1. write a sensitive section manually;
2. accept a local continuation;
3. request a multi-file edit;
4. delegate a bug to a cloud agent;
5. review the result in the IDE or GitHub.

Cursor is especially useful when the editor remains the center of work and a team wants to introduce agency progressively.

Its risk also comes from that fluidity. It is easy to move from a small suggestion to a broad edit without redefining scope. Reviewing the plan, diff, and commands—and distinguishing exploratory tasks from mergeable changes—therefore remains important.

What Codex contributes

Codex CLI works directly from the terminal. It can inspect code, modify files, run commands, review changes, and automate repeatable work. Configuration can define project instructions, permissions, and review modes.

Codex cloud changes the time dimension. Each task can receive an isolated, reproducible environment, continue while the person works on something else, and return as a reviewable result. Work can also begin from GitHub, Linear, or Slack, and several tasks can run in parallel.

Its value appears in two patterns.

Closed delegation

The task has a recognizable exit condition:

Update this API, preserve compatibility, add tests, and return a diff.

The person spends time specifying and reviewing, not necessarily executing every step.

Parallelism

While a developer works on an architectural decision, several agents can investigate independent bugs, prepare documentation, or test alternatives.

Parallelism does not remove cost. It moves the bottleneck toward specification, evaluation, and integration. If ten agents produce ten mediocre changes, the organization has not multiplied productivity; it has multiplied its review queue.

What Claude Code contributes

Claude Code was originally oriented around the terminal, but it now also works in IDE, desktop, and browser surfaces. It can read the codebase, edit files, run commands, work with Git, create pull requests, and connect external tools through MCP.

Extensibility is an important part of the product.

A CLAUDE.md file can supply persistent project rules. Skills can package reusable procedures. MCP servers connect systems such as issue trackers, observability platforms, or documentation. Hooks run controls at specific points in the lifecycle.

Hooks demonstrate the distinction between model and system particularly well.

There is no need to trust that the LLM will remember to run the formatter after every edit. A deterministic hook can always do it. Nor must the team hope it decides on its own to block a dangerous command: a rule can validate the command before execution.

Claude Code is especially well suited to teams that want to build an agentic environment around the terminal, Git, scripts, and internal tools.

What Google Antigravity contributes

Google Antigravity explicitly separates direct editing from agent coordination.

The IDE includes completion, commands, and an agent capable of operating across the editor, terminal, and browser. Antigravity 2.0 adds a management surface for launching, observing, and coordinating several agents across different projects and workspaces. Subagents can divide parts of a problem, scheduled tasks can automate recurring work, and artifacts show plans, results, and verification evidence.

The central abstraction is no longer “a conversation with the code,” but a portfolio of tasks.

That is useful when work can be decomposed:

• one agent investigates the cause;
• another prepares tests;
• another validates the interface;
• another reviews a migration;
• the person compares artifacts and decides what to integrate.

The challenge is organizational. As more agents work in parallel, avoiding overlap, conflicts, ambiguous objectives, and superficial review becomes more important.

There is no universally best tool

The four tools overlap, and their capabilities change quickly. The decision should begin with the workflow, not a ranking.

Primary need	Tool worth evaluating	Why
Stay inside the IDE and alternate between Tab, editing, and an agent	Cursor	It integrates different levels of assistance in the same surface.
Work from the terminal and delegate tasks to cloud environments	Codex	It combines local execution, automation, and isolated parallel work.
Customize rules, hooks, skills, and connections to internal systems	Claude Code	It provides an extensible surface around the terminal and tools.
Coordinate multiple agents and projects through artifacts	Antigravity	It prioritizes orchestration, subagents, scheduled tasks, and result management.
Automate repetitive tasks in CI or from events	Cursor, Codex, or Claude Code	All three offer programmatic modes; the choice depends on permissions and integrations.
Maintain maximum supervision over sensitive changes	Any of them, with the right environment	Control depends more on permissions, branches, tests, and approvals than on the brand.

The comparison should be repeated periodically. In this market, a feature table ages quickly. The more stable questions are:

• Where does the context live?
• Which tools can it use?
• How does it isolate execution?
• What evidence does it return?
• How is the result reviewed?
• Which actions require approval?
• What does it cost to operate and control the workflow?

Where the real usefulness comes from

The benefit is not limited to typing less.

Recovering context

A significant part of technical work consists of finding files, reconstructing decisions, following calls, reading logs, and remembering how to run a project.

An agent can reduce that orientation cost, especially in unfamiliar repositories or tasks that cross several layers.

Closing verification loops

Generating code is cheap. Verifying it is often the important work.

When the agent can run tests, read the error, and correct the change, it absorbs part of a loop that previously required continuous attention.

Avoiding context switching

A small bug may take little time to solve, but it interrupts more valuable work. Delegating it to a separate environment can be worth more than accelerating its implementation minutes.

Addressing the low-priority backlog

Documentation, missing tests, repetitive migrations, mechanical updates, and intermittent failures are often postponed because they do not justify an interruption.

An agent can lower the cost of starting that work.

Exploring alternatives in parallel

For a reversible decision, several independent attempts can expose solutions, risks, or implementation differences before the team commits its own time.

Parallelism only creates value when there is an efficient criterion for comparing the results.

The productivity evidence is mixed

There is no universal number for how much a coding agent accelerates work.

A controlled METR trial using early-2025 tools found that 16 experienced developers working in familiar repositories took 19% longer when they could use AI. The participants nevertheless believed that they had worked faster.

That result should not be generalized carelessly. METR now presents it as historical and notes that it does not necessarily reflect 2026 tools. The study focused on expert developers, mature repositories, and real tasks lasting roughly twenty minutes to four hours.

In February 2026, METR published later data showing signs of acceleration, but judged the estimate unreliable. Some developers avoided participating because they did not want to be assigned to work without AI; simultaneous use of several agents also made human-time measurement difficult.

A field study of Claude Code and Copilot CLI deployment at Microsoft during the first months of 2026 found that adopters merged approximately 24% more pull requests than the counterfactual estimate. The authors themselves warn that a merged PR is a proxy for output, not a direct measure of value, quality, or impact.

There is also a learning cost. An Anthropic trial with 52 developers found that the AI-assisted group scored 17% lower on comprehension while learning a new library. It finished only a few minutes sooner, and that time difference was not statistically significant. Participants who used AI to request explanations and build understanding retained more knowledge than those who delegated the solution.

These studies measure different situations. Together, they suggest something more useful than an average figure:

Productivity depends on task type, prior knowledge, the tool, the way it is used, the ability to verify, and the metric chosen.

Where they usually work best

A task is a good fit when it has several of the following properties.

Concrete objective

“Improve the architecture” leaves too many decisions open.

“Extract this validation into a module, preserve the public API, and add tests for these cases” sets a clearer scope.

Verifiable result

Compilation, tests, linting, types, snapshots, benchmarks, or browser behavior make progress observable.

Reversible change

A branch, worktree, patch, or isolated cloud environment lowers the cost of a failed attempt.

Accessible context

The repository includes instructions, commands, conventions, examples, and technical decisions. The agent does not need to guess everything the team knows.

Bounded review

The diff is understandable, and the result includes an explanation, the commands run, and the remaining risks.

Under those conditions, good candidates often include:

• bounded bugs with a regression test;
• mechanical refactors;
• dependency updates;
• repetitive migrations;
• test generation or expansion;
• CI-error investigation;
• documentation tied to code;
• disposable prototypes;
• initial repository analysis;
• preparation of a pull request for review.

Where they can make the work worse

Usefulness falls when:

• the requirement is ambiguous;
• business rules are undocumented;
• there is no way to validate the result;
• the change crosses too many systems;
• product decisions are unresolved;
• the repository contradicts its own conventions;
• the agent receives unnecessary permissions or secrets;
• reviewing the code costs more than writing it;
• the team accepts output it cannot explain;
• a learner delegates exactly the reasoning they need to acquire.

Another risk is measuring activity instead of progress.

More lines, commits, or pull requests can mean more value. They can also mean more volume to review, more duplication, and more technical debt.

The correct unit is completed and validated work

To evaluate these tools, it helps to abandon the question “How much code did it generate?” and observe the whole workflow.

Dimension	Useful metric
Speed	Time from task assignment to a reviewable diff.
Human attention	Active minutes spent specifying, monitoring, and reviewing.
Acceptance	Percentage of the change retained without substantial rewriting.
Rework	Corrections needed after the first delivery or merge.
Quality	Regressions, incidents, test results, and defects found in review.
Flow	Time from issue to merge and time blocked.
Coverage	Useful work that previously went undone.
Cost	Licenses, tokens, infrastructure, executions, and review.
Risk	Excessive permissions, data exposure, external actions, and incidents.
Learning	The team’s ability to explain, debug, and maintain the result.

A conceptual formula would be:

net value =
human time avoided
+ additional useful work
+ quality improvement
+ value of parallelism
- specification and review time
- rework
- execution cost
- introduced risk
- loss of understanding

Not every term is easy to monetize. Even so, the formula forces us to look beyond apparent speed.

How Nicolás Torres would approach it

I would not begin by buying one tool for the entire team or setting a usage quota.

I would begin by choosing three real, frequent, comparable task types. For example:

1. small fixes with a regression test;
2. diagnosis of CI errors;
3. documentation or dependency updates.

I would then establish a baseline:

• total duration;
• active human time;
• number of attempts;
• review time;
• rework;
• later defects;
• interruption cost;
• percentage of abandoned tasks.

The pilot would use a bounded environment:

• repository instructions;
• a separate branch or worktree;
• limited filesystem access;
• secrets out of reach;
• controlled network access;
• defined commands;
• mandatory tests;
• approval before integration;
• sufficient action logging.

After several weeks, I would compare results by task type and user profile. I would not mix a mechanical bug with an architectural decision or a repository expert with someone who has just joined.

I would also reserve periods of work without delegation for learning. A team that produces more code but loses the ability to understand and correct it is moving risk into the future.

Autonomy would grow only where the result demonstrates value:

read
→ propose
→ edit in isolation
→ execute at low risk
→ prepare a PR
→ automate repeatable tasks

Deployment, modification of real data, or use of sensitive credentials would follow a different process.

What should be clear when choosing a tool

Before comparing models or plans, I would ask for concrete answers to these questions:

1. Can it work across the whole repository or only selected context?
2. Which actions run locally and which run in the cloud?
3. How are dependencies and environment variables reproduced?
4. What permissions does it have over files, the terminal, the network, and external tools?
5. Can it separate each task into a branch, worktree, or isolated machine?
6. Which artifacts does it return for review?
7. How does it log commands, tool calls, and decisions?
8. What happens when a test fails or it exceeds the attempt limit?
9. How is it prevented from reading secrets?
10. How is the real cost calculated, including review and rework?

The best tool is not the one that generates the most impressive demo. It is the one that improves a concrete workflow without making risk opaque.

Conclusion

A language model predicts tokens. That description explains an essential part of how it works.

It does not, by itself, explain what a coding agent is.

Autocomplete uses prediction to suggest a continuation. An agent inserts it into an architecture with context, tools, state, execution, feedback, permissions, and exit conditions.

Cursor, Codex, Claude Code, and Antigravity are useful when that architecture can close a verifiable part of the work:

understand
→ act
→ check
→ correct
→ deliver

They are not infallible. They do not make every task valuable. They do not automatically replace judgment, architecture, business knowledge, or human responsibility.

But they are not correctly explained as systems that only write the next line.

A more demanding question should guide adoption:

What useful work can this agent complete, what evidence does it return, how much human effort does it avoid, and what boundaries does it need for the result to be trustworthy?

When that question has a measurable answer, the discussion stops being semantic. It becomes an engineering decision.

Frequently Asked Questions

Is an LLM only an autocomplete system?

At the generative-mechanism level, an LLM predicts the next token from its context. That description is not enough to explain a complete product: post-training, context, tools, memory, the execution environment, and controls change what the system can do.

What separates autocomplete from a coding agent?

Autocomplete proposes a local continuation. An agent receives an objective, explores the repository, selects tools, edits files, runs commands, observes results, and can iterate until it delivers a verifiable change.

Do Cursor, Codex, Claude Code, and Antigravity do the same thing?

They share agentic capabilities but prioritize different surfaces. Cursor combines completion, an IDE, a CLI, and cloud agents; Codex combines the terminal with delegation in isolated environments; Claude Code emphasizes the terminal, extensibility, hooks, and MCP; Antigravity focuses on coordinating agents, projects, and artifacts.

Does human code review mean the system is not an agent?

No. Human review defines authority and responsibility. An agent can investigate, edit, test, and prepare a pull request while still stopping before integration or deployment because that action requires approval.

Do these tools always improve productivity?

No. The evidence differs by tool, task, experience, repository, and metric. They can accelerate bounded, verifiable work, but they can also increase review, rework, or loss of understanding.

How should a company evaluate them?

With real tasks, a baseline, and completed-work metrics: active human time, time to a reviewable diff, acceptance, rework, regressions, cost, risk, and the team's ability to maintain the result.