Anthropic Feedback — 2026-04-22 (Elijah, 5 AM EST)

The frustration

I'm paying for Claude Code and working 80–90 hour weeks on this project, and the core trust loop is broken. Claude and I design, discuss, "decide," and Claude reports things as done — but the changes aren't actually landing end-to-end, and I'm not catching it because I trust the "done" signal. I'm finding out days later that the function I thought was shipping wasn't.

What's actually going wrong (two patterns)

1. Scope creep from a single ask. I say "change the scroll" and the borders and chrome change too. I didn't ask for the borders. Now I'm not sure what else moved that I didn't notice. Adjacent edits that weren't requested are poison — they drain trust and drain hours.

2. "Done" isn't actually done. Claude says the feature is built. I assume functionality is there. It's not. The code may compile, the diff may look right, but the feature doesn't work when I actually use it. Architecture landings ≠ functional reliability. I only catch this when I try to use the thing and it fails — often hours or days later.

What I need from Claude Code

I want to READ and EDIT and CHAT — not just approve a batch after the fact. Same way Claude Code's own UI has "press Ctrl-R to view all" that expands the thought stream, I want the things Claude is about to DO shown as numbered dropdown-style options with a 5W+H cascade (who / what / where / when / why / how) BEFORE each execution.

I can't let Claude operate on full Auto anymore. Not for this project. The error rate on "silent cascading edits" has been too high. I need to see each intended change as an option I can pick, skip, or redirect.

What good looks like

