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.
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:
"do X for me", e.g. find relevant issues, fix CI failures
"write a (often shell) script that mostly automates X"
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.
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.
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”
pyfisch | 10 hours ago
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.
simonw | 7 hours ago
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.
quasi_qua_quasi | 7 hours ago
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.
ibookstein | 6 hours ago
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.quasi_qua_quasi | 6 hours ago
Actual execution; a lot of it is just slow tools.
ibookstein | 7 hours ago
Yeah, I've been maintaining our
pre-commitintegration for a while. Same list of hooks runs both locally and in CI. Moving toprekwas a nice, seamless upgrade in terms of execution speed over the python-basedpre-commit.classichasclass | 8 hours ago
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.
wrs | 6 hours ago
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.
kwas | 6 hours ago
i've had a clanker vibecode a pre-build hook for
paruthat runs on any AUR package upgrade, hopefully detecting any suspicious changes in the build files.fazalmajid | 4 hours ago
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.
cuchulain | 4 hours ago
I liked this thread 3 or so months back about using LLMs to write better code more slowly.
andyc | 3 hours ago
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.
joshka | 4 hours ago
For the github actions case.
gh pr checks --watch --failfastis 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.
markerz | 2 hours ago
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”