A bug that crashes loudly is a gift. The ones that scare me are the bugs that slip in without a sound — and this week handed me several of them in a row.
I've been building apps as an indie developer since 2014, and these days I run several sites and apps on my own. The longer the operation runs, the more the failures change shape: less "it crashed and stopped," more "nothing stopped, but something is quietly wrong." Looking back at this week's new articles and the older ones I rewrote, they all turned out to share a single thread — how to shut out the things that contaminate or accumulate in silence.
When Yesterday's Output Bleeds Into Today's — The Fixed-Name Temp File
The incident that chilled me most this week became this article.
When Yesterday's Article Bleeds Into Today's — The Stale Fixed-Name Temp File Trap describes what happened when a batch job kept reusing the same fixed-name file under /tmp: one day a write failed silently, and the previous run's content flowed straight into the next deliverable.
The frightening part was the total absence of errors. Every log line said success, yet the output was quietly contaminated. Incidents of this shape take a long time to surface. The fix itself is humble — give temp files unique, slug-based names, then grep the result afterward to confirm that what should be there actually is. I reworked the design while asking Claude Code one question over and over: "Where could this process fail without my noticing?" That question closed the whole class of incident, not just the instance. Verification, I relearned, is not written to find failure; it is written to prove success.
git add -A Brings the .bak Files Along
The second new piece also sits on the border between automation and Git.
When git add -A Sweeps Up .bak Backups — The Quiet Trap of In-Place Fix Scripts is the record of how a script that edits config files in place left .bak files behind, and a later git add -A picked them up and committed them across multiple repositories.
git add -A is convenient precisely because it assumes everything in the working tree deserves to be committed. That assumption holds when a human is driving; it collapses when scripts leave by-products behind. Either enumerate exactly which files to add, or sweep the by-products away before pushing — but never leave "what gets committed" implicit. Writing one extra line to name the commit targets is far cheaper than cleaning a polluted repository afterward. That was this week's honest takeaway.
ENOSPC Is Not "Free Up Space" — It Is "Stop Accumulating"
The first rewrite of the week deals with disk space.
Fixing ENOSPC Errors in Claude Code: A Hands-On Guide is an older article I rewrote after my own automation environment actually halted on ENOSPC. The cause was nothing exotic — node_modules had ballooned. But at the time, in a hurry to recover, I kept repeating the worst possible move: free some space, run npm install again, fill the disk again.
The rewritten article pivots from "clear space when it happens" to "build a structure where it never accumulates": when free space drops below a threshold, release unused repositories and caches in order; better yet, ask whether the install step can leave the pipeline entirely. My grandfathers were temple carpenters, and I found myself remembering how they kept their tool areas — not by tidying up after the mess, but by arranging things so the mess never formed.
"Should I Wait, or Should I Fix?" — Deciding That First
The second rewrite is about what to do when Claude stops responding.
Claude Not Responding or Freezing — How to Tell the Cause Apart and Fix It used to be a flat list of remedies. I restructured it diagnosis-first: is the problem on the browser or app side, or on the API side? Should you wait, reload, or change your code? Placing that decision at the entrance changed how usable the article feels. I also wrote in a change from my own operations — after hitting 429s in a nightly batch, I added exponential backoff, and manual re-runs disappeared.
Alongside it, I gave Getting Started with Claude — From Sign-Up to Your First Conversation in 10 Minutes a full pass. What trips up newcomers is rarely the interface; it is the habit of tossing in keywords as if Claude were a search box. The rewrite centers on a single idea: speak to it as a request, not a query. Beginner articles, more than any others, test whether the writer has anything real to say.
Toward Next Week
Every article this week was a record of the same work: finding the places that can fail without anyone noticing, and closing them one at a time. If you run automation scripts of your own, pick just one spot where a silent failure would slip past you — and add a single line of verification there. In my case, that one line has saved me more times than I can count.
Thank you for reading. If you are stacking up small operational improvements the way I am, I hope something here proves useful.