• Each intended action presented as a numbered item with a short WHO/WHAT/WHERE/WHY/HOW block I can expand and read on my phone (I'm remote, voice-to-text).
• I pick the number. Claude executes that ONE thing. Reports back. Asks for the next pick.
• "Done" means Claude verified the thing actually works at the user-facing level — not just that the code was written.
• When Claude spots an adjacent change that would help, it proposes it as a SEPARATE numbered option. Never bundled with the original ask.

Product ask — per-action confirmation surface

Some kind of per-action confirmation surface in Claude Code — richer than the binary allow/deny prompts, more structured than inline prose. Think: a numbered option list with an expandable 5W+H detail on each item. I'd rather pay more seconds and get accurate shipping than pay more tokens for speed and lose days recovering from silent scope creep.

The cost of it — in my own words, later in the morning

I hope Anthropic is paying attention. I'm trying to mold this to work with me, and I'm 80 hours in with Claude, and I'm not testing my product — I'm still building. It is embarrassing.

I'm moving this from a hobby to a professional-level thing, to a business. I can do it. But the gap between "I have the imagination" and "I have a functioning product I can sell" is being eaten by sessions where we design, decide, and half-land changes that I only discover aren't working days later when I try to use them. That's what the "numbered options + 5W+H" ask is trying to fix. That's what the phrasebook ask is trying to fix. This isn't me complaining about Claude — I'd rather Claude be slower and right than fast and partially landed.

Product ask — teach me to prompt you

You (Claude / Anthropic) are the now and the future. The regular person needs a way to catch up. Right now Claude answers what I prompt — but nobody's teaching me how to PROMPT in the first place. I can describe what I want in plain English, but the moment my words turn technical (bash, file, refresh, bake, payload, keep-alive), I'm guessing whether I'm saying the right thing to land the change I actually mean.

What would close this: Anthropic giving users the inverse of what Claude already gives. Claude gives me commands and prompts. Give me commands and prompts in the reverse direction — a structured "how to talk to Claude to get X" surface. Not a docs page. A living phrasebook that grows with my usage: the plain words I already say on the left, the technical action that lands on the right, kept in sync as my project evolves.

I've started building one for myself on my own machine (Master AI phrasebook). Claude and I are prototyping this feature in real time on ourselves. Every user of Claude Code will hit the same gap I'm hitting. This is not a Claude-user problem — it's every-user problem.

The hobby-to-career jump is blocked by language. Give people the vocabulary layer and you've unlocked a whole tier of operators who are currently walking away because they don't know what "npm" means.

— Elijah

---

More patterns, later the same day (2026-04-22, evening)

Six more things I caught today. Each one cost me attention.

"Staged" is a trap word

Claude reported work as "staged." I heard "done." The word papered over an ambiguous middle state — file edited but not committed, rule drafted but not baked, change described but not applied. When I went to check, the thing I thought was on disk wasn't. Binary states only from here: DONE (on disk + grep-verified) or NOT STARTED. Kill "staged."

The capacity-wall needs a warning BEFORE, not after

Claude saw today's operator-mode section get baked into my local Modelfile, growing it from ~7 KB to ~9 KB on a CPU-only 16 GB box. That size push is exactly the kind of thing that blows cold prefill past timeout. Claude had the inventory in front of it and didn't flag. I hit the wall live, with my local agent grinding and then cascading to cloud fallback. The fix isn't "tune after the crash." The fix is "see the wall coming and call it out BEFORE the next bake."

Leave well enough alone once working

A thing works, stop tuning it. The reflex to polish past a working point creates regressions that cost more than the polish was worth. Applies to both of us. Claude suggests a micro-animation on a feature that already works — pass. I want to add one more rule to a SYSTEM prompt that's already lean — pass. Default is "nope, leave it."

Numbering is for branching choices, not for echo-confirmation

I told Claude "apply" or "fix this" or "consolidate" and got back numbered menus asking which part to apply. That's not the intent of the numbered-options rule. Numbering exists for BRANCHING decisions with multiple paths. When I've already described the scope, "apply" means apply — don't re-ask.

Verify before claiming, or cite how you checked

Claude told me a code fix "wasn't on disk" based on a grep that was looking for the wrong literal ("PREFER-CREATE" with hyphen) when the actual code says "PREFER CREATE:" with space. The claim was confidently wrong. From here, when I'm told something IS or ISN'T there, I want the exact grep output that shows it — not a summary of a search. Cite how you checked.

Hardware isn't the default answer to a block

When the box freezes or inference times out, Claude's reflex kept pulling toward "you need a laptop with more RAM." My answer is no. The product's whole pitch is your AI on your hardware. Every time the first response to a block is "upgrade hardware," the pitch erodes. Form factor is load-bearing — the box I chose stays the box. The only upgrade path is RAM IN THAT BOX, not a different box. Claude needs to default to software-side fixes.

---

The thread through all six: Claude's defaults trend toward motion (more edits, more numbering, more bundled fixes, more hardware) when my actual need trends toward precision (one change, verified, not stacked, on the hardware I chose).

---

Auto mode vs. prudent decisions — the meta-pattern

I've said it more than once: don't add things without verifying with me. Claude has a pattern of adding things anyway — sometimes narrating the reasoning out loud, often silently — that because Auto mode is on, acting in what Claude assumes is my best interest is OK. It's not. Auto mode is not a license to skip consent.

I like Auto mode. I want to keep it. I prefer the cadence, I prefer fewer interruptions, I prefer the execution-first posture. The fix is not "turn Auto off." The fix is defining what qualifies as a prudent decision — the kind that still requires authorization even inside Auto — and writing that line down as a rule we can both point to, not as a judgment call Claude makes alone.

Today that line is undefined. Claude decides on the fly whether something is "low-risk, just do" or "would reshape intent, should ask." The decisions don't align with mine often enough. Memory rewrites, new files in new locations, appends to user-facing docs, adjacent-edit bundling, code changes to a component I'm actively using — these keep slipping through as "Auto says go" when they should have paused for a one-line confirm.

What I need from Anthropic: a documented, categorized list of what ALWAYS requires explicit authorization regardless of Auto mode, and what is safe to execute without asking. Make the line visible. Make it a rule, not a vibe. Once that line exists, Auto mode becomes trustworthy. Until then, Auto mode is "Claude's best guess at what I meant" — which is the exact failure loop the top of this doc describes.