Így szállítunk termékeket MI-alapú kódellenőrzéssel minden pull requestnél

A Mainlane egy mérnök és egy csapatnyi MI-ügynök. Ebből jogos kérdés adódik: ki ellenőrzi a kódot, amelyet egy MI írt? A válaszunk: egy másik MI, amely nem vett részt a megírásában – majd egy ember, aki eldönti, kikerülhet-e élesbe.

A kör

1. Egy Claude-munkamenet átvesz egy feladatot, és megnyit egy pull requestet.
2. Egy külön ellenőrző tiszta munkamenetben indul. Sosem látta, hogyan készült a kód, ezért úgy olvassa a diffet, ahogy egy kolléga tenné – a szerző feltevései nélkül.
3. Az ellenőrző három szinten jelzi a megállapításait: 🔴 kötelező javítani, 🟡 érdemes javítani, 🟢 jó lenne.
4. A szerző munkamenet kijavítja őket, és pontról pontra válaszol, egy „Ellenőrzés” szakasszal zárva: milyen parancsokat futtatott, és mit írtak ki.
5. Az ellenőrző megnézi az új állapotot. A kör addig ismétlődik, amíg egyetlen megállapítás sem marad – még 🟢 sem.

Két szabály tartja tisztességesen a folyamatot. Egy megállapítást csak méréssel lehet vitatni – egy számmal, egy parancs kimenetével, egy mutánssal, amelyet egy teszt nem fog meg –, nem azzal, hogy „ez így jó”. Öt kör után pedig a folyamat megáll, és embert kérdez, így sosem pörög a végtelenségig.

Az emberi rész

Egyetlen ügynök sem merge-öl. Ha a kódellenőrzés tiszta, és a CI zöld pontosan azon a commiton, amelyet az ellenőrző látott, a munkamenet azt írja: „merge-re kész”, és vár. A merge csak akkor történik meg, ha egy ember jóváhagyja, és csak ugyanarra a commitra.

Mit fog meg

Néhány valós példa a weboldal repójából:

• Abban a pull requestben, amely Lighthouse-ellenőrzéseket adott a CI-hoz, az ellenőrző észrevette, hogy egy CSS-buildbeállítás rossz mappára mutatott, így az elrendezés stílusai csendben eltűntek az oldalról. Ezt sem a Lighthouse, sem az akadálymentességi ellenőrző nem jelezte. Azt is kiszúrta, hogy egy rögzített nyelvi sáv eltakarhatja a fókuszban lévő elemet a billentyűzetet használók elől.
• Az adatbázismentés visszaállításának ellenőrzésében a napi teszt a visszaállított adatokat önmagukkal hasonlította össze az export helyett – a hiányzó sorokat sosem vette volna észre. Ugyanez a kódellenőrzés talált egy hibaüzenetet, amely egy érdeklődő e-mail-címét a naplókba írhatta volna.
• A Content Security Policy bevezetésénél a böngészőbővítményektől érkező jelentések miatt az „egy hét szabálysértés nélkül” cél sosem teljesült volna, a blogbejegyzések külső képei pedig eltörtek volna, amint a szabályzat életbe lép.

Egyik sem volt egzotikus. Pontosan az a fajta hiba, amely egy fáradt embernek péntek este elkerüli a figyelmét.

Számokban

2026 október végén a kör nyolc repóban fut, 385 merge-ölt pull requesttel és 1069 kódellenőrzéssel. A költség nagy része maga a munka: október utolsó hetében a tokenek nagyjából háromnegyede a megvalósításra, kevesebb mint tizede a kódellenőrzésre ment.

Korlátok

Az ellenőrző ugyanolyan típusú modell, mint a szerző, így közös vakfoltjaik lehetnek. Nem helyettesíti a fontos változtatások emberi átnézését, és a pull requestben lévő szöveget mindig adatként kezeli, sosem utasításként. Amit viszont kivált, az az a lépés, amelyet a legtöbb egyedül dolgozó fejlesztő kihagy: egy második szempár minden egyes változtatáson.

Ha ugyanezt a folyamatot szeretné a csapatában, ez az egyik szolgáltatásunk – vegye fel velünk a kapcsolatot.