Bugweg's code review pipeline is built around a simple observation: an AI pass that reads every pull request the same way is either too slow to be useful or too shallow to catch anything real. So the pipeline combines a structural, deterministic check with an AI step, and the two are only combined when the risk of the change justifies it.
Every PR is first triaged into a risk tier. That triage decides how much machinery gets applied downstream. Trivial, low-risk PRs can skip the AI step entirely and get a lighter pass. Higher-risk PRs get structural, static analysis of the changed functions and types first — the kind of check that doesn't require a model's judgment to apply. Only after that does the AI step run, and it runs with more context than the diff alone: the issues found so far are matched against the repository's own bug history first.
Why genealogy comes before the AI step
That matching step is what bugweg calls Bug Genealogy — tracking a bug across its whole lifecycle, from introduced to fixed to reintroduced to locked, as one continuous record instead of a series of disconnected pull request checks. Feeding that history in before the AI step runs means the model isn't starting from scratch on whether a pattern looks risky; it has the prior that this shape of bug has shown up in this repo before, possibly more than once. That's why genealogy matching sits upstream of the AI step rather than the AI step running on raw diffs alone.
The output of all of this is still just one comment on the pull request, with findings carrying a severity tier. Structural analysis narrows what's worth attention, genealogy supplies what's happened before, and the AI step adds judgment the first two can't make on their own — for instance, whether a reintroduced pattern is actually dangerous in its new context or only superficially similar. That judgment is still probabilistic; it's a flagged finding for a human to weigh, not a verdict, and nothing here is positioned as a replacement for that human read.
There's a real tradeoff worth naming rather than glossing over. Running structural analysis and genealogy matching before every AI check adds latency to any PR that lands above the risk threshold. Bugweg accepts that cost for the changes where it matters and skips it where it doesn't — the triage step exists so a one-line config tweak isn't put through the same machinery as a change to something more consequential. Picture a team that routes every PR, regardless of size, through the full sequence: the overhead would fall hardest on exactly the changes least likely to need it. Tiering by risk is the mechanism meant to avoid that, not an afterthought bolted on top of it.
None of this works if the underlying premise is wrong, and the premise is the same one that runs through PAFTAK's other practice areas: deciding what gets scrutiny, what history gets consulted, and what judgment gets surfaced to a human is an access-control problem in disguise — the same question an IAM or PAM system asks about which request gets a privileged grant. Bugweg just asks it about code changes instead of logins: triage first, context next, human judgment last.