← Back to Blog

From Exception to PR in 5 Minutes

Srikar Srikar • September 6, 2025 • 15 min read

At 03:47:23 UTC, a NullPointerException crashes the payment service. At 03:52:18 UTC—exactly 4 minutes and 55 seconds later—a pull request titled "Fix: Add null validation to PaymentProcessor.charge()" is opened, reviewed by CI, and awaiting human approval.

No engineer was paged. No logs were manually searched. No hypotheses were debated in Slack. The system detected the fault, diagnosed the root cause, generated a fix, validated it against tests, and proposed the change—autonomously.

This isn't a demo. This is production reality at several companies using ThinkingSDK. Here's how the pipeline works.

Phase 1: Exception Capture (0-15 seconds)

When the NullPointerException fires, it doesn't just log a stack trace. The ThinkingSDK client—instrumented into the application at startup—captures a complete runtime snapshot:

{
  "exception": {
    "type": "NullPointerException",
    "message": "Cannot invoke method charge() on null object",
    "stack_trace": [...]
  },
  "execution_context": {
    "function_call_chain": [
      {"fn": "handleCheckoutRequest", "file": "CheckoutController.java:47"},
      {"fn": "processPayment", "file": "PaymentService.java:112"},
      {"fn": "charge", "file": "PaymentProcessor.java:89"}
    ],
    "local_variables": {
      "user_id": "usr_7f8a3c2",
      "cart_total": 149.99,
      "payment_method": null,
      "stripe_token": null
    },
    "call_stack_depth": 12,
    "thread_id": "worker-pool-7"
  },
  "database_context": {
    "recent_queries": [
      {
        "sql": "SELECT * FROM users WHERE id = ?",
        "params": ["usr_7f8a3c2"],
        "duration_ms": 12,
        "rows_returned": 1
      },
      {
        "sql": "SELECT * FROM payment_methods WHERE user_id = ? AND is_default = true",
        "params": ["usr_7f8a3c2"],
        "duration_ms": 8,
        "rows_returned": 0
      }
    ]
  },
  "http_context": {
    "request": {
      "method": "POST",
      "url": "/api/checkout",
      "headers": {...},
      "body": {"cart_id": "cart_abc", "user_id": "usr_7f8a3c2"}
    },
    "response": {
      "status": 500,
      "body": "Internal Server Error"
    }
  },
  "temporal_context": {
    "timestamp": "2025-09-06T03:47:23.456Z",
    "request_id": "req_9f3b2a1",
    "trace_id": "trace_checkout_abc123"
  }
}

This context is the foundation. Without it, AI can only guess. With it, AI can reason causally.

Phase 2: Root Cause Analysis (15-60 seconds)

The exception snapshot is transmitted to ThinkingSDK's analysis backend within 1-2 seconds (using async queues to avoid blocking the application). The AI analysis pipeline begins:

Step 1: Causal Chain Reconstruction

The AI traces backward from the exception point to identify the originating fault:

"The null pointer in PaymentProcessor.charge() originated from payment_method being null in PaymentService.processPayment(). This variable was populated from a database query that returned 0 rows. The query searched for a default payment method for user usr_7f8a3c2, but none exists. Root cause: Missing validation that payment_method is present before invoking charge()."

Step 2: Pattern Matching Against Historical Incidents

ThinkingSDK maintains a corpus of every exception it has ever analyzed, along with the fixes that resolved them. For this NullPointerException, it finds 47 similar incidents in the past 6 months:

  • 38 cases (81%) were resolved by adding null checks after database queries
  • 6 cases (13%) were resolved by adding default values for missing data
  • 3 cases (6%) were resolved by fixing the query logic to handle edge cases

Based on pattern confidence, the AI ranks the most likely fix: "Add null check with appropriate error handling."

Step 3: Code Context Enrichment

The AI fetches the source code for PaymentService.processPayment() and its surrounding context—imports, class structure, related functions. It also pulls recent commits to this file from Git to understand recent changes that might have introduced the bug.

// Git blame output
Commit: a3f5c2d (2025-09-05, deployed yesterday)
Author: developer@company.com
Message: "Refactor payment processing to support multiple payment methods"

Changed lines:
- payment_method = getDefaultPaymentMethod(user_id);
+ payment_method = user.getPaymentMethods().stream()
+     .filter(pm -> pm.isDefault())
+     .findFirst()
+     .orElse(null);  // <-- This introduced the bug

