Jak używam Codexa do review 15 projektów bez oddawania końcowej kontroli

Jeszcze kilka lat temu pomysł, że będę naprawdę dokładnie przeglądał 15 projektów software’owych równolegle, wydawałby mi się mało realny. Nie chodzi o otwarcie 15 repozytoriów i szybkie spojrzenie. Chodzi o regularne sprawdzanie prawdziwych projektów pod kątem błędów, błędnych założeń, problemów SEO, pomyłek w tłumaczeniach, niespójności lokalizacji, brakujących testów, regresji i starego kodu, który przestał pasować do reszty systemu.

Ograniczeniem nigdy nie była szybkość pisania. Była nim uwaga. Każdy projekt ma własną historię, konwencje, edge case’y i fragmenty, które wyglądają źle, ale istnieją celowo. Porządny review wymaga czytania, wyszukiwania, porównywania, uruchamiania kontroli i dopiero potem decyzji, co naprawdę powinno się zmienić.

Codex zmienił dla mnie koszt tej powtarzalnej pracy. Może zrobić pierwszy przebieg po repozytorium, śledzić referencje, przeglądać powiązane pliki, wskazywać podejrzane patterny, proponować testy i pomagać badać miejsca, które wcześniej musiałbym otwierać jedno po drugim. To nie automatyzuje końcowej decyzji. Przyspiesza kosztowną część pracy poprzedzającą decyzję.

Najważniejsza zasada jest prosta: nie używam Codexa po to, żeby usunąć siebie z review loop. Używam go, żeby ten loop poszerzyć.

Prawdziwym wąskim gardłem jest powtarzalność, nie pisanie kodu

Przy jednym projekcie można pamiętać zaskakująco dużo kontekstu. Przy wielu projektach przestaje to skalować. Te same klasy pracy wracają stale:

• szukanie podobnych bugów w różnych komponentach;
• sprawdzanie, czy po refactorze nie został stary call site;
• review testów po zmianie zachowania;
• wyłapywanie niespójności w metadata, logice językowej, headings czy linkach wewnętrznych;
• porównywanie localization keys i przetłumaczonej treści;
• szukanie brakującego error handling i edge case’ów;
• sprawdzanie, czy „mała” zmiana nie dotknęła zbyt wielu plików;
• czytanie diffów prostych osobno, ale kosztownych łącznie.

Żadne z tych zadań nie jest efektowne. Wszystkie są ważne. Gdy ten sam typ review trzeba powtarzać w wielu codebase’ach, koszt rośnie bardzo szybko.

Właśnie tutaj AI coding agent jest dla mnie najbardziej wartościowy. Może przejąć powtarzalną część przestrzeni wyszukiwania, żebym ja mógł poświęcić więcej uwagi ocenie.

Zaczynam od inspekcji, a nie od zgody na przepisanie wszystkiego

Jednym z najłatwiejszych sposobów na słaby wynik jest zadanie „przejrzyj cały projekt i napraw wszystko”. Brzmi wydajnie, ale miesza discovery, priorytety, architekturę, implementację i walidację w jedną niekontrolowaną pracę.

Znacznie lepiej działa rozdzielenie etapów.

inspect → explain findings → prioritize → change → validate → review diff

Najpierw chcę, żeby agent zrozumiał odpowiedni obszar i wyjaśnił, co znalazł. Potrzebuję konkretnych ścieżek plików, dotkniętego kodu, powodu podejrzenia i możliwego wpływu. Zmiany przychodzą później.

To ważne, bo AI potrafi mylić się bardzo pewnie. Kod może wyglądać na zbędny, a istnieć z powodu starej przeglądarki, payment edge case’u, ścieżki migracji albo reguły biznesowej niewidocznej w jednym pliku. Inspekcja pozwala zatrzymać błędne założenie, zanim zrobi się z niego ogromny diff.

Findings traktuję jako tropy, nie werdykty

Dobre review Codexa nie kończy się na „znalazłem 17 problemów”. Sama liczba prawie nic nie znaczy. Liczy się dowód.

Dla sensownego findingu chcę wiedzieć:

• gdzie leży problem;
• dlaczego jest problemem;
• jakie zachowanie może się zepsuć;
• jak duża pewność jest uzasadniona;
• jaki check może go potwierdzić lub odrzucić;
• jaki jest najmniejszy bezpieczny fix.

