Useful Things Agents Can Do That Are Not Writing Code
17 points by sumner
17 points by sumner
90% of the time a GitHub Actions workflow fails, it is not due to a bug. It’s because I forgot to run my formatter or my static analysis tools (think Prettier or tsc).
Make the formatter and tools part of your local pre-commit hook, it allows you to iterate faster and you conserve energy otherwise spent on CI and tokens.
I've also got a few projects where the formatter runs in GitHub Actions against every PR and pushes a commit fixing any formatting errors. It's a nice pattern.
If I had to explicitly recompile my entire working directory on every commit I would basically instantly disable precommit hooks. I use commits for basically any kind of "here's some state I want to save later".
One of the repos I work on actually does have some precommit hooks that take like 5-10 seconds to run and it's always extremely aggravating.
At $WORK we only put things that don't require a build directory in the pre-commit hooks. Static analysis and python type checkers are left to other CI steps.
Is the hook execution time coming from overheads or the hooks themselves? We've had very nice execution time improvements from migrating to prek, and the migration itself was quite seamless.
Yeah, I've been maintaining our pre-commit integration for a while. Same list of hooks runs both locally and in CI. Moving to prek was a nice, seamless upgrade in terms of execution speed over the python-based pre-commit.
Since debugging is typically half the time spent on as project vs 1/6 to 1/3 coding, it follows vibe-debugging is 2-3x more valuable than vibe-coding.
I like the merge prompt, and I say this as someone generally sceptical of AI-generated code for greenfield applications. I might actually use that because I hate the mechanical boilerplate process, though first check it did what I think is a good job.
I noticed recently that I'm doing a lot more "housework" in the code (refactors, renames, reorgs, stale comment sweeps) because Claude is so good at dealing with merge hell. Something that would baffle a standard line-based deterministic merge tool is no problem for an LLM that can "see" the code at a more semantic level. So entropy-reducing tasks that I would just never bring myself to do now actually happen.
i've had a clanker vibecode a pre-build hook for paru that runs on any AUR package upgrade, hopefully detecting any suspicious changes in the build files.
I think this is walking a slippery slope. I think about the distinction between:
I think the latter is more predictable and maintainable. You might use an LLM to start it, but then you can also read the code and know what it's doing.
In the case of merge conflicts, I'm not sure I would trust an LLM to do it correctly. Needing to fix a true conflict is fairly rare on the projects I've worked on ... it's better to design workflows so it is a rare occurence.
My clanker debugs customer issues by combining the customer report, an MCP for our logger (datadog), and the source code. Pretty helpful when I get paged.
I’ve also successfully asked “I’m going to enable this feature flag, make a datadog dashboard of every API endpoint that can be affected”
For the github actions case. gh pr checks --watch --failfast is pretty good. Lets your clanker see the output of checks as soon as they fail and start fixing the problem.
For those that mention pre-commit hooks. Sure you could do that. I tend not to like this though. My general take is if you have to run processes like this twice (local + CI) 100% of the time, then you're total time sink is 2x. If instead you mostly just let CI check things like formatting issues and handle failure cases, you cut that down a bunch. I.e. often P(fail) x (cost of cleanup + retry) < 2x the cost of doing it "right".
The calculus I generally use is mostly to do cheap / fast things locally (format, unit tests), expensive / slow things on CI, and assume that your LLM loop handles doing the right thing most of the time.
That makes a lot of sense but it depends on the team size and processes. A slow CI can be quite an obstacle when you have many pr runs during a day, it slows down your turnaround time a lot.
Also, running a formatter in a pre commit hook (and fixing issues) is usually faster locally on dev laptops then on CI.
So, yes, you might need to run a formatter twice and fix once, but that's a fast local run and fast local fix and a slow CI run and that's already down from 2x time to, let's just arbitrarily say 1.5x.
But now your CI itself is usually faster and merge trains and congestion on GitHub itself is less of a problemb and you merge more and faster during the day.
It doesn't need to be just a formatter, you can put whatever is fast to run locally on a pre commit. E.g. tests are a good thing, or at the very least a test subset of affected files or fast unit tests. PR title names and descriptions checks. Sometimes things like checks for missing API docs or similar can be fast (or, again, a subset). The point is, you can increase a pre commit hook time slightly to greatly improve CI merge times.
And that's not the only benefit. I really love the fast feedback. If I'm working on an issue and I get feedback now vs in an hour or whenever I remember to look at my PR, it's gonna help me deal with all that stuff faster, while it's fresh in my mind.
Granted, these things aren't directly related to the article itself, but are related to GH actions you mentioned, I believe.