Jeremy Sullivan

Claude Code was asking me to approve way too many things. Every time it edited a file, I'd get a "this command requires approval" prompt. Sometimes three in a row for a single task. Turns out it was writing Python scripts and sed commands just to make simple file edits — because that's the habit it defaults to. Claude Code actually has native Edit and Write tools that bypass Bash entirely. No shell process, no approval prompt. But without explicit guidance it doesn't reach for them first. The fix is a ~/.claude/CLAUDE.md — a global instruction file Claude Code reads at the start of every session. You tell it exactly which tool to use for which job, and pre-approve a handful of safe utilities (sd, ripgrep, jq, yq) in settings.json so the ones that do use Bash don't interrupt your flow. One other thing I learned: sd (a modern sed replacement) still processes files line by line, so multiline pattern edits silently fail and Claude falls back to Python. The right call there is always the native Edit tool — which works on the full file buffer and handles multiline matches natively. Put together a Gist with the full CLAUDE.md and setup instructions if you want to steal it: https://lnkd.in/g62h4fUP The approval interruptions dropped dramatically after this. Worth 10 minutes to set up.

36

7 Comments

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

14

3 Comments

In large technology transformations, the most dangerous decision is often the one that looks “cleanest” on paper. I’ve seen teams rush toward full rewrites of legacy systems because the architecture feels messy, outdated, or hard to reason about. In practice, the safer question is rarely “What’s the best design?” It’s “What keeps options open if we’re wrong?” Incremental extraction, controlled reuse, and preserving operational continuity may look inelegant—but they dramatically reduce irreversible risk. Senior technology decisions aren’t about elegance. They’re about survivability under uncertainty

33

2 Comments

We don’t talk enough about this kind of leadership. Last week, forgecode shipped a feature that degraded response quality. Instead of hiding it, they: - Admitted the mistake publicly - Explained what went wrong - Fixed it promptly In the AI space, it’s easy to chase growth at all costs. But accountability is what builds real trust. The companies that own their mistakes and put customers first? They’re the ones that will win long-term. We need more of this energy in tech.

24