Momentum it said, and then it identified why this is a bad choice. Python’s str.replace() fails silently on no-match. Edit fails loudly. CC : No good reason — momentum, plus the convenience of batching several replacements into one call. It was a bad trade, and it cost real time in this session. Python’s str.replace() fails silently on no-match. Edit fails loudly. That difference bit me at least four times today:
- Threading separators through the parser — three endSegment() call sites didn’t match. I only caught it because a debug print showed every sep was null.
- The BLAME_JOIN on the items query didn’t match — surfaced later as no such column: ab.value.
- A replacement dropped const found = new Set() because my new text didn’t re-include it — surfaced as a TS error.
- The ARCHITECTURE.md processor row didn’t match, and I nearly told you it was documented when it wasn’t. That’s the worst one, because it wasn’t caught by a compiler — only by checking. Every one of those was a silent failure I had to discover indirectly. Edit errors immediately on no-match and on an ambiguous match, which is exactly the property I want when rewriting code I can’t visually verify. There’s an irony I should name: I’ve spent this session building a feature to measure fragile compound shell commands, while doing my own work through fragile compound shell commands — heredocs, a stale cd that broke one call, quoting traps. I was generating the exact data I was analysing. Switching to Edit/Write from here. The batching convenience isn’t worth losing loud failures. Are you all seeing this happen more often these days? submitted by /u/bhatbha
Originally posted by u/bhatbha on r/ClaudeCode
You must log in or # to comment.