Test Suite Broken? Run Claude Code on the Fix While You Keep Building

You’re mid-feature. You’ve been building for an hour, Claude is on a roll, and you’re making real progress. Then you pull the latest changes from main, run the test suite out of habit, and 14 tests fail.

None of them are related to what you’re building. Someone else’s merge broke them, or a flaky dependency updated, or a test was relying on a date that just rolled over. Doesn’t matter. The tests are red, and now you have a choice.

Option A: Stop what you’re doing, fix the tests, then get back to your feature. You lose your momentum, your Claude session loses its context, and the feature takes longer.

Option B: Ignore the failing tests and keep building. You’ll fix them later. Except “later” means they stay broken, more tests pile on top, and you’ve got a compound problem by end of day.

There’s a better option.

Option C: Fix the tests in parallel

The idea is simple. Keep your feature session running exactly where it is. Open a separate session, point it at the failing tests, and let Claude fix them on a different branch. You review and merge the fix when it’s ready. Your feature work never stops.

This isn’t complicated in theory. In practice, it requires two things: isolated environments so the two sessions don’t step on each other, and a way to manage both sessions without losing track of either one.

Setting it up

This is what it looks like in Crystl, step by step.

1. Keep your feature shard running. Don’t touch it. Claude has context on what you’re building, and you don’t want to interrupt that.

2. Open a new isolated shard. In Crystl, an isolated shard creates a git worktree — a separate working directory on its own branch. This is the key detail. The test-fix shard has its own copy of the code. Nothing it does affects your feature branch.

3. Prompt Claude with the problem. Something like:

Run the test suite. 14 tests are failing. Investigate the failures, identify the root causes, and fix them. Don’t change any test expectations unless the test itself is wrong — fix the code the tests are testing.

4. Go back to your feature shard. Continue where you left off. Claude is working on both problems simultaneously.

Why this works better than you’d expect

The first time I tried this, I expected the test fix to be a quick detour. It wasn’t. The 14 failures had three root causes, one of which was a subtle race condition in an async handler. Claude in the test-fix shard spent 20 minutes tracing the issue, writing a fix, and verifying all 14 tests passed.

During those 20 minutes, I was still building my feature. I’d merged the test fix and gotten back to green before my feature shard even finished its current task. If I’d stopped to fix the tests myself, I’d have lost those 20 minutes of feature progress plus the context-switching overhead of getting back into the feature mindset.

The economics are compelling. You’re not saving a little time — you’re saving all the time the fix takes plus the cognitive cost of stopping and restarting your primary work.

Handling the merge

When the test-fix shard is done, you’ve got a clean branch with just the test fixes. Merge it to main. Then rebase your feature branch on top of the updated main if you need the fix in your feature branch (you usually do, so your tests pass in CI).

The merge is almost always clean because the test fix and your feature are touching different parts of the codebase. If they’re not — if the test failures are actually related to your feature — then parallel fixing isn’t the right approach. Fix them in your feature shard as part of the feature work.

When to use this pattern

This pattern works any time you hit a problem that’s unrelated to your current task but blocking enough that you can’t ignore it. A few scenarios I hit regularly:

Flaky tests from upstream changes. Someone merged a change that broke tests in a module you don’t own. Fix it in a parallel shard, don’t derail your own work.

Dependency updates. A minor version bump broke a type definition or changed a default. Fixing it is mechanical — update the call sites, verify tests pass — but it takes time you’d rather spend on your feature.

Linting or formatting failures. A new lint rule got added and 30 files need updating. Let Claude handle it in a separate shard with a permissive approval mode while you keep building.

Keeping track of both sessions

The risk with parallel work is losing track of what’s happening. You forget about the test-fix shard, it finishes, and the fix sits unmerged for hours.

Crystl handles this with notifications. When the test-fix shard finishes its task or needs an approval decision, you get a notification. You switch to it via the Crystal Rail, review the fix, merge it, and close the shard. Total interruption: two minutes.

You can also use split view to watch both shards simultaneously if you want to keep an eye on the fix in real time. I usually don’t — the notifications are enough — but it’s useful for trickier fixes where you want to see Claude’s reasoning as it works.

The broader principle

This scenario is an instance of a more general idea: never let an unrelated problem block your primary work. Before parallel sessions, every interruption was sequential — stop, fix, restart, pay the context-switch penalty. With isolated shards, interruptions become background tasks. The problem still gets fixed, but your momentum stays intact.

Crystl is free — sign up at crystl.dev/login.