Ten features. Here's exactly which ones are live.

Every issue bugweg flags is embedded (Voyage voyage-code-3, code-retrieval-tuned, 1024 dimensions) and checked against bug_fingerprints — every pattern this repo has ever had flagged — via cosine similarity. Above a 0.82 threshold, the issue's annotation in bugweg's check run tells you this pattern has appeared before, how many times, which PR it was first seen in, and how similar it is. It runs on every PR that reaches the LLM review stage.

Bug genealogy: how bugweg detects recurring bugs →

What is bug genealogy? →

Every file touched by a PR gets three cumulative counters updated: change_velocity (+1 per PR that touches it), complexity_delta, and defect_density (+1 per issue bugweg flags in that file). complexity_delta is a real cyclomatic-complexity score: 1 plus every branch, loop, case, catch, ternary, and &&/|| a tree-sitter parse finds in the file, computed in the same /parse call Stage 2 already makes for signature extraction, so no extra fetch, for files in one of the 5 supported languages that Stage 2 fetched this round. A concurrent test against the live parser found a real bug: Ruby's grammar gives a bare if/elsif/unless keyword the same node type as its statement, so Ruby decision points had been double-counted since the signal shipped. It was fixed, redeployed, and a real complexity value was confirmed landing in the database in place of the old line-diff proxy. Two disclosed approximations remain: it's one score per file, not per function, and LOW-tier PRs, unsupported languages, or files outside Stage 2's 15-file cap still fall back to the original added+deleted-lines proxy. Time decay is applied each time a file is touched again: its existing counters are scaled by a 30-day half-life before this PR's bump is added, so activity from a month ago counts half as much as today's. A file no PR touches keeps its last score on the map until its next PR. The dashboard's risk map shows them as a treemap grouped by folder, coloured in four risk bands so only real hotspots stand out, with test files hidden by default and a ranked list showing what drives each file's score (change velocity, complexity, defect history). Box sizing uses real file line count where it's been captured and falls back to the risk score otherwise.

Code risk prediction: how the file heat map works →

How the predictive bug risk score is calculated →

