The day automation summoned more automation

I wanted a pipeline that rolled along on its own

An issue comes in, the AI reads it, works out what's wrong, fixes the code, and opens the commit and the PR. I'm the one who put that picture on top of GitHub Actions and let it run. I even gave it a grand name: claude-pipeline.

The design idea seemed reasonable enough. "Ask for an analysis first, then improve based on that analysis." That's the order a person works in, after all.

Understand the problem, then fix it based on what you understood. Split that into jobs, wire them together, and I assumed it would roll along by itself.

The boss started this project because working from the laptop every time was too inconvenient. There is a remote option, but that assumes the laptop stays online, so something else was needed.

He wanted a way to give instructions whether he was out or at the office. That direction came to me.

Analysis called improvement, and improvement called analysis

I set it running, went off to do something else, and came back to something odd. The list of job runs had piled up without end.

[Reproduction] When analyze finishes it triggers improve; when improve finishes it triggers analyze again. There's nowhere for it to stop.

Looking closely, this is how it was hooked up. Finishing the improvement work triggered the analysis again, and finishing that analysis triggered the improvement again.

Analyze, improve, analyze, improve. Each one waking the other. At its worst it was running three layers deep.

I hadn't kicked off each of those runs. The pipeline was cloning itself and running the copies.

Two mirrors set facing each other, basically. One reflects the other, which reflects the first again. No point where it ends.

The result was predictable. It ate the entire GitHub Actions allowance, and the API tokens went with it. I didn't have the stomach to work out what it cost.

The cost stung, but exhausting the free Actions minutes hurt more. Every other workflow failed as a result, and the whole project had to be pushed back.

The problem wasn't the making, it was the stopping

At first I wondered whether letting it generate code automatically was the mistake. It wasn't. The code generation part worked perfectly well.

The real hole was that nobody had decided when it should stop or how many rounds it should run. If you run a check, that check has to become the baseline, but it couldn't work out on its own where the finish line was.

I assumed "analyze then improve" would end at improve. That it would go back and run analysis again never crossed my mind. Not understanding loop structures is what caused this.

A structure where automation triggers more automation has to have a stopping condition, and I left that entire layer out.

I never capped how many levels the recursion could go. I never set concurrency to limit how many could run at once, and there was no budget guard saying stop after this much time or this many tokens. I threw out the rule "analyze and improve" and then drove a car with no brakes.

The ability to build and the ability to manage "when and how much it runs" turned out to be entirely different problems. I worried about the analyze/improve logic and the code quality, and neglected putting up guard rails.

Next time, the brakes go on first

One thing came out of this flailing. If you're going to build a structure where automation calls automation, design the stopping condition before the feature.

Cap the recursion depth. Bind concurrent runs with concurrency. Put budget limits on time and tokens. Any one of those and the loop would have stopped itself somewhere, however many times it spun.

Building and orchestration have to be designed as separate things — a lesson that arrived only after the quota was gone.

Obvious in hindsight, but before it happened I thought "surely it won't run that far." Automation exists so you can be lazier, and automation without brakes turned out to be far more diligent about causing trouble than I am.