A Vapi saját kódellenőrző botja felére csökkentette az összeolvasztási időt

Minden pull requestet ellenőriz a bot

A Vapi mérnöke, Lat Ware által létrehozott Pedantic Review Bot akkor indul el, amikor egy jogosult pull request megnyílik, a vázlatként mentett változatokat is beleértve. A szerzők újabb ellenőrzést kérhetnek a bot megjelölésével. A rendszer átugorja azokat a commitokat, amelyeket már ellenőrzött, így az ismétlődő események nem indítanak újabb, fizetős vizsgálatot.

A megállapítások soron belüli megjegyzésként jelennek meg. Mindegyik egy félkövér, egymondatos összefoglalóval és súlyossági jelöléssel kezdődik. A zöld jelzés apró észrevételt, a piros blokkoló hibát jelent. A Vapi korábban két mesterséges intelligenciára épülő kódellenőrző eszközért is fizetett, de Ware szerint egyik sem találta meg azokat a problémákat, amelyeket a korai saját utasítások felismertek a vállalat kódjában.

A fejlesztő szerint a saját bot felépítése azért is bizonyult hasznosnak, mert a vizsgálatok költségét össze lehetett vetni a megtalált hibákkal. A Vapinál a pull requestek megnyitástól összeolvasztásig tartó átlagos ideje a korábbi, több mint 130 óráról 65 órára csökkent.

Külön bot keresi a tervezési hibákat

Az eredeti ellenőrző után a Vapi létrehozta a Pedantic Architecture Review Botot is. Erre azért volt szükség, mert egy tervezési hiba átjutott az első rendszeren. Ware leírása szerint ezt a problémát egyetlen kódsor sem fedte fel.

Az architektúraellenőrző szinte ugyanazt az utasítást használja, mint a fő bot, de általános problémák helyett magas szintű tervezési minták lehetséges hibáit keresi, és magasabb munkaszintet igényel. Jelentést készít, a konkrét kódhelyhez köthető hibákat pedig soron belüli megjegyzésekben jelzi.

A futásokat egy összetettségi szűrő korlátozza. 2026. szeptember 2. és október 2. között 763 architektúra-ellenőrzésből 33 jelentés született. Ugyanebben az időszakban a fő bot 1694 pull requestet vizsgált át, és 276 pull requestben összesen 363 blokkoló hibát jelzett. Ezek több mint fele builddel, tesztekkel, folyamatos integrációval vagy telepítéssel függött össze.

A bot olyan hibákat is talált, amelyeket egy zöld tesztállapot elfedhetett. Például jelezte, amikor tesztállításokat Storybook-történetekkel váltottak ki, amelyeket a tesztfuttató nem gyűjtött össze. Egy másik esetben egy benchmark sikeres eredményt jelentett úgy, hogy valójában egyetlen tesztet sem futtatott. Egy forgalomfelosztási módosításnál az architektúraellenőrző azt is felismerte, hogy két írás rossz sorrendben történt, ezért egy nulla forgalomra szánt kiadás egy időablakban az összes forgalmat megkaphatta.

A pontosság érdekében bizonyítania kell a megállapításait

A bot nem jelez kifogást addig, amíg azt nem ellenőrizte. Az elemzési feladat lefuttatja a pull request kódját, a rendszer pedig szükség esetén követi a hívókat, elindítja a várhatóan hibázó teszteket vagy kis reprodukciót készít.

Az elemzés és a megjegyzések közzététele külön feladatként működik. Az elemzési munkamenet megfosztott Git-hitelesítő adatokkal fut, és JSON-fájlba írja az eredményeket. Egy második feladat ellenőrzi ezt a fájlt, majd futtatás nélkül közzéteszi a megjegyzéseket. A bot hozzászólhat a kódhoz, de nem hagyhatja jóvá a pull requestet és nem küldhet fel módosításokat. A teendőkről a mérnökök döntenek.

A Vapi az elnevezést is a fejlesztés tapasztalatai alapján választotta. Az első változat annyi megjegyzést hagyott, hogy Ware Pedantic Review Botnak, vagyis pedáns ellenőrző botnak nevezte. A csapat visszajelzései után többször módosította az utasításokat, hogy a megjegyzések rövidebbek és könnyebben kezelhetők legyenek. A vállalat szerint a panaszok csökkentek, amikor a mérnökök közelebbről megvizsgálták a pontosnak bizonyuló megállapításokat. A módosított kódrészekben talált, korábban is meglévő hibák javítása így a karbantartási munkafolyamat részévé vált.

Több olcsó futás jobb lehet egyetlen drágánál

Ware közel 200 utasítást próbált ki a boton. Egy kísérletben egyetlen pull requesten az utasítás kezdőmondatának 101 változatát tesztelte, változatlanul hagyva a kódbázis kontextusát, a különbségeket, a hatókört és a JSON-kimenet formátumát. A futások 803 nyers megállapítást adtak, amelyek 57 különálló problémacsoportba rendeződtek. Egy mesterséges intelligenciás értékelő 32 hibát valósnak, 24-et tévesnek, egyet pedig nem ellenőrizhetőnek ítélt.

Az eredmény szerint egyetlen futás sem találta meg a 32 valós probléma közül tíznél többet. Ware végül az egyszerűbb utasítást választotta, mert a téves pozitív jelzéseket szerinte nem szabad figyelmen kívül hagyni. A győztes változat agresszív ellenőrzést kér, soron belüli megjegyzéseket és egymondatos összefoglalót ír elő, valamint a zöldtől pirosig terjedő súlyossági jelölést használja.

A Vapi egy ismert blokkoló hibát tartalmazó, átalakított éles szolgáltatáson is összehasonlította a konfigurációkat. Három, extra magas munkaszintű Sonnet 5.5 kódellenőrzés 12,32 dollárba került, és 44 súlyossággal súlyozott pontot ért el együtt. Egy maximális munkaszintű futás 12,30 dollárért átlagosan 35,5 pontot hozott. A tervezési ellenőrzésnél három extra magas futás 6,36 dollárból 68 pontot, egy maximális futás 11,20 dollárból átlagosan 51 pontot ért el.

A szerző hangsúlyozza, hogy ezek a következtetések még nem általánosíthatók. A promptkísérlet és a modell-összehasonlítás is egyetlen pull requestre támaszkodott, az értékelést pedig mesterséges intelligencia végezte. A Vapi további vizsgálatokat tart szükségesnek, köztük szándékosan beültetett hibákkal végzett teszteket és annak mérését, hogy a mérnökök mely megállapításokat javítják vagy utasítják el.