To szczególnie ważne przy security, SEO i business logic. Agent może wskazać miejsce warte sprawdzenia, ale brzmiące „security” wyjaśnienie nie jest jeszcze potwierdzoną podatnością. Ostrzeżenie SEO nie oznacza automatycznie problemu z rankingiem. Dziwny warunek nie oznacza automatycznie dead code.

AI obniża koszt znajdowania kandydatów. Weryfikacja nadal decyduje, co jest prawdziwe.

Validation loop sprawia, że workflow jest godny zaufania

Generowanie kodu jest najbardziej widoczną częścią AI-assisted development, ale walidacja czyni go użytecznym w produkcji.

Po zmianie chcę, żeby codebase odpowiedział. W zależności od projektu może to oznaczać:

• TypeScript lub inny compiler/type checker;
• lint;
• unit i integration tests;
• build check;
• celowane wyszukiwania starych nazw lub call site’ów;
• ręczny review finalnego diffu;
• ręczne sprawdzenie zachowania użytkownika.

Dokładne komendy są mniej ważne niż pętla. Agent tworzy założenie, repozytorium daje dowód, a następna decyzja opiera się na tym dowodzie.

Dlatego lubię mocno typowane projekty przy pracy z AI. Osobno opisałem dlaczego TypeScript tak dobrze współpracuje z Codexem w realnym software delivery: typy zmieniają wiele złych założeń w natychmiastowy, maszynowo czytelny feedback.

Niektóre kategorie review szczególnie dobrze pasują do AI

Bugi i regresje

Agent może śledzić wartość przez wiele plików, analizować callers, porównywać podobne implementacje i znajdować niespójne branche. To pomaga zawęzić źródło objawu. Nadal reprodukuję lub inaczej weryfikuję zachowanie przed zaakceptowaniem wniosku.

Testy

AI dobrze znajduje zachowania, które się zmieniły bez odpowiedniego test coverage, proponuje edge case’y i wyjaśnia, co faktycznie chroni istniejący test. Potrafi też wskazać testy badające szczegóły implementacji zamiast realnego zachowania.

SEO

Techniczne SEO to dużo pracy nad spójnością: metadata, language alternates, indexability, linki wewnętrzne, template’y, sitemap generation, redirects i konwencje strony. Agent może porównać te reguły w dużej codebase szybciej, niż ręcznie otworzę każdą route. Ale techniczną poprawność oddzielam od trudniejszego pytania: czy sam content zasługuje na ranking.

Lokalizacja i tłumaczenia

To jedna z najbardziej powtarzalnych części produktu wielojęzycznego. AI może porównywać keys, znajdować brakujące wartości, wykrywać zły język, sprawdzać placeholders i pokazywać, gdzie locale strukturalnie odjechał od innych. Jest to dużo szybsze niż ręczne czytanie wielkich obiektów tłumaczeń, choć ważny copy nadal wymaga ludzkiej oceny.

Spójność po refactoringu

Duże refactory psują się często w nudny sposób: zostaje stary import, jedna route korzysta ze starej nazwy pola, jeden test fixture ma starą shape. Search w całym repository połączony z agentem rozumiejącym cel zmiany działa tu bardzo dobrze.

Praca równoległa pomaga tylko przy niezależnych zadaniach

Kusi, żeby uruchomić wielu agentów i pozwolić wszystkim zmieniać wszystko równocześnie. Może to zwiększyć throughput, ale też pomnożyć konflikty i sprzeczne założenia.

Traktuję parallelism jako problem koordynacji. Niezależne audyty są dobrymi kandydatami: jeden projekt można sprawdzać pod lokalizację, inny pod testy, kilka oddzielnych repozytoriów można analizować naraz. Dwóch agentów przepisujących tę samą architekturę bez wspólnego planu to coś innego.

Im więcej pracy równoległej, tym ważniejsze granice: jasny projekt, jasne zadanie, jasne definition of done i wynik, który można osobno zreviewować.

Celem nie jest maksymalizacja liczby działających agentów. Celem jest maksymalizacja użytecznego, weryfikowalnego postępu.

Czego nie deleguję w ciemno

