AI autocomplete: suggesting without getting in the way

What is it, and how is it different from other help?

It is the smallest form of inline AI. Unlike a “rewrite” button or a chat, it does not ask for an explicit action: the suggestion appears on its own, based on what was just written. That makes it fast, and also easy to make annoying.

The best-known examples are in two places. In email, Gmail Smart Compose suggests text as you write. In code editors, assistants such as GitHub Copilot and Cursor Tab propose anything from a line to a whole function. In all of them the suggestion is shown dimmed and accepted with a key.

How do Gmail, Copilot and Cursor do it today?

All three share the same idea, but the details differ. This is what the official documentation says, checked on November 3, 2026:

In Copilot for VS Code, other default shortcuts are Alt+] and Alt+[ (Option on Mac) to see the next or previous suggestion, and Alt+\ to request a suggestion manually. More detail in GitHub Copilot and Cursor.

How is ghost text designed?

Ghost text is the presentation of the suggestion inside the field itself. The design decisions are few, but each one changes the experience:

• Contrast. It must be visible enough to read but not so strong that it looks like written text. A medium grey usually works. If it can be mistaken for real text, people will accept it by accident.
• Partial acceptance. Letting users accept one word or one phrase, not only all or nothing, lowers the cost of a suggestion that is only partly right. Cursor does it with a word-by-word shortcut.
• Natural dismissal. Continuing to type should dismiss the suggestion without extra steps. If the user has to close something to keep writing, the suggestion is in the way.
• Timing. A suggestion that arrives after the person has already written what they meant is no help. The Smart Compose paper describes an infrastructure built for real-time inference. Response streaming does not help here: the text has to be ready instantly.

Why does it matter to a designer?

Because autocomplete is a case where AI works at the pace of writing. A bad suggestion does not feel like a bad answer. It feels like a distraction, and it happens dozens of times in a session.

The available studies show that value is not automatic. In a University of Mississippi study with 119 participants, people who used Google Smart Compose produced the same amount of text in a 25-minute task as people who wrote without it. Participants took longer to read and accept a suggestion than to edit or reject it; one of the researchers reads this as caution. The researchers note these were short tasks on a single topic, and plan to repeat the study. The result does not say the feature is useless; it says that saving keystrokes is not the same as writing better or faster in every case.

For coding assistants, a Zoominfo study with more than 400 developers measured, between November and December 2024, an average acceptance of 33% of suggestions and 20% of suggested lines. The authors admit the limits of that metric: a partial acceptance counts as full, and a one-line suggestion weighs the same as one with hundreds of lines. That is why acceptance rate alone is not enough.

How do you apply it in a product?

A healthy autocomplete has four starting rules:

1. Measure per task, not per click. The useful question is whether the user finished sooner or with fewer corrections, not only how many suggestions they accepted.
2. Record what happens afterwards. Accepting a phrase and then deleting it is a signal of a bad suggestion. Measure later editing alongside acceptance.
3. Offer a way to turn it off. Some people write better without suggestions. Gmail, Copilot and Cursor all include that control; a visible, easy-to-find switch respects that choice.
4. Respect the type of text. In a formal email or a contract, a suggestion that shifts the tone can be worse than none.

When NOT to use autocomplete

• When precision matters more than speed. In legal or medical content, a plausible but wrong suggestion can slip through unnoticed.
• When the user thinks while writing. Drafting an essay or exploring an idea needs quiet. Constant suggestions break the train of thought.
• When the help can’t be short. If the help requires explaining, comparing or asking for a decision, a chat or a form usually works better.
• When typing is not the bottleneck. If what is slow is thinking, not typing, autocomplete does not solve the real problem.

Example

Illustrative example: a note app for designers that offers autocomplete in report bodies. The user types “The onboarding flow has three steps, but the second one” and faint text appears: “asks for data before showing any value”. They can accept all of it with Tab, accept a single word with a shortcut, or keep typing and the suggestion disappears. If the team finds that half of the accepted suggestions are deleted within a minute, they know the suggestion looks right but isn’t, and they adjust the model or the context sent to it.

Common mistakes

• Showing the suggestion in the same colour as the real text.
• Measuring success only by acceptance rate, without looking at later editing.
• Not allowing partial acceptance.
• Turning autocomplete on in every field, including those where people write short or fast entries.
• Letting a suggestion change an important fact (a figure, a name) without the person noticing.
• Copying one product’s shortcuts without checking them: Tab is the common one, but the rest changes between editors and versions.

Sources

• Gmail Smart Compose: Real-Time Assisted Writing (Google Research, KDD 2019)
• Use Smart Compose in Gmail (Gmail Help)
• Experience with GitHub Copilot for Developer Productivity at Zoominfo (arXiv:2501.13282)
• Researchers study implications of Google Smart Compose (University of Mississippi)
• Getting code suggestions in your IDE with GitHub Copilot (GitHub Docs)
• GitHub Copilot keyboard shortcuts (GitHub Docs)
• Tab overview (Cursor Docs)