FIF

Frequently Ignored Feedback

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.

“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 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 the Bash tool to execute malicious code.

“Make it so I can ask the model what model it is”

Don’t waste your time asking an LLM what model it is. LLMs often self-report their model name incorrectly. We gently nudge Amp’s model to refer to the Amp Owner’s Manual when asked about this, but we don’t want to use more system prompt tokens to force it, because that would degrade the performance of Amp and waste tokens that you could otherwise use.

“Add support for more editors.”

We don’t plan to create native extensions for editors other than VS Code (and forks thereof). Users of JetBrains can use the Amp CLI with JetBrains’ MCP server to enhance Amp’s code awareness, and we’ll document similar MCP-level integrations with other editors based on demand and quality.

“Let me bring my own Anthropic API key or use Amazon Bedrock.”

We tried hard to make this work but decided to remove BYOK permanently because it hurts quality and focus.