Twój agent AI do kodowania pracował całą noc. Otwierasz dashboard w poniedziałek rano, a tam świeci się jak choinka: 14 pull requestów, 2000 zmienionych linii, trzy nowe feature'y postawione. Pijesz kawę z poczuciem, że zatrudniłeś juniora za darmo.
A potem faktycznie czytasz ten kod. Połowa tych PR-ów zawiera fixy na bugi, które agent sam wprowadził dwa commity wcześniej w tej samej sesji. Jedna funkcja została napisana, zepsuta, przepisana, zepsuta ponownie i wreszcie wylądowała przy piątym podejściu. Dashboard policzył każdą próbę jako produktywną pracę.
Witaj w rework ratio — metryce, o której nikt sprzedający ci narzędzia AI do kodowania nie chce rozmawiać.
Wnętrze sesji agenta
Przez ostatni miesiąc każde większe narzędzie do kodowania wypuściło autonomiczne agenty. GitHub Copilot i Cursor 3 uruchomiły swoje na początku kwietnia; Claude Code Routines pojawiło się 14 kwietnia; OpenAI Codex rozszerzył się o multi-agentowe workflow 16 kwietnia. Każde z tych narzędzi uruchamia pętle iteracji bez nadzoru — agent pisze kod, sprawdza czy działa i próbuje ponownie, jeśli nie.
I to właśnie to "próbuje ponownie" sprawia, że cała księgowość się sypie. Oto skrócona, ale reprezentatywna sesja agenta, który miał dodać endpoint uwierzytelniania użytkowników. Czterdzieści trzy minuty. Dwanaście commitów:
| # | Wiadomość commita | Typ |
|---|---|---|
| 1 | Add auth route handler | Nowa praca |
| 2 | Add JWT token generation | Nowa praca |
| 3 | Fix import error in auth.py | Przeróbka |
| 4 | Add password hashing | Nowa praca |
| 5 | Fix type error in hash function | Przeróbka |
| 6 | Rewrite auth route to fix 500 error | Przeróbka |
| 7 | Add input validation | Nowa praca |
| 8 | Fix validation regex causing test failure | Przeróbka |
| 9 | Fix test broken by commit 6 | Przeróbka |
| 10 | Add rate limiting middleware | Nowa praca |
| 11 | Fix rate limiter config path | Przeróbka |
| 12 | Clean up unused imports from iterations | Przeróbka |
Pięć commitów posuwa feature do przodu. Siedem naprawia problemy, które agent sam stworzył w tej samej sesji. To 58% rework ratio — ponad połowa wysiłku agenta idzie na sprzątanie po sobie.
Dashboard zaraportował 12 commitów, 847 zmienionych linii, jeden feature ukończony. Wszystko technicznie prawda. Wszystko mylące.
Jak obliczyć rework ratio
To nie teoria. Możesz to wyciągnąć z dowolnego repo, w którym pracują agenty:
Rework Ratio = (commity modyfikujące kod napisany wcześniej w tej samej sesji agenta) ÷ (łączna liczba commitów w sesji)
Odpal git log --diff-filter=M na branchu wygenerowanym przez agenta. Oflaguj każdy commit, który zmienia plik, którego agent już dotykał w tej samej sesji. Oddziel prawdziwe rozszerzenia (dodanie nowej funkcji do istniejącego pliku) od poprawek (naprawienie tego, co właśnie się zepsuło). Ratio siedzi tam w historii diffów.
Raport jakości kodu GitClear z kwietnia 2026 zmierzył powiązany sygnał — code churn w ciągu 72 godzin od napisania — i wyszło 7,1% dla projektów z AI kontra 3,2% dla projektów czysto ludzkich. Ale to łapie churn po merge'u — kod, który trafia na produkcję i potem jest przepisywany. Churn wewnątrz sesji, gdzie agent psuje i naprawia własny kod zanim ty w ogóle zobaczysz pull request, pozostaje niewidoczny dla każdego istniejącego narzędzia pomiarowego.
To jest ta luka. GitClear mierzy churn po merge'u. Dashboardy vendorów mierzą aktywność. Nikt nie mierzy przeróbek dziejących się wewnątrz pętli agenta.
Kłamstwo dashboardu
Prześledźmy matematykę dla prawdziwego zespołu. Załóżmy, że agenty odpalają 50 sesji tygodniowo u 10 inżynierów, średnio 12 commitów na sesję. Jeśli typowe rework ratio wynosi 55%:
- 50 sesji × 12 commitów = 600 commitów/tydzień (to, co pokazuje dashboard)
- 600 × 0,55 = 330 commitów, które nie wyprodukowały niczego, co trafiło do shipu
- 330 przeróbkowych commitów × ~$0,15 średniego kosztu tokenów = ~$50/tydzień spalone na AI-owy odpowiednik wciskania Backspace'a
Przeskaluj to. Organizacja ze 100 inżynierami agresywnie używająca agentów przepala $2 000–$5 000 miesięcznie na tokeny, które generują zero netto kodu. Dashboard nazywa to "AI-assisted development". P&L nazywa to marnotrawstwem.
Jak potwierdziło wiele analiz w tym roku — kod generowany przez AI niesie ze sobą mniej więcej 1,7× więcej problemów na PR niż kod ludzki, incydenty rosną proporcjonalnie do outputu AI, a niezawodność agentów rośnie o połowę wolniej niż ich możliwości. Rework ratio wyjaśnia część mechanizmu: kod, który przetrwał pięć wewnętrznych przepisywań, nosi architektoniczne blizny po pierwszych czterech próbach. Funkcje są kształtowane przez historię debugowania, nie przez zamysł projektowy.
Co zostaje po przeróbkach
Odejmij pętle autokorekty i realne zyski produktywności lądują na poziomie 1,5–2× dla większości zespołów. Benchmarki produktywności Larridin z Q1 2026 wykazały, że wykorzystanie AI w zespołach inżynieryjnych skoczyło o 65%, a throughput PR-ów urósł o jakieś 10%. Luka między adopcją a outputem jest częściowo wyjaśniona właśnie przez przeróbki zjadające różnicę.
Ukryty koszt to nie tylko tokeny. Każdy cykl korekcji dodaje defensywną złożoność do finalnego kodu. Nazwy zmiennych odzwierciedlają historię debugowania, a nie koncepcje domenowe. Abstrakcje gromadzą guard clause'y z poprzednich nieudanych prób. Kod działa, ale czyta się go jak pisany przez kogoś, kto ciągle zmieniał zdanie — bo tak właśnie było.
Metryka, która zmieniłaby procurement
Zadaj swojemu vendorowi narzędzi AI do kodowania jedno pytanie przed następnym sprint planningiem: jaki procent akcji agenta w sesji to korekta własnego wcześniejszego outputu?
Sprawdziłem każdy dashboard, każdą stronę analityki, każdy raport engineering intelligence od głównych narzędzi shipujących agenty w tym miesiącu. Żadne nie oddziela "nowej użytecznej pracy" od "agenta kłócącego się ze sobą".
Pierwszy vendor, który pokaże tę metrykę — uczciwie dzieląc nową pracę od autokorekty — wygrywa deale enterprise'owe. Nie dlatego, że liczba będzie pochlebna (nie będzie), ale dlatego, że zademonstruje coś, czego żaden vendor jeszcze nie zaoferował: uczciwość w kwestii tego, co autonomiczne kodowanie faktycznie produkuje.
Nie musisz czekać. Sklonuj dowolny branch wygenerowany przez agenta. Przeczytaj commity po kolei. Policz te, które naprawiają to, co agent właśnie zepsuł.
Twój dashboard mówi 10×. Twój git log mówi co innego. Wierz git logowi.
