As a User: Two Things I'd Ship for Claude Code
I use Claude Code every day. I've built projects in languages I was learning from scratch, and the tool made that possible.
But two design choices create friction that a tool this good shouldn't have.
1. I Can't Plan Without It Building
When I'm in a planning phase, I want to think — not ship. I'll type something like: "Discuss the tradeoffs between A and B. Write your analysis to docs/plan.md. Do not change any code."
Claude writes the file (sometimes) and then keeps going. New directories, modified source files, whatever it decided was the logical next step. I come back to a diff I didn't ask for.
So now I pepper every planning prompt with "no code," "STOP after writing," "do not implement." I've baked these into my CLAUDE.md. I've built custom slash commands specifically to enforce a boundary that should be a mode. It works about 80% of the time. The other 20% is reverts.
Gemini's CLI handles this cleanly — it creates a temporary plan file before executing anything. A checkpoint. "Here's what I'm about to do." If it's wrong, you catch it before a single file changes. That's not a capability difference. It's an interaction design choice, and it's the right one.
2. Enter Submits
In Claude Code's terminal, Enter sends your prompt. New line is Shift+Enter. Most people expect the opposite — Enter to keep writing, a deliberate action to submit.
When you're composing a careful multi-line prompt — especially one with "do not implement" instructions — accidentally submitting halfway through means Claude takes off with half an idea. Paired with problem one, a stray Enter key kicks off changes you didn't want from a prompt you didn't finish.
That's it. Two things. The tool is genuinely great, and these are the two places where I'm fighting it instead of using it.