← Latest papers
💻 computer science

RGFL: Reasoning Guided Fault Localization for Automated Program Repair Using Large Language Models

This paper presents RGFL, a novel reasoning-guided fault localization approach for large language model-based automated program repair that utilizes a hierarchical reasoning module and a two-stage ranking scheme to significantly improve file- and element-level localization accuracy on project-level codebases, thereby boosting end-to-end repair success rates.

Original authors: Melika Sepidband, Hamed Taherkhani, Hung Viet Pham, Hadi Hemmati

Published 2026-01-27
📖 5 min read🧠 Deep dive

Original authors: Melika Sepidband, Hamed Taherkhani, Hung Viet Pham, Hadi Hemmati

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a master detective trying to fix a broken machine in a massive, multi-story factory. The machine is a computer program, and the "broken part" is a bug. The factory is so huge (millions of pages of blueprints) that you can't possibly read every single page to find the mistake. You need a way to zoom in on the exact room and the exact tool that's causing the problem.

This paper introduces a new method called RGFL (Reasoning Guided Fault Localization) to help Artificial Intelligence (specifically Large Language Models, or LLMs) act as better detectives.

Here is the breakdown of how it works, using simple analogies:

The Problem: The "Too Much Information" Trap

In the past, when AI tried to fix code, it often got overwhelmed.

  • The Old Way: Imagine handing the detective a stack of 1,000 blueprints and saying, "Find the broken pipe." The detective might guess based on which blueprint looks most similar to the description of the leak (e.g., "It mentions water, so it must be the kitchen"). This is like matching keywords.
  • The Result: The detective might pick the kitchen blueprint, but the leak is actually in the bathroom. The AI fixes the wrong thing, and the machine stays broken.

The Solution: The "Think Before You Guess" Strategy

RGFL changes the game by forcing the AI to think and explain before it picks a suspect.

  1. The Interrogation (Reasoning): Instead of just scanning the blueprints, the AI looks at one specific room (a file) or one specific tool (a function) at a time. It asks itself: "What does this tool do? How does it relate to the leak described in the report?"
    • Analogy: Instead of just looking at a picture of a wrench and saying "This looks like a plumbing tool," the detective holds the wrench and says, "This wrench is used to tighten the valve that controls the water pressure. If the pressure is wrong, this is the likely culprit."
  2. The Ranking: The AI generates a written explanation for every candidate. Then, it compares these explanations to the bug report to see which one makes the most logical sense.
    • The Paper's Claim: This "reasoning" step is much better than just matching keywords. It helps the AI understand the cause of the problem, not just the surface details.

The Results: Finding the Needle in the Haystack

The authors tested this on real-world software projects (like the famous SWE-bench dataset). Here is what they found:

  • Better File Hunting: When looking for the right "room" (file) in the factory, RGFL found the correct one much more often than previous methods.
    • The Stat: In one test, the old method found the right file 71% of the time. RGFL found it 85% of the time.
  • Better Tool Hunting: Once the right room was found, RGFL was much better at finding the specific "tool" (code element) that needed fixing.
    • The Stat: The old method found the exact tool 36% of the time. RGFL found it 69% of the time.
  • Fixing More Bugs: Because the AI was looking at the right place, it actually fixed more broken programs.
    • The Stat: Using RGFL, the number of successfully fixed bugs went up by nearly 13% compared to the best existing methods.

A Surprising Discovery: Sometimes "Less" is More

The researchers also ran a special experiment to see what happens if they give the AI perfect information (telling it exactly which file, tool, and line is broken).

  • The Finding: Even when they told the AI the exact file, it still failed sometimes.
  • The Twist: In some cases, telling the AI exactly which specific line of code to change actually confused it. It was like telling a chef, "Put salt on the third grain of rice." The chef got so focused on that one grain they forgot the whole dish.
  • The Lesson: Sometimes, it's better to tell the AI, "The problem is in this specific room," and let it figure out the details, rather than micromanaging it down to the exact line.

Summary

This paper proves that if you ask an AI to explain its thinking about why a piece of code might be broken, it becomes a much better detective. It stops guessing based on surface similarities and starts looking for the actual cause. This leads to finding the right code faster and fixing more software bugs.

What the paper does NOT claim:

  • It does not claim this works for every programming language (they only tested Python and Java).
  • It does not claim this is a magic cure for all software errors (some bugs are still too hard for the AI to fix, even with the right location).
  • It does not claim this is ready for medical or critical safety systems yet; it is a research study on open-source software projects.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →