Developer Bug DNA: What It Actually Tracks

Developer Bug DNA is bugweg's feature for tracking the specific categories of mistakes an individual developer tends to make — the bug categories that show up most often across their PRs — and using that history to make review comments more targeted. It's a live feature in bugweg today, not a roadmap item.

What it's for

If a developer has hit a particular kind of bug before — an off-by-one in pagination logic, a missed null check on a specific data path — a review comment that references that pattern is more useful than one treating every PR as a blank slate. Developer Bug DNA is the mechanism bugweg uses to build and apply that per-developer pattern history.

How it works

Every flagged issue updates a per-developer cluster profile. The profile stores running averages and counts, never raw per-issue embeddings, so the profile isn't built to be traced back to specific PRs. When a PR is reviewed, the top three patterns for its author are fed back into the review, so bugweg can say "you've done this before." The profile is viewable per repo in the dashboard.

Profiles are keyed by GitHub login. A developer can link every login they've used to their bugweg account from the Developer Bug DNA screen, and the dashboard merges them into one profile, so a login rename doesn't fragment their history. That link is self-reported: it isn't verified against GitHub, because the app has no user-level GitHub login, only the org-wide GitHub App install.

How it relates to Genealogy and the Firewall

Developer Bug DNA is related to, but distinct from, Bug Genealogy, which tracks bugs at the repo level across PRs over time, and the Recurrence Firewall, which lets a team turn a fixed bug's pattern into a rule that flags or blocks matching changes. Genealogy remembers what a codebase has done wrong before; Bug DNA is aimed at what a specific person's PRs tend to show. They're complementary, not the same feature under two names. For how these fit against other AI reviewers, see the feature comparison.

The straightforward way to evaluate it is to look at the comments it produces on your own PRs and check whether they reference patterns specific to you rather than generic style nits. That's a better signal than any description of the feature, including this one.