Lesson 3.4: Multi-Step Self-Healing Pipeline: Write, Run, Fix, Repeat

Lesson 3.4: Multi-Step Self-Healing Pipeline: Write, Run, Fix, Repeat

The Naive Approach Trap

You've just used Claude Code to batch-fix type hints across 20 files. The diffs look good in chat, so you manually copy-paste them into your editor, test, commit. Two weeks later, a teammate runs the same claude command on the same files. They get almost identical diffs. Three weeks later, you run it again and get diffs you've already committed. Each time, tokens are burned on re-processing work that's already done.

This scales catastrophically in CI. A GitHub Actions workflow that calls claude -p < git-diff.txt every 6 hours with no state tracking will process the same files repeatedly. After 30 days, you've burned 40% of your token quota on duplicate work. At team scale—50 daily diffs—this compounds. You have no visibility into which files actually need attention, which diffs were rejected by your team, and which fixes succeeded.

The trap is simple: Claude Code produces diffs; your pipeline has no memory of which diffs you've already decided to keep.

The Failure Mode

Here's the exact technical breakdown:

1. Token Waste & Invisible Cost Growth
   A naive loop runs claude -p on files A, B, C. It outputs 3 diffs. You review and accept 2 (A, B); you reject 1 (C, it had a syntax error). On day 2, you run the loop again without state. Claude re-processes A, B, C in parallel, outputs 3 diffs again, but you now have duplicates in your chat history and you've spent 30% of those tokens on re-processing A and B. At enterprise scale with hundreds of daily files, this is undetectable until your token quota is exhausted mid-month.

2. Lost Diffs & Unrecoverable Context
   File C failed the first time because Claude's fix introduced a bug. You didn't save that failure reason. On day 2, Claude generates the same buggy diff for C. Your script has no memory of why C failed, so it can't narrow the context or hint at the mistake. You're stuck in a loop.

3. Exit Code Silence
   claude --print exits with non-zero if an API error occurs or token limit is hit. A bare bash script like claude -p < input.txt | jq . swallows that exit code if jq succeeds. Your pipeline reports success even though Claude failed halfway through. This gets worse in CI: the GitHub Actions job succeeds (bash exit 0), but only 60% of your files were processed.

4. ANSI Escape Codes in JSON
   By default, claude --print wraps output in ANSI color codes (e.g., x1b[32m). If you pipe this directly to jq .content[0].text, the text field contains escape sequences. You can't parse diffs with embedded x1b[32m markers; git apply fails silently.

5. No Visibility into Token Consumption
   You have no idea if your remaining Pro session tokens are sufficient for the next batch. A pipeline that processes 50 files blindly and runs out of tokens on file 43 leaves you with 7 unprocessed files and no way to know without manually checking Claude's UI.

The ClaudeForge Architecture

This lesson introduces state-tracked, self-healing batch processing. The deliverable is a Bash script (batch_fix.sh) that:

• Maintains a state file (JSON) tracking each file's processing history

• Calls claude --print --no-color to suppress ANSI codes

• Checks token budget before each batch via claude /status

• Parses Claude's response into individual diffs, applies them with git apply --check, and commits only successful ones

• On failure, retries with narrowed context: feeds only the error message + the original file back to Claude, not the entire codebase

• Logs every step (file name, tokens consumed, diff accepted/rejected, error reason) for audit and debugging