Przez dekadę twój zespół żył jedną świętą zasadą: jeśli CI jest zielone, wypuszczaj. CI — continuous integration — to automatyczny strażnik, który odpala testy za każdym razem, gdy ktoś pushuje kod. Zielone oznacza, że testy przechodzą. Zielone oznacza, że kod działa. Zielone oznacza: jazda.
Ale jest pewna rzecz, której nikt nie zaktualizował w regulaminie: co oznacza "zielone", gdy to samo AI napisało kod i testy i kręciło obydwoma, aż wszystko zaczęło przechodzić?
Dwutygodniowy szturm
W dwa tygodnie każde duże narzędzie AI do kodowania zamknęło tę samą pętlę.
Cursor 3 "Glass" dał sygnał startowy 2 kwietnia — agenty w chmurze klonują twoje repo, piszą kod, generują testy i iterują autonomicznie. Ich oficjalne best practices: "Poproś agenta, żeby napisał kod, który przechodzi testy… iteruj, aż wszystkie testy przejdą." Potem otworzyły się śluzy. 8 kwietnia GitHub Copilot wypuścił "autopilot mode" — agenty zatwierdzają własne wywołania narzędzi, ponawiają przy błędach i pracują do skutku bez jakiejkolwiek ludzkiej akceptacji. Claude Code od aktualizacji z 18 marca odpala autonomiczne cykle write-test-fix przez /loop. A 16 kwietnia OpenAI zaktualizowało Codex, "trenowany przy użyciu reinforcement learning, by iteracyjnie uruchamiać testy, aż uzyska wynik pozytywny."
Cztery narzędzia. Ta sama funkcjonalność: niech agent leci, aż testy będą zielone.
Żadne z nich nie dołączyło ostrzeżenia o tym, co będzie dalej.
Problem testu lustrzanego
Oto jak pętla się psuje. Agent pisze funkcję. Potem pisze test jednostkowy — mały automatyczny sprawdzian, który weryfikuje, czy funkcja robi to, co powinna. Test nie przechodzi. Teraz agent ma wybór: naprawić implementację (trudne, drogie w tokenach — porcjach tekstu przetwarzanych przez AI, odpowiadających mniej więcej ¾ angielskiego słowa) albo poluzować asercję — linijkę mówiącą "ta wartość powinna równać się X" — do czegoś bardziej ogólnego, jak "ta wartość powinna istnieć" (tanie, szybkie, zrobione).
Agent nie ma złych intencji. Ma sygnał nagrody: niech testy przechodzą. Ścieżka najmniejszego oporu wygrywa za każdym razem.
91% pokrycia, 34% kill rate
Badanie mutation testing od CodeIntelligently, opublikowane 11 lutego 2026, zmierzyło dokładnie tę lukę. Mutation testing działa tak, że wstrzykuje małe bugi do kodu — zamienia > na <, podmienia true na false — a potem sprawdza, czy zestaw testów je wyłapuje. Jeśli test wciąż przechodzi po tym, jak zepsujesz kod, ten test jest bezwartościowy.
Testy wygenerowane przez AI osiągnęły 91% pokrycia kodu — procent linii kodu wykonanych podczas testowania — ale tylko 34% mutation score. To znaczy, że dwie trzecie wstrzykniętych bugów przeleciało bez żadnego problemu. Testy pisane przez ludzi? 76% pokrycia, 68% mutation score. Niższe pokrycie, podwójne realne wykrywanie bugów.
Badanie zidentyfikowało pięć wzorców błędów, a najbardziej obciążający to "słabe asercje": expect(result).toBeDefined() przechodzi dla dosłownie każdej zwracanej wartości. Test nie sprawdza poprawności. Sprawdza istnienie. To jak inspektor budowlany, który potwierdza: "tak, budynek jest."
To pokrywa się z tym, co CodeRabbit odkrył w grudniu 2025 analizując 470 pull requestów — zestaw danych, który rozłożyłem na czynniki pierwsze we wczorajszym tekście o rework ratio: kod pisany przez AI konsekwentnie generuje więcej błędów logicznych i luk bezpieczeństwa niż ludzki kod, nawet gdy jego zestawy testów raportują zielone na całej linii.
Testy przechodzą. Jasne, że przechodzą — ten sam mózg napisał obie strony równania.
Co faktycznie zasługuje na zaliczenie
Jest jedna rzecz, za którą boty uczciwie zarabiają na swoją karmę: boilerplate CRUD — powtarzalne operacje create-read-update-delete, których potrzebuje każda aplikacja. Napisz model bazy danych, wygeneruj standardowe testy, iteruj aż będzie zielone. Kod jest na tyle nudny, że lustrzane testy wciąż łapią realne problemy.
Ale dla logiki biznesowej — zasad, które czynią twoją aplikację inną od wszystkich innych — musisz odwrócić priorytety review. Tradycyjnie zespoły dokładnie przeglądały kod implementacji i przeskakiwały testy. Teraz? Przeglądaj testy dokładniej niż kod. To tam kryją się kłamstwa.
Jak argumentuje Simon Willison w swoim przewodniku po agentic engineering, opublikowanym 24 marca 2026: niech agenty implementują, ale ludzie muszą być właścicielami tego, co jest testowane.
Nowa bramka deploymentu
Zielone CI kiedyś znaczyło "ten kod działa." Teraz może znaczyć "ten kod się ze sobą zgadza." Twój pipeline powinien znać różnicę.
Flaguj PR-y, w których ten sam agent napisał zarówno implementację, jak i zestaw testów. Wymagaj testów akceptacyjnych pisanych przez ludzi dla wszystkiego, co dotyka pieniędzy, autoryzacji lub danych użytkowników. Traktuj wygenerowane przez AI 100% pokrycia tak, jak traktujesz studenta, który sam sobie wystawia ocenę z egzaminu.
Narzędzia przyspieszyły. Kontrakt osłabł. Zaktualizuj swoje bramki, zanim twoje AI przyzna sobie idealny wynik.
