Mainlane to jeden inżynier i zespół agentów AI. To rodzi uczciwe pytanie: kto sprawdza kod napisany przez AI? Nasza odpowiedź to inna AI — taka, która go nie pisała — a po niej człowiek, który decyduje, czy zmiana trafi na produkcję.
Pętla
- Sesja Claude bierze zadanie i otwiera pull request.
- Osobny recenzent startuje w czystej sesji. Nigdy nie widział, jak powstawał kod, więc czyta diff tak, jak zrobiłby to kolega — bez założeń autora.
- Recenzent zostawia uwagi na trzech poziomach: 🔴 trzeba poprawić, 🟡 warto poprawić, 🟢 miło byłoby mieć.
- Sesja autora je poprawia i odpowiada punkt po punkcie, kończąc sekcją „Weryfikacja”: jakie polecenia uruchomiła i co one wypisały.
- Recenzent sprawdza nowy head. Pętla się powtarza, dopóki nie zostanie żadna uwaga — nawet 🟢.
Uczciwości pilnują dwie zasady. Uwagę można zakwestionować tylko pomiarem — liczbą, wynikiem polecenia, mutantem, którego test nie wyłapuje — a nie stwierdzeniem „jest w porządku”. A po pięciu rundach pętla się zatrzymuje i pyta człowieka, więc nigdy nie kręci się w nieskończoność.
Rola człowieka
Żaden agent nie robi merge’a. Gdy review jest czyste, a CI zielone dokładnie na tym commicie, który widział recenzent, sesja pisze „gotowe do merge’a” i czeka. Merge następuje dopiero wtedy, gdy zgodzi się na niego człowiek, i tylko dla tego samego commita.
Co wyłapuje
Kilka prawdziwych przykładów z repozytorium tej strony:
- W pull requeście, który dodał sprawdzanie Lighthouse do CI, recenzent zauważył, że ustawienie budowania CSS wskazywało zły folder, więc style układu po cichu znikały ze strony. Nie zgłosił tego ani Lighthouse, ani narzędzie do sprawdzania dostępności. Wyłapał też przypięty baner wyboru języka, który mógł zasłaniać element z fokusem osobom korzystającym z klawiatury.
- W kontroli odtwarzania kopii zapasowej bazy danych codzienny test porównywał odtworzone dane z nimi samymi zamiast z eksportem — nigdy nie zauważyłby brakujących wierszy. To samo review znalazło komunikat o błędzie, który mógł zapisać e-mail leada w logach.
- Przy wdrażaniu Content Security Policy raporty z rozszerzeń przeglądarki sprawiłyby, że cel „tydzień bez naruszeń” nigdy nie zostałby osiągnięty, a zewnętrzne obrazy we wpisach na blogu przestałyby działać po włączeniu polityki.
Nic z tego nie było egzotyczne. To rzeczy, które zmęczony człowiek przeoczy w piątkowy wieczór.
W liczbach
Pod koniec października 2026 roku pętla działa w ośmiu repozytoriach: 385 scalonych pull requestów i 1069 review. Większość kosztów to sama praca: w ostatnim tygodniu października około trzech czwartych tokenów idzie na implementację, a mniej niż jedna dziesiąta na review.
Ograniczenia
Recenzent to model tego samego rodzaju co autor, więc może mieć te same martwe pola. Nie zastępuje ludzkiego review ważnych zmian, a tekst w pull requeście traktuje jako dane, nigdy jako polecenia. Zastępuje za to krok, który pomija większość programistów pracujących w pojedynkę: drugą parę oczu przy każdej zmianie.