The AI identifies that yesterday's refactor introduced the null return case without adding validation. High-confidence diagnosis: "Regression introduced by commit a3f5c2d."

Phase 3: Fix Generation (60-120 seconds)

With root cause identified, the AI generates a fix. But not just any fix—a fix that adheres to the codebase's conventions:

Step 1: Contextual Code Generation

The AI analyzes how the codebase handles similar validation logic elsewhere. It finds that other endpoints use a pattern of throwing a PaymentValidationException when required data is missing:

// Existing pattern in OrderService.java
if (shipping_address == null) {
    throw new PaymentValidationException(
        "Missing shipping address",
        ErrorCode.MISSING_SHIPPING_ADDRESS
    );
}

The AI generates a fix that follows this existing pattern:

// Generated fix for PaymentService.java
public Payment processPayment(String userId, double amount) {
    User user = userRepository.findById(userId);
    PaymentMethod paymentMethod = user.getPaymentMethods().stream()
        .filter(pm -> pm.isDefault())
        .findFirst()
        .orElse(null);

    // AI-generated validation
    if (paymentMethod == null) {
        throw new PaymentValidationException(
            "No default payment method found for user: " + userId,
            ErrorCode.MISSING_PAYMENT_METHOD
        );
    }

    return paymentProcessor.charge(paymentMethod, amount);
}

Step 2: Test Generation

Every fix needs tests. The AI generates test cases that cover the bug and its edge cases:

@Test
public void testProcessPayment_whenNoDefaultPaymentMethod_throwsException() {
    // Arrange
    String userId = "usr_test";
    User user = new User(userId);
    user.setPaymentMethods(Collections.emptyList());
    when(userRepository.findById(userId)).thenReturn(user);

    // Act & Assert
    assertThrows(PaymentValidationException.class, () -> {
        paymentService.processPayment(userId, 99.99);
    });
}

@Test
public void testProcessPayment_whenDefaultPaymentMethodExists_succeeds() {
    // Arrange
    String userId = "usr_test";
    PaymentMethod pm = new PaymentMethod("pm_123", true);
    User user = new User(userId);
    user.addPaymentMethod(pm);
    when(userRepository.findById(userId)).thenReturn(user);

    // Act
    Payment result = paymentService.processPayment(userId, 99.99);

    // Assert
    assertNotNull(result);
    verify(paymentProcessor).charge(pm, 99.99);
}

Phase 4: Validation (120-240 seconds)

Generating a fix is easy. Validating that it doesn't break anything is hard. ThinkingSDK runs a multi-stage validation pipeline:

Step 1: Static Analysis

  • Lint check: Does the code follow style guidelines?
  • Type check: Does it compile without errors?
  • Dependency check: Are all imports available?

Step 2: Existing Test Suite

The AI triggers the full test suite (1,200 tests, ~90 seconds runtime). If any test fails, the fix is rejected and the AI iterates:

Test suite result: 1,200 tests passed, 0 failed
Coverage: 87% of modified lines covered by existing tests

Step 3: AI-Generated Test Suite

The newly generated tests are run to ensure they pass and properly validate the fix:

New test suite result: 2 tests passed, 0 failed

Step 4: Canary Deployment (if configured)

For high-confidence fixes, ThinkingSDK can automatically deploy to a canary environment (1% of traffic) and monitor for SLO violations:

Canary deployment: v2.3.2-autofix-a3f5c2
Traffic: 1% of production requests (routed via feature flag)
Duration: 5 minutes
Metrics monitored:
- Error rate: 0.02% (within baseline)
- p95 latency: 120ms (within baseline)
- Success rate: 99.98% (within baseline)

Canary status: PASSED

Phase 5: PR Creation (240-300 seconds)

With all validations passed, ThinkingSDK creates a pull request using the GitHub API:

PR #1847: Fix: Add null validation to PaymentProcessor.charge()

## Summary
Fixes NullPointerException in PaymentProcessor.charge() caused by missing validation
after database query returns no default payment method.

## Root Cause
Commit a3f5c2d refactored payment method retrieval to use Stream API with orElse(null),
introducing a code path where payment_method can be null. This was not validated before
invoking charge().

## Fix
Added null check following existing PaymentValidationException pattern used in
OrderService and ShippingService. Throws descriptive error when payment method is missing.

## Testing
- Added 2 new test cases covering null and non-null scenarios
- All 1,200 existing tests pass
- Canary deployment validated (1% traffic, 5 minutes, 0 regressions)

