Rozliczenie per użytkownik zamienia 60-centowy przegląd kodu w 4 dolary

Zrób podział na swoim rachunku za AI code review. Nie cena katalogowa, ale rzeczywisty podział: ile zapłaciłeś w zeszłym miesiącu, podzielone przez liczbę pull requestów, które przejrzał. Zrobiłem to dla naszego zespołu i wynik był tak dużo gorszy niż liczba na stronie z cenami, że pomyślałem, że popełniłem błąd.

Nie popełniłem błędu. Po prostu kupowałem produkt tak, jak mi go sprzedano, a nie tak, jak go używamy.

Oto teza, a wszystko poniżej jest jej dowodem. AI code review jest sprzedawane na dewelopera, a konsumowane na pull request. Te dwie liczby nie mają ze sobą nic wspólnego, a luka między nimi to miejsce, gdzie idą twoje pieniądze. Osobno, i co gorsza, narzędzie, za które płaciliśmy, przeczytało diff z sześcioma prawdziwymi defektami i znalazło jeden.

Zastąpiliśmy go czymś, co sami zbudowaliśmy. Pokażę ci rachunki dla obu twierdzeń, włącznie z częściami, które sprawiają, że wyglądamy gorzej.

Sześć defektów weszło. Jeden wyszedł.

Pull request dotyczył refaktora autosave w naszej platformie. Zwykły, średniej wielkości, taki, który otwiera się we wtorek i nikt nie traci przez niego snu. Greptile go przejrzał, zostawił dwa komentarze i poszedł dalej.

Potem jeden z naszych inżynierów przeszedł przez diff ręcznie i właściwie go ocenił, spisując każdy prawdziwy defekt, nie patrząc na to, które narzędzie co zgłosiło. Sześć defektów. Cztery z nich P1, takie, które psują dane użytkownika, a nie tylko kogoś denerwują.

Autosave uzbrajał się na zawsze po normalizacji wartości. Nieudane zapisywanie ponawiało próbę w nieskończonej pętli. Autosave nadpisywał to, co użytkownik aktywnie pisał w innej karcie. Promise zapisu został odrzucony bez obsługi. Opuszczenie strony porzucało wszystko oczekujące. Przycisk zapisu renderował się tylko wtedy, gdy kroku nie można było zapisać.

Jeden z tych sześciu został zgłoszony.

Żaden z tych sześciu nie trafił na produkcję, i chcę być precyzyjny co do przyczyny, ponieważ powód jest całym sednem. Zostały wyłapane, ponieważ człowiek przeczytał diff. Nie dlatego, że reviewer je zatrzymał. Płaciliśmy za siatkę bezpieczeństwa, która złapała jedną rzecz z sześciu, a rzeczą, która złapała pozostałe pięć, był inżynier czytający kod linia po linii, czyli dokładnie ta czynność, którą produkt ma redukować.

Pewne stwierdzenie odwrotności jest gorsze niż milczenie

Było siódme znalezisko. Nie było prawdziwe.

Powiedziano nam: „nieudane autosave nie ma retry”. Rzeczywisty defekt, znajdujący się w tej samej funkcji, był przeciwny: nieudane autosave ponawiało na zawsze. Nie przeoczony błąd. Odwrócony.

Myślałem o tym jednym więcej niż o pięciu przeoczeniach razem wziętych. Przeoczenie to cisza, a cisza jest do przeżycia, ponieważ już zakładasz, że twój reviewer nie jest wszechwiedzący. Odwrócenie jest gorsze niż cisza. Wysyła inżyniera do poprawnego pliku, szukając złej rzeczy, a kiedy nie znajduje rzeczy, której nigdy nie było, zamyka plik i oznacza go jako przejrzany. Fałszywy raport nie tylko nie pomaga. Wydaje twoją uwagę, i wydaje ją dokładnie w miejscu, gdzie ukrywał się prawdziwy błąd.

Jeden model oznacza jedną ślepą plamkę, i nigdy nie poznasz jej kształtu

Moja pierwsza reakcja była taka, że kupiliśmy złe narzędzie. Ta reakcja była błędna, a przejście nad nią zajęło mi dłużej, niż chciałbym przyznać.

Każdy frontier model ma ślepe plamki i nie są to te same ślepe plamki. To nie jest defekt w produkcie żadnego konkretnego dostawcy, to jest to, czym są te systemy. Co oznacza, że jeśli zbudujesz swój proces review na dokładnie jednym modelu, zbudowałeś go na dokładnie jednym wzorcu ślepoty, i nigdy nie poznasz kształtu tego wzorca, ponieważ jedynym instrumentem, który mógłby ci go pokazać, jest instrument, który jest ślepy.

