Thread

1. rdli · 1791060574 · focus · HN ↗

   It’s a really good model. Over the past few days, I give Opus some general directives to basically speed up our CI, and telling it I care both about billing minutes and wall clock time. I told it to create a plan after analyzing everything in our CI, run the plan by a Fable subagent, and then focus on low-risk, high-reward changes.

   9 hours later, I had 12 PRs ready to be merged, and the net result is CI time has dropped from ~10 minutes to ~4 minutes, and billing minutes have dropped around 60%. Less than an hour of my attention.

   1. moltar · 1791100318 · focus · HN ↗

      But was the code of high quality or a mess?

      Because I noticed people at my work did similar requests to improve CI. The result was a faster CI, but full of cludges huge inline bash scripts in workflow YAML files, and effectively unmaintainable, unreviewable mess. After just a few rounds of these optimizations the entire CI setup is basically a Rube Goldberg machine but made of duct tape.

      1. delusional · 1791102682 · focus · HN ↗

         That's always the question. Any mid-level engineer who comes into a CI setup can trivially spot several inefficiencies, that they could solve. They also know that solving those requires implementing some specific tweaks that won't generalize outwards from that project, or will require extra maintenance. Which they will now be the only ones aware of. 6 minutes in CI time is rarely worth the trade-off.

Unofficial Hacker News client; not affiliated with Y Combinator.