KeelenAnswer · quality
My app is full of bugs. Where do I start?
Updated 11 September 2026
Start by measuring. Do not guess. Add error monitoring to learn which failures real users hit, and how often. Then rank bugs by how many users they affect. Do not rank by how annoying a bug feels. When the project has a verified test command, write a failing test before each fix. Then later changes can catch that case again. A test makes regressions easier to catch. It cannot promise the bug never returns. If bugs arrive faster than you fix them, improve the test and review pipeline first. Work the backlog after that.
Bug fixing suits a loop such as Keelen. The work is clear. You have a bug you can reproduce, you know what should happen, and you have a test that can check it. Red first proof works when a verified project test command supports it. When it does not, read the evidence and decide if the change is ready.
What to do, in order
Instrument before you triage
An error tracker turns "it is buggy" into a ranked list. Each bug gets a frequency and a stack trace. Most teams learn their loudest complaint is not their most common failure.
Rank by users affected
A crash that hits 30% of signups matters more than a small glitch somebody saw twice. Sort bugs by how many users they hit. Fix anything that blocks payment or signup first. Do that even when the bug is rare.
Write the failing test first
Reproduce the bug as a test that fails, then fix until it passes. This is the single practice that stops a bug list from cycling, and it is what separates a fix from a patch.
Put a gate in front of the branch
Run tests in CI on every pull request. Block the merge while a check is red. Without this, your fix rate and your bug rate stay equal forever.
Look for the shared cause
Long bug lists usually have a few root causes. One boundary may lack validation. An async path may be unhandled. Two environments may differ. Fix one root cause and a dozen symptoms go away at once.
Why bug lists do not shrink
A list that never gets shorter has two causes. Fixes arrive slower than new bugs. Old bugs come back because nothing captured them as tests. The same remedy helps both. Write a test for each fix. Add a gate that holds a change when a required check fails. Track whether your changes reduce the failures users actually meet.
Red-first, enforced rather than encouraged
Red first proof needs a verified project test command. Keelen then adds the new tests without the implementation. It wants a failure before it accepts that proof. Read the failure and the later pass for the same revision, then copy the steps that show the user's case. A test result alone does not prove a full fix.
From an error report to reviewed work
You can turn on Sentry filing. Selected issues then become Requests. The lane stays inside its filing and work in progress limits. The project workflow plans and builds eligible work under your review controls. Later quiet telemetry is a signal. It does not prove the fix worked.
Finding the bugs nobody has reported
Users do not report some kinds of failure. The read only security scan covers those. It checks injection paths and git history secrets. Vulnerable dependencies and infrastructure mistakes are covered too. It shows a coverage map for each group. This is an engineering review. It is not a penetration test. You can send findings to the loop as work.
When Keelen is not the answer
- The app is broken in production right now. Handle the incident first. This work is a planned cleanup. It will not fix an outage.
- If the real problem is the design, you need a rewrite. A person has to make that call.
- You have no repository access.
Hand the work to a loop
Connect a repository and write what you want in plain language. Review the tested pull requests that come back.
FAQ
Which bug should I fix first?
Fix anything that blocks signup or payment first. Then fix the bugs that hit the most users. Counts from an error tracker beat a guess every time.
Can AI fix bugs reliably?
Yes, when you have a reproduction and a test. This is the work it suits best. Without them it is a guess. That is why Keelen requires a failing test before the fix, and runs your suite on a clean checkout afterwards.
What if the fix breaks something else?
That is what the suite on a clean checkout and the CI gate are for. Nothing merges over a red required check, and every change is a single pull request you can revert.