Pozwól, że to wyjaśnię. Problem nie polega na tym, że twój reviewer jest zły. Problem polega na tym, że twój reviewer jest pojedynczy. Druga opinia nigdy nie była luksusem w code review, była całym mechanizmem, dzięki któremu code review działało, i po cichu ją porzuciliśmy w momencie, gdy to zautomatyzowaliśmy.

Więc zbudowaliśmy Juror. Kilka frontier modeli przegląda ten sam diff równolegle, każdy przez własny natywny agent harness, każdy wolny do przeszukiwania twojego repozytorium w sposób, jaki zamierzył jego dostawca. Ich znaleziska są scalane, więc trzy prawie-duplikujące się raporty jednego defektu stają się jednym znaleziskiem zamiast trzema, a to, co ląduje na pull requeście, to pojedynczy komentarz.

Uruchomiliśmy go na tym samym commicie.

Recenzent	Znalezione	Precyzja	Koszt	Czas
Greptile	1 z 6	50%	nie ujawniono	nie ujawniono
Juror	4 z 6	100%	$1.08	8m22s

Oto część, w której przegrywamy

Juror przeoczył dwa.

Greptile złapał odrzucony promise zapisu, a my nie. Żadne narzędzie nie znalazło nieskończonej pętli ponawiania. Złóż oba reviewery razem, a dostajesz pięć z sześciu, co jest lepsze niż którekolwiek z osobna, i nie zamierzam tego ukrywać pod powyższą tabelą.

Mogłem wyciąć tę sekcję. Zachowuję ją, ponieważ to jest argument. Różne modele łapią różne rzeczy. To nie jest niezręczne zastrzeżenie przypięte do naszej oferty, to jest oferta, a model konkurenta znajdujący coś, co nasz przeoczył, jest najczystszym dostępnym dowodem na to, że uruchamianie pojedynczego reviewera jest błędem. Dzień, w którym to przestanie się dziać, będzie dniem, w którym zacznę się martwić, że nasze jury skurczyło się do jednej opinii w czterech kapeluszach.

Nie płacisz za review. Płacisz za krzesła.

Teraz rachunek, czyli miejsce, w którym to przestaje dotyczyć jednego pull requesta.

Plan Pro Greptile to 30 dolarów za miejsce na miesiąc, według stanu na sierpień 2026. Obejmuje to 50 kredytów na miejsce, gdzie jeden kredyt kupuje standardowy review, a trzy głębszy, a dodatkowe kredyty kosztują 1 dolara każdy.

Za recenzję to tanio. Mniej więcej sześćdziesiąt centów, jeśli wykorzystasz każdy przyznany kredyt. Chcę być całkowicie uczciwy: w przeliczeniu na jednostkę to mniej niż koszt naszego własnego narzędzia w przypadku powyższego pull requesta. Mały zespół, który w pełni wykorzystuje swój limit, powinien kupić miejsca i nie będę udawał, że jest inaczej.

Nikt nie wykorzystuje w pełni swojego limitu.

Jesteś rozliczany za programistę. Recenzje zużywasz na pull request. Te dwie liczby przestają być ze sobą zgodne w momencie, gdy liczba pracowników rośnie szybciej niż tempo mergowania, czyli od razu, w każdej organizacji inżynieryjnej, jaka kiedykolwiek istniała. Dwudziestu inżynierów na Pro to 600 dolarów miesięcznie i tysiąc kredytów. Jeśli ten zespół merguje 150 pull requestów, całkowicie normalny miesiąc, zapłaciłeś 4 dolary za recenzję i pozwoliłeś wygasnąć 850 kredytom.

Cena katalogowa się nie zmieniła. Zmieniło się Twoje wykorzystanie. Sześćdziesiąt centów stało się czterema dolarami i nikt nie wysłał Ci o tym maila.

Nazwijmy to podatkiem od miejsca: pieniądze wydane na licencję na programistę za produkt zużywany na artefakt. Jest niewidoczny na stronie z cenami, skaluje się wraz z zatrudnianiem, a nie z użyciem, i jest największą pozycją w tym, co faktycznie płacisz.

Mogę Ci powiedzieć, ile to kosztowało, bo drukujemy rachunek

Juror nie ma miejsc. Działa na Twoim własnym runnerze GitHub Actions, wywołuje API modeli z Twoimi własnymi kluczami, a rachunek to koszt inferencji i nic więcej. Ta recenzja PR-a z autosave, cztery prawdziwe defekty i zero fałszywych alarmów, kosztowała 1,08 dolara i zajęła osiem minut i dwadzieścia dwie sekundy.

Mogę Ci to powiedzieć co do centa, ponieważ każda recenzja Jurora kończy się tabelą: każdy model, jego tokeny wejściowe, tokeny z cache, tokeny wyjściowe, dolary. Każda liczba jest oznaczona jako reported, gdy dostawca ją obliczył, lub estimated, gdy wyliczyliśmy ją z opublikowanych cen katalogowych. Gdy harness nie podaje ani jednego, ani drugiego, drukuje unknown, a suma jest oznaczona jako dolne oszacowanie. Nie zgadujemy i nie zaokrąglamy na swoją korzyść.