• Decyzje architektoniczne: model może proponować opcje, ale długoterminowe trade-offs często zależą od kontekstu spoza repo.
• Wnioski security: findings potrzebują weryfikacji, threat context i często specjalistycznych narzędzi.
• Reguły biznesowe: kod może być wewnętrznie spójny, ale implementować złe zachowanie produktu.
• Duże destrukcyjne refactory: ogromny diff trudniej zrozumieć i łatwiej bezmyślnie zaakceptować.
• Production deployment: zielone testy nie usuwają ryzyka operacyjnego.
• Final review: chcę wiedzieć, co się zmieniło, zanim podpiszę się pod zmianą.

Nie dlatego, że AI jest tam bezużyteczne, tylko dlatego, że wiarygodnie brzmiąca błędna odpowiedź może być szczególnie droga.

AI review nie zastępuje analizy statycznej

Nie traktuję Codexa jako zamiennika compilerów, linterów, testów, scannerów czy monitoringu. Te narzędzia mają przewagę, której AI nie ma: są wąskie, deterministyczne i powtarzalne.

Najsilniejszy workflow je łączy. Codex może rozumować w kontekście i sugerować gdzie patrzeć. Narzędzia statyczne egzekwują precyzyjne reguły. Testy weryfikują zachowanie. Logi i monitoring pokazują rzeczywistość. Human review łączy te sygnały z intencją produktu.

Bez takich feedback systems ufałbym AI mniej, nie więcej.

Największy wzrost produktywności to lepsza alokacja uwagi

Łatwo powiedzieć „Codex oszczędza czas”, ale dla mnie to zbyt słabo opisuje zmianę.

Rzadkim zasobem w software development nie są keystrokes. Jest nim wysokiej jakości uwaga. Przed AI coding agents mnóstwo tej uwagi szło na powtarzalne discovery: szukanie tych samych patternów, czytanie podobnych plików, śledzenie referencji, sprawdzanie czy zmiana dotarła wszędzie, a potem powtarzanie tego samego audytu w kolejnym repo.

Teraz mogę delegować więcej first-pass work i zostawiać własną uwagę na trudne do automatyzacji decyzje: czy finding ma znaczenie, czy fix pasuje do architektury, czy UX się poprawia, czy ryzyko jest akceptowalne i czy naprawdę chcę to shipować.

Dlatego utrzymywanie i review wielu projektów czuje się dziś inaczej. Nie reviewuję mniej. W wielu przypadkach mogę reviewować więcej, bo mechaniczna część nie zużywa całego budżetu.

Workflow, któremu ufam

1. Zdefiniuj wąski cel review. Bugi, testy, SEO, lokalizacja, refactor albo inne konkretne zagadnienie.
2. Najpierw inspekcja, potem edycja. Chcę dowodów i dotkniętych miejsc.
3. Priorytetyzuj findings. Nie każdy teoretyczny problem wymaga zmiany.
4. Ograniczaj zakres zmian. Małe, spójne diffy są łatwiejsze do walidacji.
5. Uruchamiaj machine checks. Typecheck, lint, testy, build, search lub walidację specyficzną dla projektu.
6. Czytaj diff ręcznie. Szukam zbędnych rewrite’ów, błędnych założeń, pominiętych edge case’ów i zmian poza scope.
7. Weryfikuj ważne zachowanie. Szczególnie users, pieniądze, security, SEO i production infrastructure.
8. Dopiero potem przechodź dalej. Parallelism jest użyteczny, ale nierozwiązana niepewność nie powinna się rozprzestrzeniać.

Piętnaście projektów nie wygląda już jak piętnaście razy więcej review

Codex nie sprawił, że 15 projektów jest proste, i nie zdjął ze mnie odpowiedzialności. Zmienił relację między skalą a ilością powtarzalnego wysiłku.

Mogę robić głębsze first passy, szersze consistency checks, więcej pomysłów na testy i bardziej systematyczne audyty bez osobistego spędzania każdej minuty na wyszukiwaniu w każdym pliku. Zaoszczędzoną uwagę mogę przeznaczyć na decyzje, które nadal potrzebują developera.

Taki AI-assisted development uważam za wartościowy: nie autopilot, nie ślepe zaufanie i nie „generuj kod, aż coś przejdzie”. To ciaśniejszy loop między inspekcją w skali maszyny a ludzkim osądem.

Dla mnie to jest prawdziwy leverage Codexa. Nie eliminuje review. Umożliwia poważne review na skali, którą wcześniej znacznie trudniej było utrzymać.