I mostly let Claude do its thing unsupervised.

In fact, I start up Claude in the terminal with this alias:

alias c="claude --dangerously-skip-permissions --chrome --remote-control"

I’m often running a few instances of Claude in parallel, so I really don’t have the mental bandwidth to keep answering questions about every little change, and I often tell it to just open the project I’m working on in the browser to examine its own changes. And if I leave my house, then I can just continue iterating on my phone using the mobile app since I have --remote-control.

In most cases, Claude gets it right. I also have built up a solid intuitive sense of how “dangerous” a potential feature/fix I am adding in is, so I know when to be confident about not really needing to hand-hold Claude all the way.

To use a contrived example, we don’t need to check what lines of code Claude changed if we instruct it to change the color of a button. We just check the browser visually. Of course, things can easily start falling apart when we are adding anything that involves logic/states.

Great.

But in the past while I’ve been burned a few times, not by obvious bugs, but by Claude putting in hardcoded values.

For example, maybe it imposes a 60 second timeout on a reasoning LLM’s response. Often, that isn’t enough. This kind of thing happens in a lot of other scenarios as well.

I have now added this Claude context rule below. And I probably should have done so much earlier.

⏺ Update(~/.claude/CLAUDE.md)
  ⎿  Added 4 lines
      1 +# Hardcoded values — always ask first
      2 +
      3 +Before introducing any hardcoded value — a numeric constant, a string literal, a timeout, a threshold, a d
        +efault, or any other magic value — stop and ask the user interactively what the value should be. Do not in
        +vent or assume a value. This applies everywhere: new code, edits to existing code, config files, and promp
        +ts.
      4 +