"Bug genealogy: why a returning bug looks new in code review"

Full disclosure up front: I work on Bugweg, a GitHub app that reviews pull requests, and I mention it later in this post.

Picture this (a made-up example, not a customer story): six months ago you fixed a null-dereference in a profile formatter. Last week a refactor quietly brought it back. The reviewer saw a clean diff, approved it, and nothing in the process said "we have been here before".

That is the gap. Most reviews, human or automated, judge a pull request mostly on its own diff. Once a PR merges, the context is easy to lose, so a reintroduced bug looks brand new.

What is bug genealogy?

Bug genealogy is the idea that a bug has a life story, not just a single appearance in a diff, and that a reviewer should know the whole story, not just the current chapter. In practice it means tracking four stages:

1. Introduced in one PR.
2. Fixed in a later PR.
3. Reintroduced in a refactor.
4. Locked, once the team turns the pattern into a rule that checks future PRs.

If your review process only sees step 3 in isolation, it cannot tell a new mistake from a repeat.

You can do a manual version today

You do not need a tool to start.

• When you fix a bug, write the pattern in the PR description in one sentence: what the code did wrong, not just what you changed.
• Label fix PRs consistently (for example regression-fix) so you can search them later.
• Before approving a risky refactor, search closed fix PRs for the files it touches.
• Add a test that fails on the old behavior. A regression test is the cheapest lock there is.

This works. It also depends on someone remembering to do it on every PR, which is where it breaks down on a busy team.

Automating the memory

bugweg's Bug Genealogy feature does the lookup for you. Each issue it flags is compared with the bugs it flagged earlier in the same repository, using stored fingerprints and a similarity threshold. When there is a match, the annotation on that issue says it is a recurring bug, how many times it has been seen in the repo, which PR it was first seen in, and how similar it is to the earlier occurrence.

Some limits, so you can judge it fairly:

• It only knows about bugs bugweg itself flagged in that repo. It does not know every bug your repo ever had.
• It runs on PRs that get a full AI review, not on every PR in the repo.
• A match is a prompt to look, not a verdict. It does not catch every bug and does not replace human review.
• Optionally, a team can turn a fixed pattern into a block rule (bugweg calls this the Recurrence Firewall; see the features page). That only blocks a merge if your branch protection requires the bugweg check.

Try it on a repo you already suspect

Pick a repo with a known recurring problem. Open a PR that touches that pattern and read the review. If it connects the PR to the earlier occurrence, the idea is working. If it reviews the PR cold, you have learned something too.

The trial is one-time: 3 free PR reviews per developer. A card is verified with a $0 authorization and is not charged during the trial. To keep getting reviews after that you subscribe; Developer is C$10 per seat per month (C$8 billed annually), plus applicable taxes, in Canadian dollars. See pricing.

The full write-up, with a timeline diagram, is on the bugweg blog: What Is Bug Genealogy?

---

Disclosure: I work on bugweg. Bugweg is an independent product. GitHub is a trademark of GitHub, Inc.; bugweg is not affiliated with, endorsed by or sponsored by GitHub.