Teraz spójrz jeszcze raz na dwie komórki w tej tabeli, które mówią „not disclosed”. To nie jest luka w moich badaniach. Narzędzie nie mówi Ci, ile kosztowała recenzja, bo nie musi. Kupiłeś miejsce. Ekonomika jednostkowa to sprawa dostawcy, a dostawca wolałby, żebyś nadal mnożył po swojemu.

To było to, czego naprawdę chciałem i nie mogłem kupić za żadną cenę. Nie tańszy recenzent. Recenzent, który mówi mi, ile wydał.

Czego nie zamierzam robić, to nazywać tego benchmarkiem

To jest jeden pull request.

Nasz własny protokół benchmarkowania mówi, że decyzja o zastąpieniu wymaga 20 do 30 rozstrzygniętych PR-ów obejmujących frontend, backend, migracje, współbieżność, kod wrażliwy na bezpieczeństwo oraz zarówno małe, jak i duże diffy. Mamy jeden. Leży w repozytorium z ostrzeżeniem, że nie może być przedstawiany jako statystycznie wystarczający dowód, że któryś z recenzentów może zastąpić drugiego, i nie zamierzam łamać własnego ostrzeżenia w poście na blogu o tym, jak starannie raportujemy liczby.

Cztery na sześć przeciwko jednemu na sześć to nie wynik benchmarku. To jeden rozstrzygnięty przypadek, który sprawił, że byłem skłonny uruchomić oba obok siebie. Inny pull request, taki który mocno opiera się na kontekście całego repozytorium, gdzie indeksowany recenzent powinien sobie dobrze radzić, mógłby to odwrócić. Jeśli tak się stanie, ten przypadek również trafi do korpusu.

To, co nie jest próbką jednego, to arytmetyka. Trzydzieści dolarów za miejsce razy dwudziestu inżynierów to 600 dolarów, czy mi się to podoba, czy nie, a 150 recenzji na tysiąc kredytów to 15% wykorzystania w dowolnym miesiącu, który zechcesz zmierzyć. Przerzuciliśmy się na strukturę cenową, którą mogę obronić dzieleniem, i na jeden obiecujący przypadek. Nie na twierdzeniu o wydajności, którego jeszcze nie zasłużyliśmy.

Zmierz nas

Nie bierz mojego słowa za to wszystko. Mam komercyjny interes w Twojej konkluzji i powinieneś odpowiednio ważyć wszystko powyżej.

Uruchom obu recenzentów w trybie shadow na swoim własnym repozytorium. Pozwól im działać przez kilka tygodni, bez blokowania mergowania przez żadnego z nich. Następnie weź wszystkie znaleziska, usuń etykiety, aby nikt nie wiedział, które narzędzie co powiedziało, i poproś starszego inżyniera o rozstrzygnięcie ich na zimno względem kodu. Policz, co każdy złapał. Policz, co każdy wymyślił.

Dostarczyliśmy narzędzia właśnie do tego, bo sami tego potrzebowaliśmy:

npx juror-ai benchmark --file your-corpus.json

Raportuje recall, precision, wskaźnik duplikatów, koszt i opóźnienie dla każdego recenzenta, któremu go podasz, i wymienia każde przeoczenie z nazwy. Nasze również.

Nie sądzę, aby model miejsc przetrwał kontakt z kimś, kto dokona dzielenia. Przetrwa teraz, ponieważ dzielenie jest lekko irytujące, a strona z cenami jest tak ułożona, żebyś się tym nie przejmował. Ktoś w Twojej organizacji w końcu przeprowadzi to obliczenie. Kiedy to zrobi, odpowiedź nie będzie wynosić sześćdziesiąt centów.

Ten pull request z autosave został zmergowany dziś rano, tak przy okazji. Wymagało to dwóch dodatkowych commitów: jeden, aby zapisy nawigacji były single-flight, a drugi, aby autosave zbiegał się i zostawił builder w spokoju. Dobre commity. Nic się nie pali.

Nikt nigdy nie będzie wiedział, że były konieczne, ponieważ błędy złapane przed mergowaniem nie pozostawiają śladu i nie generują raportu o incydencie. To jest ta część, która powinna Cię niepokoić. Recenzent, który przeoczył pięć z nich, kosztuje tyle samo, czy znajdzie sześć, czy zero, i nigdy Ci nie powie, za który z tych dwóch miesięcy właśnie zapłaciłeś.

---

Juror jest open source na licencji MIT: github.com/juror-ai/juror. Cennik Greptile cytowany z greptile.com/pricing według stanu na sierpień 2026.