By Friday, November 21, I had four workflows ready to automate.
I had a working batch script for the first workflow. It handled repository selection, branch creation, background execution, commit and PR automation.
Three more workflows needed scripts.
Planning Ahead
I already knew how this would end. Four workflow scripts weren’t enough. I’d need a fifth script. A master orchestrator that could run the four workflow scripts in a specific order.
Some workflows depended on others. The order mattered.
So the plan was clear: build individual workflow scripts, then build the master script to coordinate them.
But I hadn’t built the individual scripts yet.
Claude’s Second Script
I asked Claude to create the batch script for workflow 2.
Claude read the requirements and wrote the script. Not by copying script 1. By understanding what workflow 2 needed and implementing it.
When I reviewed it, I found problems.
Some parts were missing. Features that existed in script 1 weren’t in script 2. Other parts were done differently. Different error handling approaches. Different repository selection logic.
Claude had written a working script. But it was inconsistent with script 1.
The Real Problem
The problem wasn’t that Claude made mistakes. The problem was that Claude wrote the scripts independently.
Script 1 did things one way. Script 2 did things another way. Both worked. But they weren’t consistent.
That’s when I thought about how I’d normally work with code. When you have multiple implementations doing similar things, you don’t write each one independently. You extract the common parts. Share the infrastructure. Customize only what’s specific.
Shared Infrastructure
The workflow scripts shouldn’t be independent implementations. They should be thin wrappers around shared code.
Everything common should be extracted. Repository handling. Branch management. Background execution. PR creation.
Each workflow script would just specify:
- Which workflow to run
- How to name the branch
- What commit message to use
- Any workflow-specific parameters
The shared infrastructure would handle everything else.
This wasn’t just cleaner. It enforced consistency. All four scripts would use the same repository logic. The same error handling. The same conventions.
Refactoring
So I had Claude refactor scripts 1 and 2. Pull the common code into shared functions. Leave only the workflow-specific parts in each script.
Now each workflow script was maybe 30 lines. Workflow identification. A few parameters. Done.
The shared infrastructure handled the rest.
Consistency by Default
With the refactored architecture, creating scripts 3 and 4 was straightforward.
Each new workflow script just specified its unique configuration. The shared code did the work.
And because they all used the same infrastructure, they were consistent. Not because I reviewed carefully. Not because Claude remembered how script 1 worked. Because the code itself enforced consistency.
Same repository handling. Same error checking. Same PR creation logic. Automatically.
This is what proper architecture buys you. Not just less code. Consistency that can’t be violated.
The Master Script
With four workflow scripts refactored and working, I built the master orchestrator.
It was straightforward. The master script just needed to:
- Run workflow 1’s script
- Wait for completion
- Run workflow 2’s script
- Wait for completion
- Continue through all workflows
The workflow scripts already handled parallel repository execution. The master script just ran them sequentially.
This created a clean architecture:
Master Orchestrator
├── Workflow 1 Script
│ └── (runs on multiple repositories in parallel)
├── Workflow 2 Script
│ └── (runs on multiple repositories in parallel)
├── Workflow 3 Script
│ └── (runs on multiple repositories in parallel)
└── Workflow 4 Script
└── (runs on multiple repositories in parallel)
Serial coordination at the workflow level. Parallel execution at the repository level.
Testing Strategy
I wouldn’t test the master script for a while.
Each workflow needed individual testing first. Run the workflow script. Check the results. Fix issues. Iterate until production-ready.
Only after all four workflows were tested and stable would I try the master script.
But the architecture was in place. When I was ready to test the master orchestrator, the pieces were there. Four working workflow scripts. A master script to coordinate them. All using shared infrastructure.
The refactoring made this possible. Without shared code, maintaining four independent scripts would have been painful. With shared code, they worked together naturally.
By Friday evening, November 21, I had the architecture in place. Four workflow scripts using shared infrastructure. A master orchestrator to run them sequentially. Not tested yet. But ready for testing when the time came.
And when I did test it, I’d discover a bottleneck I hadn’t anticipated. One that would teach me something about when to use AI and when not to.
Next: When Bash is Better