coding-with-ai/03-autocomplete

Autocomplete

Key idea

Autocomplete is the lowest-friction way to work with an AI assistant: ghost text appears as you type, you accept with Tab or keep typing to ignore. It is the one form of AI assistance that does not require you to write a prompt — the act of typing is the prompt.

That cheapness is its strength and its trap. Because accepting a suggestion is a single keystroke, it is easy to accept code you did not actually read. The skill of using autocomplete well is almost entirely about what you accept and what you reject, not about how you invoke it.

Key goals

• Recognize what autocomplete is good for and what it is not
• Build the habit of reading a suggestion before accepting it
• Avoid the autocomplete-your-verification trap
• Know when to escalate from autocomplete to a chat or an agent

---

How autocomplete works

As you type, the extension sends a window of context (the current file, usually some recently viewed files) to a model that predicts the next tokens. The prediction appears as faint "ghost text" inline; Tab accepts it, continued typing ignores it.

Examples (early 2026): GitHub Copilot, Codeium, Cursor Tab, Continue.dev, Microsoft Copilot in VS Code. Most agentic tools (Claude Code, Cline) do not provide ghost-text autocomplete — they're optimized for chat-and-agent interaction. If you want autocomplete and an agentic tool, you generally run two extensions side by side.

The model is small and fast on purpose; the latency budget is the time between your keystrokes, which is short. Don't expect the depth of reasoning you get from a chat-with-a-frontier-model — autocomplete is pattern completion, not analysis.

Where autocomplete shines

• Boilerplate you would have typed anyway. Loop scaffolds, function signatures whose shape is obvious, import lines, the body of a getter, repetitive variations of the same pattern.
• Filling in a pattern from context. If you've just written three similar dictionary entries, the fourth will autocomplete correctly.
• Local syntactic completions. Closing brackets, common method names on a known object, the rest of a familiar identifier.

The common thread: the model has all the information it needs in the few lines around your cursor, and the answer is mechanical.

Where autocomplete fails

• Anything that requires understanding a wider context. If the right answer depends on what a function in another file does, autocomplete will guess — and the guess looks plausible.
• Novel logic. If you are doing something the codebase has not done before, the model will pattern-match to something similar and produce confident-looking code that is subtly wrong.
• Anything where "correct" is non-obvious from the surface. Off-by-one indices, edge cases in numerical code, units, sign conventions, the precise contract of an API you are calling.

Habits that matter

Read the suggestion before accepting it

The cost of accepting wrong code that looks right is high. You will find the bug an hour later in a debugger when you could have caught it in 200 milliseconds. If a suggestion is more than a few lines, the right move is to read it, decide, and either accept or rewrite — don't Tab-and-pray.

A useful threshold: if the suggestion is longer than the comment or signature that triggered it, slow down.

Do not autocomplete your verification

This is the single most damaging autocomplete failure mode in scientific and engineering code.

Whether your verification is a formal unit test, a sanity-check script, a comparison against a known answer, or a hand-checked numerical result, it is supposed to be your expression of what the code should do. If the model writes the check based on the code, the check passes by construction and confirms nothing.

Write your check yourself; let the model help with the implementation. If you must use autocomplete in a test file, autocomplete the boilerplate (imports, fixtures, the test function signature) and write the assertion yourself.

Treat repeated rejection as a signal

If you find yourself Tab-rejecting (or ignoring and overwriting) the same kind of suggestion repeatedly for the same task, the model doesn't have the signal it needs. Stop reaching for autocomplete and either write it yourself or escalate to a chat where you can give the model the context it's missing.

When to escalate

Autocomplete is one rung of a ladder. Step off when:

Symptom	Escalate to	Why
You want a refactor or change to a block you can describe in words	In-project chat (section 04)	A one-sentence instruction lands better in a chat panel than as a comment-prompt to autocomplete
The change spans more than one file	Agentic delegation (section 05)	Autocomplete is per-cursor; agents handle cross-file work
You need to think through a design decision	Chat (section 04)	Autocomplete cannot reason; it can only complete
You keep accepting suggestions and then deleting them	Write it yourself	The model isn't helping; you are doing the work in two places

A historical note: inline edits

Older guides and tutorials (and the 2024-era marketing for Copilot and Cursor) put inline edit — highlight a block, press Cmd+K, type "make this async" — alongside autocomplete as the second main in-editor interaction. The pattern emerged in 2023 alongside instruction-tuned LLMs (ChatGPT, GPT-4), which were the first models that could reliably turn a natural-language instruction into a code transformation. It sat between the earlier completion-only era (autocomplete, powered by Codex and similar) and the agentic loops that followed. The hotkey still exists in most tools, but the pattern is fading because in-project chat does the same job with better context.

If you have highlighted code and a one-sentence instruction, an inline edit and an in-project chat message produce essentially the same diff. The chat panel just makes it easier to follow up, ask why, or refine. We don't teach inline edit as a primary workflow here. If your tool of choice still leans on it, the same one-sentence-spec discipline applies.

Habits that survive tool changes

The tools will keep changing. These habits do not:

• Read every accepted suggestion. Even short ones. Especially short ones in numerical code, where a sign flip looks the same as the right answer.
• Keep the cycle tight. If autocomplete is producing more than ~10 lines at a time for you, you are no longer reviewing in real time — you are reading code the AI wrote, which is a different mode.
• Use version control as a safety net. Commit before a stretch of heavy AI-assisted coding. git diff is the last line of defense.
• Verify with your own checks. The check has to come from you, not from the AI that wrote the code.
• Be willing to turn it off. Autocomplete is the right tool sometimes and the wrong tool other times. Toggling it off for a session where you want to think is a real productivity move.

Exercises

Exercise 1: For one work session, keep autocomplete on but make a conscious "accept / reject / rewrite" decision on every suggestion of more than one token. Note how often each happens. The exercise is not "reject more" — it is to make the choice visible.

Exercise 2: Take a small numerical or scientific function you've recently written. Use autocomplete to draft a verification check for it. Then write the same check by hand without looking at the function. Compare what each check actually tests — and notice which one is checking what you expected versus what the code does.

Exercise 3: Spend a half-day with autocomplete disabled. Note where you missed it (boilerplate, repetition) and where you didn't (anywhere you were actually thinking). The exercise is to feel the difference between the two modes of writing code.