## Impact
- Affects /api/checkout endpoint
- Resolves exception affecting 127 users in past hour
- Exception first occurred at 2025-09-06T03:47:23Z
- Total affected requests: 342

## Validation
✅ Lint passed
✅ Type check passed
✅ Test suite passed (1,200/1,200)
✅ New tests passed (2/2)
✅ Canary deployment passed

Generated by ThinkingSDK autonomous debugging system
Exception ID: exc_9f3b2a1
Analysis ID: analysis_7a8f3c2

The PR is now ready for human review. In many cases, teams configure auto-merge for low-risk fixes that pass all validations.

What About Complex Bugs?

Not every bug can be auto-fixed in 5 minutes. The system handles varying complexity levels:

High Confidence (70% of exceptions)

  • Null checks, type validation, missing error handling
  • Auto-fix success rate: ~85%
  • Median time to PR: 4.5 minutes

Medium Confidence (20% of exceptions)

  • Logic errors, off-by-one bugs, incorrect calculations
  • Auto-fix success rate: ~60%
  • Requires human review before merge

Low Confidence (10% of exceptions)

  • Distributed system bugs, race conditions, architectural issues
  • Auto-fix success rate: ~30%
  • AI provides analysis + suggested approaches, human implements fix

The Economics of Auto-Fixing

Traditional debugging costs:

  • Engineer time: 2-4 hours to diagnose, fix, test, deploy
  • Incident response: Page engineer, context-switching cost
  • User impact: Hours of degraded service while fix is developed

With autonomous fixing:

  • AI time: 5 minutes to PR creation
  • Engineer time: 5-10 minutes to review and approve
  • User impact: Minutes instead of hours

For a team handling 50 production exceptions per week, auto-fixing saves ~150 engineering hours per week. That's nearly 4 full-time engineers reclaimed for building instead of firefighting.

The Trust Problem

Would you let AI push fixes to production without review? Most teams wouldn't—and shouldn't. Trust is built incrementally:

Phase 1: AI-Generated Analysis Only

AI diagnoses the problem, suggests a fix, but humans implement it. This builds confidence in AI's diagnostic accuracy.

Phase 2: AI-Generated Fixes with Mandatory Review

AI generates fixes + tests, creates PRs, but humans must review and approve before merge. Teams observe that AI-generated fixes are high-quality and rarely require modification.

Phase 3: Auto-Merge for Low-Risk Fixes

After observing 100+ successful AI-generated fixes, teams enable auto-merge for specific categories (e.g., null checks, input validation) that pass all tests and canary validation.

Phase 4: Full Autonomy with Monitoring

AI auto-merges all high-confidence fixes. If production metrics degrade post-deployment, the system auto-reverts and escalates to humans.

What We've Learned

After running this system in production for 8 months across 12 companies:

1. Context is Everything

The richer the runtime context, the higher the auto-fix success rate. Teams that instrument database queries, HTTP requests, and distributed traces see 2x higher success rates than teams that only capture stack traces.

2. Historical Data Accelerates Learning

The system improves over time. After analyzing 10,000 exceptions in a codebase, pattern recognition becomes highly accurate. Early adopters see 60% auto-fix rates; after 6 months, this rises to 85%.

3. Humans Still Matter

Auto-fixing handles the grunt work—null checks, validation, error handling. Humans focus on architectural decisions, performance optimization, and complex distributed system bugs. The division of labor makes both more effective.

The Future: Proactive Fixing

Today's system is reactive—it fixes bugs after they occur. Tomorrow's system will be proactive—it will detect potential bugs before they reach production.

Imagine:

  • A pull request is opened that adds a new database query without an index. CI comments: "This query will cause a full table scan on a 10M row table. Suggested index: CREATE INDEX idx_users_email ON users(email)"
  • A function is modified to handle nullable values, but 3 call sites don't pass null checks. CI opens a PR: "Fix: Add null validation at 3 call sites for updated function"
  • A deploy is about to introduce a memory leak based on heap profiling in staging. CI blocks the deploy and suggests: "Detected unbounded list growth in BackgroundWorker.cache. Suggested fix: Add cache eviction policy"

This shifts debugging from "react to production failures" to "prevent production failures." The fastest way to fix a bug is to never ship it.

Try It

ThinkingSDK is available now. Instrument your application, let exceptions flow into the system, and watch as PRs start appearing within minutes of each fault.

The age of manual debugging is ending. The age of autonomous software repair is here. Ready to see it in action? Contact us at contact@thinkingsdk.ai to get started.