Saturday, November 22, I was testing the batch scripts. Running one workflow at a time across multiple repositories to measure performance.

The workflow execution was fast. Background processing worked perfectly. But I noticed something consuming disproportionate time.

Git commits. Each one took two minutes.

Finding the Bottleneck

I’d built skills for git operations. One would commit and push code. Another would create pull requests. For interactive development, these were exactly right. Claude would analyze changes and write contextual commit messages.

But I was tracking timing across the batch operations, and these skills stood out. Two minutes per commit. For operations that should be trivial.

The repositories processed in parallel, so the total time was determined by whichever repository took longest. That repository’s runtime was getting inflated by two minutes just for the commit. That’s not a performance problem. That’s an architectural mismatch.

The Wrong Abstraction

The issue wasn’t the skill. The skill worked perfectly for interactive development where thoughtful commit messages add value.

The issue was using that abstraction in a batch context where every commit followed an identical pattern. I was paying for intelligence to solve a problem that didn’t require intelligence.

That’s expensive. Not just in time, but in how it compounds across scale.

The Solution

I replaced the skill invocation with bash commands. Direct git operations with templated messages.

Commits that took two minutes dropped to 30 seconds.

Since the repositories run in parallel, this meant the longest-running repository only added 30 seconds for the commit instead of two minutes. The bottleneck shrank by 90 seconds.

Choosing the Right Tool

This is about matching tools to context.

Claude excels at tasks requiring judgment, adaptation, and context. That’s where you want intelligence. But batch operations with predictable patterns don’t need intelligence. They need fast, consistent execution.

The same task in different contexts requires different tools. Interactive development benefits from thoughtful commits. Batch operations benefit from speed and consistency.

Recognizing that difference matters.

Thinking About Scale

Small inefficiencies compound at scale.

One commit taking two minutes instead of 30 seconds? Negligible when you’re working interactively. But in parallel batch operations, that two minutes becomes the floor for your total runtime.

Eventually I’ll run this across all repositories. If the commit operation dominates the critical path, everything waits for it. That scales poorly.

This pattern appears everywhere in systems. The difference between fast and slow architecture often comes down to identifying what actually needs intelligence versus what needs simple execution.

Use intelligence where it creates value. Use simplicity everywhere else.

What I Learned

First, intelligence has a cost. Don’t pay for intelligence when the problem doesn’t require it.

Second, the right abstraction depends on context. The same operation in different contexts may need different tools.

Third, bottlenecks in parallel systems determine your total runtime. Optimize the critical path.

The skills were designed for one context. I used them in another. The moment I recognized the mismatch, the solution was obvious.

Sometimes the best engineering decision is recognizing when you don’t need engineering. Use bash. Use simple tools. Solve the actual problem.

What Fast Tooling Reveals

By Saturday evening, the batch scripts were fast. The automated analysis agents were generating insights efficiently. Pattern reports. Individual analyses. All working.

And consistently, those reports surfaced the same underlying issue: the workflow instructions themselves had problems. Workers interpreting instructions differently. Inconsistent results. Imprecise language.

The tooling was finally fast enough that it stopped being the problem. Which meant I could see what the actual problem was.

The instructions needed work. Not more testing. Not more data. Systematic refinement.

Next: Clear, Concise, Precise