Concepts

Autocomplete vs an agent that takes the job

Autocomplete predicts the next line in the file you are editing. An agent takes a described outcome across the workspace. Where each one fits.

Autocomplete and a coding agent get compared as if one replaces the other. They do not solve the same problem. Autocomplete predicts the next token or line in the file you are already editing. A coding agent takes a described outcome, gathers context across the workspace, plans, edits several files, runs commands, and checks the result.

Most developers end up wanting both, because the two tools fit different steps of the same task.

What autocomplete actually does

Autocomplete is a completion model pointed at your cursor. It reads the file around the caret and predicts what comes next.

It is fast enough to stay in your typing rhythm.
It never leaves the file, so there is no context to manage.
It keeps you in the driver's seat: every accepted suggestion is a keystroke you chose.
It is strong on boilerplate, repetitive patterns, and the line you were about to write anyway.

Autocomplete is not a smaller agent. It is a different kind of tool: a prediction at the cursor, not a job that runs to completion.

Where autocomplete breaks down

The moment a task stops being local, prediction at the cursor runs out of room.

Cross-file changes. Renaming a concept across a package, or changing a signature and every caller, needs a view of the whole workspace rather than the current buffer.
Migrations. Framework upgrades and API migrations are long sequences of related edits that have to stay consistent.
Test-fix loops. Fixing a failing test means running the test, reading the output, and editing again. Autocomplete cannot run a command.
Anything that needs a command to run. Builds, migrations, linters, and test suites live outside the editor buffer.
Work you did not type. When you assign an outcome instead of writing each line, there is nothing at the caret for a completion model to complete.

What an agent does instead

An agent starts from a described outcome, not a cursor position. The loop is understand → plan → implement → verify.

Understand: gather context from the workspace — the files, symbols, and call sites the job touches.
Plan: write the approach down before changing anything.
Implement: edit the files the plan names, and run the commands the job needs.
Verify: run a check and read the result instead of assuming the change worked.

That is a larger surface than autocomplete, which is exactly why it needs more control than a suggestion popup.

What an agent needs before you trust it

Context you can inspect. You should be able to see which files the agent read and why.
A plan on disk. The approach should be a file you can read, edit, and diff before implementation starts.
A review checkpoint. Edits should stage somewhere you can see them before they land on disk.
Verification evidence. A check should define what "passing" means — an exit code and an output phrase — so success is observed, not implied.

Without those, an agent is a black box writing to your working tree. With them, it is a tool you can steer.

How Vortex implements that loop

Plan mode writes <workspace>/.vortex/plans/<name>.plan.md. The plan is an editable file, so the approach is reviewable before any edit happens. See plan files.
Review mode keeps every agent file edit as a pending patch in the Changes panel. Nothing is written to disk until you approve it, and rejected patches are discarded. See review mode.
Verification checks can require a specific exit code and an output phrase, so a step is defined rather than assumed.
On-device retrieval is lexical, symbol, path, outline, and reference search. There is no embedding corpus and no repo upload, and you can see which files the agent read.

Vortex is not an editor, and it does not compete on tab completion. It is the layer that takes a described job through context, plan, edits, commands, and verification.

Pick the right tool for the step

Step	Better tool	Why
Rename a local variable	Autocomplete	One file, one obvious change, no command to run
Finish a line you already started	Autocomplete	The intent is already in your head and at the caret
Write a new module	Agent	The job needs context from several files plus a plan
Fix a failing test	Agent	The loop has to run the test and read the output
Migrate an API across the repo	Agent	Cross-file edits need a plan and a review checkpoint
Review a diff before it lands	Agent, then you	Edits stage as pending patches you approve or reject

Most of these are not either/or. Keep autocomplete for keystroke-level work and hand the agent the steps that span files and commands.

What Vortex does not claim

Verification gates are advisory in this beta. You can require an exit code and an output phrase, but the agent does not hard-block a run on a failing gate. You stay the final reviewer.
Vortex is macOS-only during the closed beta. Windows and Linux are out of scope for this beta.

Try it

Vortex is invite-only on macOS 12+. Join the waitlist for access, or read the comparison pages and Vortex vs Cursor to see where it fits next to an editor-first tool.