A CodeRabbit újragondolta, hogyan rangsorolja a pull requesteket

A rendezett lista önmagában kevés

A CodeRabbit 2026. szeptember 18-i bejegyzése szerint az AI-alapú kódolási eszközök és ügynökök felgyorsítják a kód elkészítését és a pull requestek megnyitását. Ahogy azonban nő a PR-ek száma, a csapatoknak el kell dönteniük, melyik változtatás igényel először figyelmet, és ki tudja előrevinni az adott munkát.

A vállalat kezdetben egy rendezett, beérkező levelekhez hasonló sorral próbálta kezelni a problémát. A megoldás azonban félrevezető helyzeteket is eredményezett. Egyes PR-eket például felülvizsgálatra váróként jelölt, noha már jóváhagyták őket. Olyan jóváhagyott PR-ek is ebbe a csoportba kerültek, amelyeknél merge-konfliktus miatt a szerző következő lépése a rebase lett volna.

A CodeRabbit szerint így a felülvizsgálónak minden PR-t meg kellett nyitnia, hogy ellenőrizze, valóban neki kell-e cselekednie. Ez csökkentette a munkasor hasznosságát, ezért a rendszernek előbb azt kell meghatároznia, mi a következő szükséges lépés, és ki a felelős érte.

Előbb munkafolyamat, utána prioritás

A Triage két külön feladatra bontja a döntést. A munkafolyamat besorolása explicit szabályok alapján határozza meg a PR állapotát, a következő lépést, a felelős szerepkört, valamint azt, hogy egy művelet vagy felülvizsgálat késésben van-e. Ezeket a döntéseket a rendszer AI-modell nélkül hozza meg.

A szabályok sorrendje szerint a lezárt vagy nem követett PR-ek untracked állapotba kerülnek. Ezt követi többek között a lezárásra jelölt, döntést igénylő, frissítést igénylő, blokkolt és felülvizsgálatra váró állapot. A rendszer olyan végső műveletet is kijelölhet, mint a merge, a szerző frissítése, a felülvizsgálat, a frissítés, a lezárás, a megfigyelés vagy a visszaaktiválás.

A besorolás minden alkalmazható okot rögzít, de az állapotot az első megfelelő szabály alapján választja ki. A CodeRabbit indoklása szerint az emberi döntést igénylő kérdések megelőzik a mechanikus javításokat. Ezért kerül például a döntést igénylő állapot a konfliktusok kezelése elé, ha egy PR már meglévő munkát ismétel.

A P0 és P3 közötti prioritás nem azonos a teendővel

A prioritás számítása a CodeRabbit szerint ellenőrizhető bizonyítékokra és determinisztikus szabályokra épül. Három jel számít: a jelenlegi, ellenőrzött felülvizsgálati hibák súlyossága, a kapcsolódó Linear- vagy Jira-ügy sürgőssége, valamint az, hogy hány másik nyitott PR vár az adott változtatásra.

Mindhárom értéket 0 és 1 közé normalizálják, a hiányzó jel pedig nullának számít. Az eredmény P0, P1, P2 vagy P3 prioritási szint lehet. A CodeRabbit szerint egyetlen erős jel is magas prioritást eredményezhet, több közepes jel pedig erősítheti egymást. A belső jelek önmagukban nem nyilváníthatnak vészhelyzetet, ezért ilyen esetben a rendszer P0 helyett P1-et ad, 84-es pontszámmal.

Egy teljesen felül nem vizsgált PR, amelyhez nem kapcsolódik ügy és amelytől más nyitott PR-ek sem függenek, 0 pontot és P3 besorolást kap. Ez nem azt jelenti, hogy a változtatás értéktelen vagy már ellenőrizték, csak azt, hogy a rendelkezésre álló bizonyítékok nem támasztanak alá magasabb rövid távú prioritást. A felülvizsgálati bizonyítékok egy új commit után elévülnek, a státusz és a prioritás pedig külön mezőkben marad látható.

A rendszer emellett egy repository-szintű modellt használ a PR-ek összehasonlítására. A modell figyelembe veszi többek között a várható értéket, a hátralévő munkát, az időérzékenységet, az információs értéket, az újramunka kockázatát, a függőségi sorrendet és a szükséges emberi döntés mennyiségét. Így a felhasználók a prioritás mellett azt is láthatják, mi a következő teendő, és kihez tartozik.