BugCleaner
A console app that automatically works through the technical-debt bugs in Azure DevOps every week. It generates data fixes with an enterprise LLM and applies them to the lower environments; opens PRs automatically for .NET and Angular bugs; and when it can't solve something, it only reports a suggested fix. It never touches prod. A technical-debt pile assigned in one go is now down to zero.
What Problem Does It Solve?
These bugs didn't pile up over time. The infrastructure team scanned the codebase with an automated detection tool they had built themselves and assigned our team a large pile of technical-debt bugs in one go. None of them were "right now" problems; with sprints already full of new work, working through them by hand would have taken months.
BugCleaner is a console app I wrote to whittle that pile down week by week. It runs every week via Task Scheduler, pulls the technical-debt bugs from Azure DevOps and handles each one according to its type.
BugCleaner runs at VakıfBank on an LLM hosted inside the bank. The source code belongs to the bank.
Decision Table
For every bug, the first question is "what kind of change does this need?" The behavior follows from the answer:
| Bug type | What it does |
|---|---|
| DML (data fix) | Generates the fix with the LLM and applies it to the lower environments. It never touches prod; if the fix needs to go to prod, it adds that to the report. |
| DDL (schema change) | Applies it in dev only, flags that a deployment is needed and adds it to the report. |
| .NET or Angular | Opens a bug branch, commits and pushes the change, creates a pull request and adds the PR link to the report. |
| Complex | If it's beyond what the LLM can solve reliably, it doesn't touch the code at all; it only generates a suggested fix and puts it in the report. |
That fourth row is a deliberate boundary. Where the tool isn't sure, instead of tinkering with the code it gives a human a starting point.
The choice of model also comes down to context: fixing a bug needs the relevant code, table structure and analysis together. So I moved all of my tools to the model with the largest context window available in the bank.
How Does It Work?
Task Scheduler (weekly)
└─ BugCleaner (console app)
├─ Azure DevOps: technical-debt bugs
├─ Classification: DML / DDL / .NET-Angular / complex
├─ In-house LLM: fix or suggestion
├─ Apply: lower environments | branch → commit → push → PR
└─ Email report: resolved, needs deployment, PR links, suggestions
At the end of the week the team gets a single email: which bugs were resolved, which are waiting for deployment, which PRs are waiting for review, and which bugs only have a suggestion.
Results
The pile assigned in one go is down to zero. The tool still runs every week, so new technical debt found by the detection tool gets handled before it piles up. What I like most about it is that it can say "I can't solve this": coming back with a suggestion, without changing any code, on work outside the LLM's reach is what earned the team's trust in the tool.
Muhammed Emin Özdemir
Senior full-stack developer at VakıfBank. Focused on enterprise systems, clean code and LLM-based tools.
More about me →
Comments
Be the first to comment