From "here's the problem" to "here's the fix"
Since ErrorLens launched, the number one piece of feedback we received was consistent: "You tell me the root cause clearly, but I still have to figure out the fix myself."
That's a fair observation. Knowing that a NullPointerException is caused by an unguarded repository lookup is genuinely useful. But knowing the root cause and knowing what code to write are two different problems. The gap between diagnosis and fix is where developers still spend significant time.
Today we're closing that gap. Code Patch Suggestions is now available on all plans.
What it does
For every error that ErrorLens identifies in your analysis, it now generates a side-by-side code diff showing:
- Before: The problematic code pattern, inferred from your stack trace and error context
- After: The corrected code that addresses the identified root cause
- Filename: The likely file and class where the change should be applied, inferred from stack frame information
- Language: Detected automatically from the stack trace (Python, Java, JavaScript, TypeScript, Go, C#, Ruby, PHP, Rust, and more)
- Description: A one-line explanation of what the change does and why it fixes the error
The diffs are syntax-highlighted in the language of your stack trace, with line-level change indicators that match the standard unified diff format you'd see in a code review.
How the inference works
We don't have access to your source code — and we never will. The code patches are inferred entirely from the stack trace and log content you provide.
Stack traces contain more information than most developers realize. A Java stack trace includes the full class name, method name, and line number. From the class name, we can infer the package structure and the likely design pattern. From the method name and the exception type, we can infer what operation was being attempted. From the line number and surrounding stack frames, we can infer the call context.
For example, a stack trace like:
java.lang.NullPointerException
at com.myapp.payment.PaymentService.process(PaymentService.java:47)
at com.myapp.checkout.CheckoutController.submit(CheckoutController.java:89)tells us: a NullPointerException occurred in a method called process in a class called PaymentService in a payment package, called from a checkout controller. The most common cause of an NPE in a service method called from a controller is an unguarded lookup — a repository call that returned null. The inferred fix is to add null safety around the user or entity lookup that precedes the failing operation.
The fix isn't copy-pasted from our training data. It's generated specifically for the context of your stack trace: the class names, method names, and inferred code structure from your application.
What we mean by "realistic" patches
We deliberately chose the word "realistic" rather than "correct." We don't know your codebase. The generated patch shows the right structural approach to fixing the identified root cause, using naming conventions inferred from your stack trace. In most cases, applying the patch will require minor adjustments for your specific variable names, method signatures, or class structure.
Think of it as a senior engineer looking at your stack trace and writing a fix on a whiteboard: the logic is right, the pattern is right, the specific variable names are the best guess from context. It gets you 70–90% of the way to a working fix rather than starting from scratch.
In our internal testing, the patches required no modification in 41% of cases, minor modifications (variable name changes) in 38% of cases, and structural adaptation in 21% of cases. In no cases did a patch make the existing problem worse — all generated patches address the identified root cause even when they need adaptation.
Multi-file changes
Some root causes require changes in more than one file. For example, fixing a NullPointerException by changing a repository method to return Optional<T> also requires updating every caller of that method. When ErrorLens detects this pattern, it generates multiple diffs across the affected files, ordered from most important to least critical.
Multi-file patches are currently supported for:
- Repository/DAO method signature changes that cascade to service layer callers
- API contract changes that require updates to request and response handling
- Configuration changes that require corresponding code updates
- Database connection pool or resource management changes
Supported languages
Code Patch Suggestions currently generates diffs for: Python, Java, JavaScript, TypeScript, Go, C#, Ruby, PHP, Rust, Swift, Kotlin, Bash, and SQL. The language is detected automatically from the stack trace format — no configuration needed.
For mixed-language stack traces (common in microservices environments where a Python service calls a Java service), ErrorLens generates patches for each language separately, labeled clearly.
Feedback we're incorporating next
Since launching in private beta three weeks ago, the two most common feedback items have been:
- Copy-to-clipboard for individual diffs. Currently, you copy the entire diff panel. We're adding per-diff clipboard buttons in the next release.
- Integration with GitHub pull request comments. The roadmap item for automated PR comments from CI will include the full code diff, so reviewers can see the suggested fix alongside the error analysis.
Try Code Patch Suggestions on your next analysis. If you have a specific case where the patch is structurally wrong (not just needing variable name updates), we'd like to know — there are edge cases in certain error patterns we're still improving.