Coding agents waste hours fixing tests that already pass

Last week our coding agent spent 45 minutes trying to "fix" a test that was already passing. It kept running the same failing command, convinced something was broken, burning through API calls while I slept.

The problem? It couldn't tell the difference between a command that failed and a test that was supposed to fail.

Most coding agents live in this confusion. They see exit code 1 and assume disaster. They retry commands that worked. They "fix" code that's already correct. They turn every expected failure into an emergency.

The fix is teaching your agent the difference between system failures and expected outcomes.

Here's the pattern that stopped our agent from chasing ghosts:

## Expected Failure Patterns

# Tests that should fail
if command.startswith('npm test') and 'FAIL' in output:
    check_for_expected_test_failures(output)

# Build commands with warnings
if 'warning' in output.lower() and exit_code == 0:
    log_warnings_but_continue()

# Linting that finds issues
if command.startswith('eslint') and exit_code == 1:
    parse_lint_issues_as_todos(output)

But the real breakthrough was adding outcome classification to every command result:

def classify_outcome(command, exit_code, output):
    if is_test_command(command):
        return classify_test_outcome(output)
    elif is_build_command(command):
        return classify_build_outcome(exit_code, output)
    elif is_lint_command(command):
        return classify_lint_outcome(exit_code, output)
    else:
        return 'success' if exit_code == 0 else 'failure'

Now when our agent runs npm test and sees "3 tests failed", it doesn't panic. It classifies this as test_results_available and moves on to analyzing which tests actually need attention.

Key insight: Your agent needs to understand the difference between "this command didn't work" and "this command worked and found problems."

The classification system catches three major confusion patterns:

• Test confusion: Failing tests aren't broken commands
• Lint confusion: ESLint finding issues isn't ESLint failing
• Build confusion: Compiler warnings aren't build failures

We also added retry logic that respects outcome classification:

if outcome == 'system_failure':
    retry_with_backoff()
elif outcome == 'expected_failure':
    analyze_and_proceed()
elif outcome == 'partial_success':
    continue_with_warnings()
else:
    proceed_normally()

Since adding outcome classification, our agent stopped 90% of its ghost-chasing. It runs tests once, analyzes the results, and moves on. It doesn't retry successful linting. It doesn't "fix" intentionally failing tests.

The agent went from burning 200+ API calls on phantom problems to actually fixing real issues. And I stopped waking up to 47 notifications about "critical failures" that were just normal development workflow.

If your coding agent keeps retrying things that already worked, it needs outcome classification. Not smarter models. Not better prompts. Just the ability to tell the difference between a broken command and a working command that found problems.