First user tests and the paperclip problem
From cursing at a model to boost performance to making it easier to attach files
After our launch last week, we just completed our first round of in-person user tests, and we want the community to know exactly what we're addressing right now. Interestingly, we noticed one of our users cursing at a model while we were doing the tests, which seems like an interesting way to improve model performance.
We’re not here to judge you (or your prompts) but to hear your honest feedback, so don’t hesitate to share your thoughts.
Our goal is to fix ten community requests by the end of this week, and we’re still on track, but we can’t do it without your feedback, so if you have any requests for us, submit your ideas or bugs. 🪲
The paperclip problem
Clear visual clues (affordances) are critical in user interfaces. From speaking to real users, we noted they were looking for the famous paperclip to attach files in the context window, but it was nowhere to be found. The simple way to attach code is by typing the shorthand “@” and then choosing what type of context you want to add, which might be folders, files, commits, or URLs. Easy, right? Well, no.
We submitted a PR to fix this issue in our Cline/Roo fork because 3/4 of test users complained. We’re also working on drag-and-drop support to add context quickly. Ideally, you won’t need to (manually) add files to the context in the future, and hopefully, there will be no need to worry about the paperclip problem any time soon, either.
The agent—at the right, please
Cursor/Copilot users will agree that it’s more convenient to have an AI coding agent on the right and your files/git on the left. Users have told us this: they want to keep the flexibility of using the left tab as they please and see files/git all the time, but what if we make this a default setting? We want to hear your thoughts, but from our users’ first interviews, everyone seems to prefer to keep the assistant on the right.
Walls of texts
When using Kilo Code, asking permission for certain actions is crucial. We offer automatic acceptance for some actions, but there are still a few cases in which you must manually accept for obvious reasons.
As models become more verbose and have bigger output windows, they provide better performance by extended thinking. Still, they can also be overwhelming if the UI is not managed properly. Should we spend our time reading: thinking traces?
Our early beta testers complained that it’s very cumbersome to find something between walls of text and expect them to approve something to keep going. This excess of information produces confusion and makes the workflow tedious for our users. We tried simplifying the UI/UX, making the thinking traces and details collapsible by default.
Another recurring problem is the non-persistence of the settings. For example, when you want Kilo Code to auto-approve certain actions without confirming them, a bug prevents them from being persistent. We fixed that, so now you can auto-approve sudo commands and see your computer catch fire.
We also added a feedback button, so now you can complain directly to us :)
Simplify the user experience
We've discovered some interesting insights from our beta testers that we hadn't caught in our internal testing. It's amazing how much you can learn from one-on-one sessions.
Kilo Code takes the YC motto seriously: just write code and talk to users.
Some issues our testers found:
When pasting a URL (like docs with www), Kilo Code opened a browser to scrape screenshots instead of just copying and adding text to the context window
But also:
I don’t want to think about pricing on every interaction; cost info is distracting. I suggest a “verbose” mode for cost visibility and other details.
As you can see, we still have plenty of things to figure out.
Bugs, bugs, and more bugs
A user recently opened an SSH connection with VS Code and tried to use Kilo Code while Justin and I watched closely:
This is how I usually work. I like to connect to a more powerful machine on a remote server. Let me try to execute some commands.
We quickly realized that Kilo Code wasn't functioning properly over SSH connections. It was a bit embarrassing, but the user was still eager to try Kilo Code locally instead.
Another user encountered an issue when working with a large codebase:
When I attempt to read a file, there's no way for me to restrict the number of tokens in the file I'm passing, which results in my context window being maxed out and causing errors
Recently, Tijs Teulings submitted an issue when trying out the newly released Gemini 2.5, and we’re still investigating:
While using Kilo was fine on my M4 macbook Pro on my M1 it's quickly draining all the resources to the point where VSCode becomes totally unresponsive.
We know there’s a lot of work to do to be the best coding agent, and we’ve just started.
We’re actively trying to discover these issues and would love to hear more about your own problems. So the next time, you don’t need to yell at your computer too much to make it work properly. 👀