What 157 Developers Really Think About Kilo Autocomplete
Insights from 157 developers using Kilo Autocomplete in the wild.
Exactly one month ago, we enabled autocomplete by default for new users in the VS Code extension.
One month later, what do Kilo users think about autocomplete?
To find out, we ran a survey where 157 Kilo users answered a few questions about whether—and how—they find autocomplete useful.
The results were encouraging. Most developers accept suggestions regularly, and they’re not just filling in obvious lines; they’re writing documentation, refactoring code, and generating tests. The language spread was wider than we expected too, from Python and TypeScript to Rust, Flutter, and C#. Autocomplete has become a core part of how developers work.
People Use Autocomplete for More Than “Filling in Obvious Lines”
Survey question: “In what contexts do you primarily use autocomplete?”
What we learned: When asked about their main use cases for autocomplete, responses fell into two distinct categories.
The most common uses were low–cognitive load tasks where the next step is predictable:
Filling in obvious lines (81)
Fixing errors as I type (52)
Boilerplate or scaffolding (47)
But users also rely heavily on autocomplete for higher-value tasks that require more context and thinking:
Writing documentation (51)
Refactoring or code transformations (49)
Writing tests (28)
API usage and calling libraries (25)
Our autocomplete performs well at contextual suggestions, and users are clearly taking advantage of that capability.
The spread across both categories shows that people see autocomplete as useful for much more than just boilerplate.
90%+ of Users With Autocomplete Enabled Use It Regularly
Survey question: “How often do you accept autocomplete suggestions?”
What we learned: Acceptance rates suggest a pattern of “cautious but consistent” adoption.
Most respondents said they accept suggestions often (52) or sometimes (46), meaning they typically accept around 20–80% of the suggestions they see.
Only 20 people reported accepting suggestions almost always (>80%), while just 9 said they rarely accept them. No one selected almost never.
This distribution suggests users have found a productive middle ground. They’re not blindly accepting everything, but they’re also not fighting autocomplete.
The near absence of “rarely” and “almost never” responses implies that people who keep autocomplete enabled generally find real value in it, rather than leaving it on and ignoring the suggestions.
Developers Are Using Autocomplete in Programming Languages We Didn’t Expect
Survey question: “What programming languages do you use autocomplete with most often?”
What we learned: Autocomplete usage is heavily concentrated in dynamically typed and web-focused languages. TypeScript/JavaScript (72) and Python (64) account for most responses, followed by HTML/CSS (37) and Markdown (18).
The strong showing for HTML/CSS and Markdown suggests autocomplete isn’t just for “real code”; people also find value in speeding up repetitive markup and documentation work.
Statically typed systems languages saw lower adoption: Java (11), C# (10), Go (9), C/C++ (4), and Rust (4). This may reflect either lower representation in the survey or the fact that these languages already benefit from mature IDE tooling, such as strong type inference and language servers, which reduces reliance on AI autocomplete.
The “other” responses reveal an interesting long tail. Infrastructure-as-code tools like Terraform and YAML, mobile and cross-platform frameworks (Kotlin, Flutter), and niche languages (Lua, Scala, Robot Framework) show that users are pushing autocomplete into more specialized domains beyond mainstream web development.
All this suggests that autocomplete is already being used across a vast number of programming languages and frameworks.
How We Plan to Make Autocomplete Even Better
Our focus for 2026 will center on three key areas:
Speed. Autocomplete is already fast, but we want to make it as fast as humanly possible. We ship with speed, and we want the same experience for you.
Affordability. You can already use autocomplete through the Kilo Gateway (which takes 0% markup). We plan to make it easy to bring your own key (BYOK) through the gateway, so you can take advantage of free tiers and discounts that model providers offer directly.
Transparency and model choice. Autocomplete currently uses Codestral as the default model. After testing dozens of models, we found it offered the best balance of speed, accuracy, and contextual understanding. As we continue testing, we expect to identify additional strong candidates, giving you the flexibility to easily switch the underlying autocomplete model.
Is there another feature you’d like us to add to make autocomplete even better? Let us know in the comments below!
Really smart approach to actually survey users on how they're using autocomplete. The finding that people lean on it for documentation and refactoring surprised me a bit - I always assumed those were tasks where you'd want more conscious control. But thinking about how I work, yeah, having suggestions for JSDoc blocks or renaming patterns would actually cut down on the boring bits while you focus on logic. One thing I'd be curious about is whether acceptance rates vary by task complexity or if its more just ahabit thing once you trust the tool.
Please add a custom system prompt feature for autocomplete.
The fact that autocomplete usage is primarily concentrated in dynamic types and web-related languages is likely because most LLMs possess stronger capabilities in these fields. Consequently, developers in these areas are more likely to feel that code completion already meets their needs.
Many evaluation organizations have conducted independent tests showing that most LLMs perform better in dynamic types and web-related languages while remaining relatively weak in other domains. This is a general tendency that may be related to the training data or the logic inherent in the programming languages themselves.
However, system prompts can significantly influence an LLM's performance. In the current workflow, I feel that the prompt used is a generic one rather than being tailored to different languages.
If a custom prompt feature can be implemented, the effectiveness of the autocomplete function would improve across various scenarios, and the range of applicable use cases would be expanded.