Off by default: an organization admin must switch it on (confirming the team's developers have been informed). Once on, every flagged issue updates a per-developer cluster profile (running centroids and counts rather than one embedding per issue, so the profile itself is a summary, not a list of your past PRs), and the top 3 patterns for that PR's author are fed back into the Stage 4 review prompt so bugweg can flag "you've done this before." Admins can see every profile and other members only their own; any developer can erase theirs and opt out, switching the feature off deletes all profiles, and profiles inactive for 90 days, or 30 days after a member with a linked login leaves the organization, are deleted. Profiles are still keyed by GitHub login under the hood, but a developer can now self-link every GitHub login they've used to their Clerk account from the Developer Bug DNA screen — the dashboard merges linked logins into one profile, so a login rename no longer fragments their history. Self-reported, and a login already claimed by one account can't be re-claimed by another; not verified against GitHub OAuth (this app has no user-level GitHub login flow, only the org-wide GitHub App install).

Read how Developer Bug DNA works →

Available on Team and Enterprise, and during the free trial. Not included in Developer.

A real standalone pass, not just folded into general review: on MEDIUM+ tier PRs, bugweg extracts function and type signatures from every changed file (via tree-sitter, running in an isolated sandbox service — see Security), then runs a dedicated Sonnet call whose only job is contract consistency — signature mismatches, unhonored return types, call sites not updated to match a changed signature, violated nullability contracts — separate from the general bug-finding review (which still does its own folded-in contract check too, as a fallback). Findings post as their own “Behavioral Contract Validator” section in the PR's check run, and in the dashboard's PR detail view. In our internal test on a pull request with two nullability violations, it flagged both and suggested a fix for each. Like any AI review, it can miss issues or flag ones that aren't real. Its biggest original gap — only seeing callers inside this PR's own diff — is now closed two ways: a bounded scan (reusing Dependency Blast Radius's own call-site search) finds a changed function's callers in files this PR doesn't touch, and now walks up to two hops further — a caller-of-a-caller, and one hop beyond that — with a visited-name guard so a circular call chain can't loop the search forever. In our internal test on a 3-file call chain, a function's direct caller and that caller's own caller were both correctly found and fed into the contract check, a circular chain correctly terminated instead of looping, and a function with no callers anywhere correctly came back empty rather than erroring. What's disclosed, of the same character as every other live feature's caveats: the scan has a bounded file/call-site budget per hop (a very large or very deep repo won't surface every caller at every level — the same tradeoff Blast Radius's own live call-site search already makes), and like the rest of bugweg's review, it's an LLM judgment call against extracted signatures, not a type-checker guarantee.

Read how the Behavioral Contract Validator works →

Describe a failure in plain English and bugweg runs a natural language code search, ranking your indexed codebase by meaning, not keywords, then has Claude judge the top matches for whether they can actually cause it. Open Bug Search from any repo's dashboard. It keeps a per-repo code-embedding index: code chunks are sent to Voyage to be embedded, and the index stores the vectors with file path, git hash and line number, not the code text (see Security). It is keyed by git blob SHA, so unchanged files are never re-embedded. After the first search, the rest of the repo is indexed in the background, in one tarball download rather than file by file, and edited or deleted files are refreshed or pruned. Ranking is an exact cosine search over every indexed chunk (pgvector). The 10 best chunks are re-fetched from GitHub and sent to Sonnet for a HIGH/MEDIUM/CLEAN verdict. Each search shows how much of the repo is indexed and says when the ranking is still partial. In our internal test on a 65-file repo, the file that caused the described bug shared no words with the query, and it ranked first once the index was complete. Files whose names matched the query words did not reach the top 10. Disclosed limits: chunks are fixed 60-line windows rather than parsed functions. Files over 100 KB, vendored or minified files and unsupported languages are not indexed. A search takes about 13 to 25 seconds, most of it the verdict step.

Every flagged issue is checked against your repo's active recurrence_rules. A match above a rule's similarity threshold, on a rule set to block, sets bugweg's GitHub Check Run conclusion to action_required. If your branch protection requires that check, GitHub won't merge the PR until it passes (unless someone with bypass rights overrides it); if it doesn't, it's a clear visible warning on the PR. Warn-only rules are shown on the issue but don't block, and if the similarity check can't run for a PR, no rule is enforced on that review. Rules are created and deleted through the dashboard and scoped strictly to the owning repo. Production Lock also adds a block rule automatically for each production bug it verifies.

Both halves are deployed. The ingest half: a per-repo Sentry/Rollbar webhook listener, stack-trace-to-fingerprint correlation against the same table PR reviews write to, and a Bug Ledger dashboard view. The auto-fix half runs at merge time: when a PR that touches the affected file is merged into your default branch, and bugweg's review of that PR no longer flags the tracked production bug, bugweg links the merge commit as the fix. It then generates a regression test and runs it in an isolated per-job sandbox with a hard timeout, against the commit before the merge and the merge commit. Only a test that fails before and passes after is kept: bugweg opens it as a draft pull request for your team to review and adds a block rule to the Recurrence Firewall. In our internal test on a fixture repo (2026-10-03, through the live tracker webhook with a Sentry-format test event we sent ourselves), the fix PR was merged, the incident was linked to it seconds later, the generated test failed on the old commit and passed on the fix, and a draft regression-test PR opened automatically. A delivery from a real Sentry organization is still untested, and generated tests can still be wrong, so review them like any other PR.

Production Lock stops one step short of merging, by design: it proves a regression test against the fix (fails on the broken commit, passes on the fix) and opens it as a draft pull request. bugweg never merges the pull request itself; your team reviews it.

Read how the Recurrence Firewall and Production Lock work →

Every analysis gets a LOW/MEDIUM/HIGH/CRITICAL impact score, derived from the highest issue severity found in the PR — that core computation is unchanged. Alongside it, changed files now get a best-effort reachability signal shown in both the PR's check run and the dashboard's PR detail view: whether a file is itself entry-point-shaped (routes/, api/, handlers/, etc.) or referenced by one, via a static 1-hop import check against the repo's entry-point files. This is a real static heuristic, not a call graph or runtime trace — it doesn't change the score itself (to avoid altering existing alert-gating behavior), and "no signal found" means unknown, not unreachable. In our internal test on a pull request covering all three cases (an entry-point file, a file imported by one, and a file with neither signal), each was classified as expected. An optional Express middleware (bugweg-express-telemetry, MIT-licensed, not yet published to npm) can report real aggregated route-hit counts into this reachability signal — no per-request tracking, no new vendor, an ordinary counter batched and flushed periodically. In our internal end-to-end test against production (a test Express app with generated traffic), the counts landed in bugweg's database and were picked up by scoring. The same test found and fixed a bug where failed deliveries were dropped; a retest confirmed retried counts now arrive. It only ever covers repos that explicitly opt in and currently only ships an Express package — every other repo, and every non-Express stack, keeps the static-only signal above unchanged.

Read how the User Impact Score works →

Available on Team and Enterprise, and during the free trial. Not included in Developer.

On MEDIUM+ tier PRs with a base commit to diff against, bugweg compares function signatures at the PR's base and head commits (TypeScript, Python, Go, Java and Ruby), and for each function whose parameters or return type changed (up to 5 per PR) it fetches the repo's file tree at the PR head, regex-scans same-language files for call sites (bounded: 40 files and 15 call sites per changed function, 120 files total per PR), and has Claude Sonnet verdict each one 🚫 breaking / ⚠️ at-risk / ✅ safe with a stated reason, defaulting to at-risk when a snippet is ambiguous. In our internal end-to-end test, it caught a real breaking call site for a changed signature.

Read how Dependency Blast Radius works →

Available on Team and Enterprise, and during the free trial. Not included in Developer.

Measured, not guessed: on every MEDIUM+ tier PR, bugweg runs your own vitest, jest or pytest suite with coverage on the PR head, then flags new or changed functions whose added lines never execute (.ts, .py, .go, .java and .rb files; up to 8 functions per PR). It runs in an isolated sandbox (see Security): customer code runs as an unprivileged user, the dependency install can reach only the npm and PyPI registries, and the tests themselves run with outbound network blocked (verified in our own test on 2026-10-03). For each gap it writes a suggested test, and runs up to 3 of them per PR in the sandbox. The check run lists each suggested test by file path, marked ✅ passed, ⚠️ failed or not run, with how many of the flagged lines it executed. Suggested tests beyond those 3, and for Go, Java or Ruby files, are listed as not run. In our internal tests on real PRs, it worked for all three frameworks. A function reached only through another tested function was correctly left unflagged, and a function called only inside a skipped test was correctly flagged. A purely static scan would typically get both of those wrong. When the real run can't happen, the check run says so and falls back to a clearly labelled static scan. That happens when dependencies fail to install, the setup is unsupported (pnpm workspaces, Go, Java or Ruby), or install or tests exceed 120 seconds. Disclosed limits: .tsx and JavaScript files are not analyzed, npm installs skip postinstall scripts, git and private-registry dependencies are unreachable, one project is measured per PR in a monorepo, and one-line functions are approximate.

Read how the Test Coverage Gap Localizer works →

Not one of the original ten, added after market research: every PR — including LOW-tier docs-only or image-only diffs that skip the LLM review — is scanned with regex and Shannon-entropy checks for hardcoded AWS/GitHub/Slack/Stripe-shaped credentials and private key blocks. The matched value itself is not stored or echoed back, only a description of the credential type.

Teams can add a .bugweg.yml to exclude paths (glob patterns) or override severity per bug type. It is read from the PR's base commit on every PR, so a pull request can't change the config that reviews it; edits to .bugweg.yml take effect after merge.