FIF

Our responses to some common feedback that we are intentionally not acting on. Note that we may change our minds here; this is just our current position.

“Make it so Enter, not Cmd/Ctrl+Enter, submits the message.”

We think that Cmd/Ctrl+Enter as submit nudges people to write better, longer prompts. (There is a setting to change this that you can probably find, but no promises it’ll stick around.)

“Make it so the user can switch models.”

We believe that building deeply into the model’s capabilities yields the best product, vs. building for the lowest common denominator across many models.

“I don't want it to edit files directly.”

Requiring edit-by-edit approval traps you in a local maximum by impeding the agentic feedback loop. You’re not giving the agent a chance to iterate on its first draft through review, diagnostics, compiler output, and test execution. If you find that the agent rarely produces good enough code on its own, instead of trying to “micro-manage” it, we recommend writing more detailed prompts and improving your AGENT.md files.

“Don't show all the noisy work the agent is doing, just hide it and show me the final result.”

We believe that hiding it all sets expectations too high about how well it works. We also get much better feedback from users when they see its work, and high-quality feedback is extremely valuable.

“Make it so I can make my new threads private (not shared) by default.”

We believe that shared by default results in more threads being shared, which is an important benefit of the product. It reduces the expectation that your threads are “perfect” or “not dumb” if everyone knows the default is shared. It is akin to Google Docs “sharing” edit history by default, or GitHub “sharing” your Git branches by default.

“Show me how much my thread cost.”

Making the costs salient will make devs use it less than they should. Customers tell us they don’t want their devs worrying about 10 cents here and there. We all know the dev who buys $5 coffee daily but won’t pay for a tool that improves their productivity.

“Make it so threads are automatically compacted and I do not have to worry about the context window.”

We think this reduces quality and creates an inconsistent experience (devs wondering why the agent suddenly got dumber and not realizing it’s because they just hit an auto-compaction threshold). We would do this if we find a technique that provably doesn’t hurt quality. In the meantime, we offer a manual way to do it.

“I want to be able to restore to previous points in the conversation and throw away the changes.”

We believe that a lot of the restore/checkpoint features in other IDEs/text-editors are a left-over from the pre-agentic world in which you explicitly apply/accept certain snippets of code and the model you were talking to couldn’t access your codebase. With agents that explore your code, though, things become trickier: if you revert changes that the agent made, then the agent now has a different ‘view of the world’ (it thinks its change was made) and that will confuse it and lead it off track. And if you revert the changes and then tell the agent about it, the question is: was that worth it? Because the agent can also undo changes on its own. In fact, you can tell the agent “undo the change in foobar.svelte” and it will undo the last edit.

“I want the agent to make Git commits.”

Our current thinking is that we want to give the agent as much freedom as possible. It should be able to run commands, edit files, and so on. But that means we want to always have the security of our VCS in the background. So for now, we don’t want the agent to touch the VCS on its own. You can tell it to make commits, sure, and tell it to open PRs, but we don’t want to mess with our staging/commits on its own.

“Add more safety controls or configurability over shell commands that it runs.”

We are (currently) NOT trying to protect against a malicious actor prompt-injecting something that causes run_terminal_command to execute malicious code.