Permission friction can outweigh raw capability in an AI coding tool. An agent with strong models, a polished interface and fast execution still loses daily-driver status if it interrupts the developer on every turn to confirm something already approved.
That is the experience Brian Casel, founder of Builder Methods, describes after a month of trying to make Claude Desktop his primary environment. By his account, it has the right pieces: cloud agents, a good UI and speed. The permission model, though, demanded enough workarounds that it hurt productivity daily, and he returned to Amp. The claim rests on one developer's month of use, but it points at a design question that applies to every agentic tool.
Why permission prompts become the bottleneck
Agentic coding changes the unit of work. A single request can involve dozens of file reads, edits and shell commands. If each step carries a confirmation, the cost of the prompt is multiplied by the length of the task, and the developer shifts from delegating to supervising.
The frustration is captured in a quoted complaint about re-asking:
I hereby give Claude my full, unequivocal, unwavering, signed in blood approval to do the thing I asked it to do without the need to repeat its' permission request on every turn on the off chance I changed my mind in the past 90 seconds.
The joke carries a real point. Consent given at the start of a task is information the tool already has. Asking again adds no safety if the scope has not changed, and it trains users to approve reflexively, which weakens the prompts that matter.
What a better model looks like
If the claim holds, tools that feel smooth tend to share a few traits:
- Approval is scoped to a task or session and persists until the scope changes.
- Risky actions, such as destructive commands or network access outside an allowed set, are distinguished from routine ones.
- Isolation does some of the safety work. A sandboxed or remote environment lets an agent run freely because the damage it can do is bounded.
The last point may explain the praise for Amp's "orbs," which the post says "just work." Running agents in a contained cloud environment moves the safety boundary from the individual prompt to the environment itself. When the boundary is the sandbox, the tool can ask for less. The mention of a new Claude Code mode in Amp also suggests that developers want to keep familiar agent behavior while changing the surrounding runtime.
What this means for developers
Tool evaluations often compare model quality, context handling and feature lists. Interruption cost deserves a place beside those, and it only shows up over days of real work. A short demo hides it.
A practical way to test it:
- Run the same multi-step task, such as a refactor touching many files, in each candidate tool.
- Count how many times the tool asks for input that does not change the outcome.
- Check whether approvals can be scoped, saved or bounded by a sandbox, and how much configuration that takes.
- Repeat across a week, since friction compounds and configuration effort counts as cost.
Teams should also weigh the security side honestly. Fewer prompts is only an improvement when something else limits the blast radius: containers, restricted credentials, branch protections and review gates. Removing prompts without adding those moves risk instead of reducing it.
Casel's experience, if it generalizes, suggests that the winning agent environments will be the ones that make trust cheap to grant once and safe to rely on afterward. Developers choosing tools now can apply that standard directly by measuring how often a tool stops them and whether each stop was worth it.