Dev Notes
Dev Notes: June 8, 2026
One change to a GitHub Action took down code review for the whole company last week. Not the kind of down where nothing runs. The worse kind, where everything runs and never finishes.
We have an action that runs an AI review on every pull request across the org. Someone shipped what looked like a safe improvement: stream the output, and block the AI from running a shell tool it didn't need. Reasonable. Locking down a tool's permissions is usually the careful move.
Instead, review jobs stopped terminating. What used to take about five minutes ran for 18 to 22 and kept going. Every PR. Every team. Then the fix to remove the shell block broke how the action loaded, so the second change made things worse before the third one, a job-level timeout, finally pulled everyone out.
Here's what stuck with me. We added this tool because it made review faster. We never gave it the boring guardrails we give real infrastructure. No timeout. No ceiling on how long a single run could burn. It sat in everyone's workflow as a convenience right up until it was the thing blocking everyone's workflow.
AI tooling crossed into infrastructure faster than we started treating it like infrastructure. The moment a tool runs on every PR, every deploy, or every commit, its failure stops being an inconvenience. It's an outage. The unglamorous parts (timeouts, blast-radius limits, a kill switch) aren't optional once the blast radius is the whole org.
Treat your AI tooling like it can take down production. Because the day it runs everywhere, it can.
This Week on Slightly Caffeinated
No new episode this week. TJ and I will be back in the studio next Saturday with a fresh one. Catch up on past episodes at slightlycaffeinated.fm while you wait.
What I'm Learning
I found eight end-to-end tests this week that had passed on every PR for months without ever running.
The tests checked out a single repo in CI. The fixtures they needed lived in other repos that CI never pulled, so the suite quietly skipped all eight and reported green. Nobody noticed, because a skipped test and a passing test look almost identical in the summary. The checkmark was real. The coverage wasn't.
The fix was boring: commit small fixture repos into the test setup so the tests actually have something to run against. Now they run on every PR, and two of them caught a real bug the next day.
The takeaway: check your skip counts, not just your pass counts. A test that can't fail isn't protecting you. It's decorating your CI output.
Dev Tool of the Week
A command-line tool for setting which app opens which file type on macOS.
If you've ever set "Open With," hit "Change All," and watched macOS ignore you a week later, duti is the fix. It sets defaults by file type, so you can point every Markdown file at your editor and have it stick. A one-off looks like this (I send mine to Zed):
duti -s dev.zed.Zed net.daringfireball.markdown all
The better move is a config file you keep in your dotfiles. One line per rule, each with the app's bundle ID, the type, and the role:
dev.zed.Zed net.daringfireball.markdown all
dev.zed.Zed .md all
dev.zed.Zed .markdown all
Then apply the whole file in one shot: duti ~/.config/duti/markdown-zed.duti. Install with brew install duti, check a current default with duti -x md, and a fresh Mac is one command away from opening everything the right way.
That's it for this week. Hit reply if you've got an AI tool wired into your team's workflow that broke in a way you didn't see coming. I collect these.
– Chris