Twoje narzędzie do code review sprawdza każdy PR tym samym playbookiem. Formatowanie? Check. Konwencje nazewnictwa? Check. Znane CVE? Check. Czy kod napisał junior o 2 w nocy, czy autonomiczny agent wygenerował go z wiadomości na Slacku — te same reguły, te same heurystyki, ten sam zielony ptaszek. To jak szukanie duchów wykrywaczem metali. Technicznie skanujesz. Praktycznie — jesteś bezużyteczny.

18 kwietnia CodeRabbit wypuścił analizę multi-repo — ich reviewer śledzi teraz zależności pomiędzy repozytoriami. Fajny trik. Ale jest pytanie, którego wciąż nie zadaje: kto napisał ten kod? Copilot review też go nie zadaje — a wszedł w GA ze swoją agentową architekturą 5 marca. Cursor 3 też nie — mimo że 2 kwietnia odpalił swój agent-first interface. Nic innego na rynku też nie. Ani jedno narzędzie nie zmienia strategii review w zależności od tego, czy autorem jest istota z węgla, czy z krzemu.

To nie jest filozoficzny niuans. To strukturalna ślepa plamka. Własne badanie CodeRabbit z grudnia 2025 na 470 PR-ach mówi wprost: PR-y napisane przez AI mają 75% więcej bugów logicznych i poprawności, generując przy tym 3x więcej problemów z czytelnością. Ale bugi, które narzędzia do AI review faktycznie łapią — formatowanie, kolejność importów, nazewnictwo — to bugi, które popełniają ludzie. Kod AI halucynuje syntaktycznie perfekcyjne wywołania API do endpointów, które nie istnieją. Pisze zestawy testów, które walidują założenia samej implementacji zamiast specyfikacji. Produkuje logikę biznesową, która się kompiluje, przechodzi każdy automatyczny check i po cichu robi nie to, co powinna. Tryb awarii i metoda detekcji nie są nawet w tym samym budynku.

Cloud Security Alliance raportowało 4 kwietnia, że liczba CVE powiązanych z narzędziami AI do kodowania skoczyła z 6 w styczniu do 35 w marcu — 6-krotny wzrost w jednym kwartale. Tymczasem Qodo zebrało 70 mln dolarów 30 marca na "weryfikację kodu". Wszyscy budują szybsze pattern-matchery. Nikt nie buduje jedynej funkcji, która ma znaczenie: powiedzieć reviewerowi, na jaki rodzaj kodu patrzy, zanim zacznie patrzeć.

A tak wyglądałby authorship-aware review. Ląduje PR wygenerowany przez agenta. Narzędzie widzi tag autora — cursor-agent, copilot-workspace, cokolwiek twój bot podpisuje — i przełącza playbook na zupełnie inny. Zamiast sprawdzać styl, sprawdza semantykę: czy ta funkcja odpowiada specyfikacji? Czy ten test weryfikuje zachowanie, czy tylko odzwierciedla implementację? Czy to wywołanie API odnosi się do czegoś, co faktycznie istnieje? To jest przepaść między "wygląda dobrze" a "jest dobrze", i w tej chwili każde narzędzie review na rynku operuje wyłącznie po stronie "wygląda".

Możesz to dziś sfejkować ręcznie. Oznacz PR-y od agentów. Naucz reviewerów, żeby pomijali uwagi o formatowaniu, gdy widzą etykietę, i szli prosto do sprawdzania intencji. Pytaj "czy to robi to, co jest w tickecie?" zamiast "czy to jest zgodne z naszym style guidem?". To koślawe. Ale to jedyne podejście, które działa, dopóki ktoś nie wypuści prawdziwego rozwiązania.

Ironia jest gruba: branża właśnie wydała miliardy, żeby AI pisało kod i AI recenzowało kod, a brakującą funkcją jest jedno pole metadanych. Człowiek czy maszyna? Jeden boolean. Każdy reviewer na rynku go pomija. Każdy z nich ocenia kod, nie wiedząc, kto jest autorem — jak ocenianie wypracowań bez wiedzy, czy napisał je student, czy ChatGPT. Widzieliśmy, jak to działa na uczelniach.

Następne narzędzie do review, które będzie miało znaczenie, nie będzie najsprytniejszym pattern-matcherem. Będzie pierwszym, które uczciwie zapyta, kto jest autorem — i zmieni całe swoje podejście na podstawie odpowiedzi.