Agentic AI for Code Quality: A Four-Agent Machine Learning System for Repository Refactoring, Public RAG, Groq Reasoning, and Reinforcement Learning
This paper presents a multi-agent AI framework that integrates rule-based analysis, public RAG, Groq-powered LLM reasoning, and Q-learning reinforcement learning to autonomously detect, refactor, and validate code quality improvements in software repositories, achieving significant reductions in technical debt while preserving functional correctness.
Original paper licensed under CC BY 4.0 (https://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 your code repository as a messy, chaotic attic filled with old boxes, tangled wires, and duplicate tools. For years, you've had a "Code Inspector" (traditional tools like Pylint or SonarQube) who walks in, points at the mess, and hands you a long list of complaints. But here's the catch: the Inspector never cleans up. They just tell you what's wrong and walk away.
This paper introduces a new team of four AI Agents who don't just complain; they actually roll up their sleeves, clean the attic, and prove they didn't break anything while doing it. The researchers built a "self-healing" system where these four distinct characters try to fix the same messy code, and the system picks the winner based on who actually made the place better without causing a disaster.
The Four Agents: A Team of Specialists
The researchers didn't just build one robot; they built a team of four, each with a different personality and skill set, to see which one works best for different kinds of messes.
- The Rule-Based Agent (The Strict Librarian): This agent follows a strict, unchanging checklist. It looks for obvious, boring problems like duplicate imports, extra spaces, or missing comments. It's safe and reliable, like a librarian who knows exactly where every book goes, but it might miss the deeper, more confusing structural problems.
- The RAG Agent (The Researcher with a Library Card): This agent is smart, but it doesn't rely on its own memory alone. Before it suggests a fix, it goes out and grabs the latest "Software Engineering Best Practices" from a public library (using a tool called Tavily to search the web and a local database of rules). It grounds its advice in real, public knowledge, making it less likely to make things up (hallucinate).
- The Groq LLM Agent (The Creative Architect): This agent uses a powerful Large Language Model (running on Groq for speed) to "think" about the code. It looks at the big picture and suggests deep, structural changes, like reorganizing how the whole building is laid out. It's great for complex, semantic problems but needs to be watched carefully so it doesn't get too creative and break things.
- The Q-Learning Agent (The Trial-and-Error Learner): This agent is a student of Reinforcement Learning. It doesn't have a fixed rulebook or a library card. Instead, it learns by trying different actions (like "clean up imports" or "fix exceptions") and getting a score based on how much the code improved. Over time, it learns which moves work best for specific types of messy code.
The "Self-Healing" Pipeline: How They Work
The system doesn't just let these agents run wild. It acts like a strict referee with a very specific game plan:
- The Safe Copy: Before any agent touches the code, the system makes a perfect, safe copy of the repository. No one is allowed to touch the original.
- The Diagnosis: The system scans the code to find "code smells" (bad habits like methods that are too long, too many nested loops, or high complexity).
- The Cleanup: Each agent tries to fix the code on its own copy.
- The Safety Net (The Most Important Part): This is where the paper is very careful. Just because an agent made the code look "cleaner" doesn't mean it's better. The system runs automated tests on the new code. If the tests fail, the fix is thrown out immediately. The code must pass the tests and show an improvement in quality metrics (like lower risk or better maintainability) to be accepted.
- The Winner: The system compares the results. It picks the agent that improved the code the most without breaking the tests.
What the Experiments Showed
The researchers tested this system on four famous "refactoring katas" (practice code repositories designed to be messy): GildedRose, ExpenseReport, Theatrical Players, and Dependency Breaking.
The results were fascinating because no single agent won every time. The "best" agent depended entirely on the type of mess:
- GildedRose: This repository had simple, repetitive problems. The Rule-Based Agent (the Strict Librarian) won here, improving the quality score by 11 points (from 61 to 72). It was perfect for simple, deterministic cleanup.
- ExpenseReport: This one needed better structure and risk management. The RAG Agent (the Researcher) took the lead, improving the score to 68. It turned out that having access to public refactoring guides was the key.
- Theatrical Players: This code needed a deep, semantic reorganization. The Groq LLM Agent (the Creative Architect) was the hero, boosting the score to 69. It understood the complex logic better than the others.
- Dependency Breaking: This was a tough one with tangled dependencies. The Q-Learning Agent (the Learner) performed best, skyrocketing the score from 45 to 74 (a massive 64.44% improvement!). It learned that adaptive, state-based actions were the only way to untangle this specific knot.
What the Paper Says "No" To
The authors are very clear about what this system is not.
- It is not a magic wand that fixes everything perfectly every time.
- It explicitly rejects the idea that one single AI model is the "best" for all situations. The paper argues that different problems need different strategies.
- It rules out the idea that you can just let an AI rewrite code without checking if it still works. The paper emphasizes that without the "metric gate" (tests and score checks), an agent might make the code look pretty but break the actual functionality.
- The paper does not claim this is a solved problem for all software. It admits these results are based on four specific public repositories and that the system currently only works on Python code.
How Sure Are We?
The paper presents these results as measured outcomes from a specific experiment. The authors show concrete numbers: for example, the Dependency Breaking repository saw a 66.67% reduction in issues and a 39.56% reduction in risk when using the Q-Learning agent.
However, the authors are careful to note that these are simulations on a limited set of test cases. They suggest that while the results are promising, the system needs to be tested on many more repositories (25–50 more, they propose) to be sure it works everywhere. They also note that the "quality score" is a composite number they created, which is useful but might not capture every single nuance of software quality.
The Bottom Line
This paper suggests that the future of fixing code isn't just one super-intelligent robot. Instead, it's a team of specialists working in parallel, each using a different strategy (rules, research, creativity, or learning), all under the watchful eye of a strict referee that ensures nothing breaks. The "winner" changes depending on the job, proving that in the world of code quality, variety is the key to success.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.