Martwy punkt managera: Gdy wyższa prędkość ukrywa wyższy koszt

Martwy punkt managera: Gdy wyższa prędkość ukrywa wyższy koszt

8 min czytania

Martwy punkt managera

Twój dashboard wygląda świetnie.

Commity na tydzień: w górę o 23%. Cycle time PR-ów: w dół. Story pointy zamknięte: najwyżej od trzech kwartałów. Zespół wdrożył narzędzia AI do kodowania cztery miesiące temu, i wykres velocity potwierdza to, na co wszyscy liczyli. Szybciej. Więcej. Lepiej.

Tyle że mierzysz nie to, co trzeba. Liczby, które poszły w górę, to te, które AI z definicji napompowuje. Liczby, które poszły w bok — albo gorzej — nie są na twoim dashboardzie.

Co widać na dashboardzie

Narzędzia AI do kodowania są zoptymalizowane pod jedną rzecz: skrócenie czasu między zamiarem a kodem. Developer myśli “potrzebuję retry handlera z exponential backoff” i ma działający kod w 30 sekund zamiast 15 minut.

Ta prędkość pojawia się wszędzie, gdzie managerowie patrzą. Więcej commitów. Więcej PR-ów. Więcej zmienionych linii. Metryki velocity, które napędzają sprint review i planowanie kwartalne, świecą na zielono.

Rozsądny manager widzi te liczby i konkluduje: narzędzie działa. Shipujmy więcej. Ruszajmy szybciej. Przypadek ROI pisze się sam.

Problem polega na czymś innym. Każda metryka, która się poprawiła, mierzy produkcję. Żadna nie mierzy, ile ta produkcja kosztuje ludzi, którzy ją wykonują.

Czego nie widać na dashboardzie

Gęstość bugów. Uplevel Data Labs przeanalizował 800 developerów przez sześć miesięcy — trzy miesiące przed dostępem do GitHub Copilota, trzy miesiące po. Throughput PR-ów pozostał bez zmian. Cycle time się nie poprawił. Ale liczba błędów wzrosła o 41%. To nie drobny sygnał w szumie. 41% wzrost na próbie 800 osób.

Bugi nie były losowe. Kod generowany przez AI wprowadza tryby awarii inne od kodu pisanego przez człowieka. Zhallucynowane wywołania API. Logika wyglądająca wiarygodnie z edge case’ami, których model nie rozważył. Kod, który przechodzi testy napisane przez developera, ale nie przechodzi testów, których nikt nie pomyślał napisać. Każdy bug wygląda poprawnie na pierwszy rzut oka. Znalezienie go wymaga drugiego, wolniejszego spojrzenia.

Churn kodu. GitClear przeanalizował 211 milionów zmienionych linii w repozytoriach Google, Microsoftu, Mety i firm enterprise od 2020 do 2024 roku. W 2020 roku 5,5% nowo dodanego kodu było poprawiane w ciągu dwóch tygodni. Do 2024 ta liczba osiągnęła 7,9%. Duplikacja kodu wzrosła z 8,3% do 12,3% zmienionych linii — mniej więcej 4-krotnie. Refaktoring — linie przeniesione zamiast dodane czy usunięte — spadł z 24,1% do 9,5%.

Więcej kodu. Mniej refaktoringu. Więcej duplikacji. Więcej churnu. Wykres velocity idzie w górę. Zdrowie codebase’u idzie w dół. Ale zdrowie codebase’u nie pojawia się na sprint review.

Koszt koordynacji. Siddhant Khare, inżynier infrastruktury AI, opisał tę zmianę precyzyjnie: “AI redukuje koszt produkcji, ale zwiększa koszt koordynacji, review i podejmowania decyzji. I te koszty spadają w całości na człowieka.”

Przed AI jeden developer spędzał cały dzień nad problemem projektowym w głębokim skupieniu. Po AI ten sam developer ogarnia sześć problemów dziennie przez szybkie przełączanie kontekstów. Output na dzień: wyższy. Obciążenie poznawcze na dzień: dramatycznie wyższe. Wąskie gardło przesunęło się z produkcji na ewaluację. A ewaluacja nie generuje commitów.

Manager patrzący na dashboard widzi sześć rozwiązanych problemów. Nie widzi zmęczenia decyzyjnego narastającego za outputem. Nie widzi developera, który wrócił do domu o 18:00 pusty — nie od pisania kodu, ale od przeglądania go.

Obciążenie review. Kod generowany przez AI wymaga dokładniejszego review niż kod pisany przez człowieka. Kod kolegi podąża za wzorcami, które rozpoznajesz. Znasz jego nawyki, konwencje, typowe błędy. Kod generowany przez AI nie podąża za żadnym spójnym wzorcem. Każde review wymaga pełnej uwagi, bo nie wiesz, gdzie będą problemy.

Osoba, która przeglądała trzy PR-y dziennie, teraz przegląda siedem. Każdy trwa dłużej na linię. Łączne godziny review poszły w górę. Ale “godziny review” nie są na dashboardzie. “PR-y zmergowane” — są.

Problem “Smażenia Mózgu”

Badacze BCG przebadali prawie 1500 amerykańskich pracowników na początku 2026. Ukuli termin: “AI brain fry.” Zmęczenie psychiczne z nadmiernego użycia lub nadzoru nad narzędziami AI, przekraczające pojemność poznawczą.

Liczby są konkretne. Pracownicy z wysokim stopniem nadzoru nad AI — starsi developerzy przeglądający output AI — raportowali 14% większy wysiłek umysłowy, 12% większe zmęczenie psychiczne i 19% większe przeciążenie informacyjne w porównaniu z tymi, którzy mieli niski poziom nadzoru.

Objawy: mgła mentalna, trudności z koncentracją, dłuższe czasy podejmowania decyzji, bóle głowy. 18% inżynierów oprogramowania i developerów zgłosiło doświadczanie “smażenia mózgu przez AI.”

Badacze BCG rozdzielili użycie AI na kategorie. Automatyzacja — stosowanie AI do rutynowych zadań — nie powodowała “brain fry.” Nadzór — bezpośredni monitoring i ewaluacja agentów AI — tak. Typ użycia AI, który managerowie nagradzają najbardziej (szybsze shipowanie), produkuje typ obciążenia poznawczego, który wypala ludzi.

A wypalenie nie pojawia się na dashboardzie velocity, dopóki nie jest za późno. Pojawia się jako list z wypowiedzeniem za trzy miesiące.

Niewidzialne równanie kosztów

Oto kalkulacja, której nikt nie robi.

Widoczne zyski: 10 godzin zaoszczędzonych na generowaniu kodu na developera na tydzień. Realne. Mierzalne. Celebrowane na all-hands.

Niewidoczne koszty:

  • 6 dodatkowych godzin code review na developera tygodniowo (kod AI wymaga dokładniejszego czytania)
  • 3 dodatkowe godziny debugowania trybów awarii specyficznych dla AI (zhallucynowane API, ślepota na edge case’y)
  • 2 dodatkowe godziny koordynacji (więcej outputu = więcej integracji = więcej merge conflictów)
  • Niekwantyfikowalne: zmęczenie decyzyjne, atrofia myślenia, rosnąca zależność

Netto zmiana produktywności: gdzieś między marginalną a negatywną. Ale widoczne zyski są głośne, a niewidoczne koszty są ciche. Managerowie celebrują zyski. Nikt nie mierzy kosztów.

Badanie Uplevel potwierdziło to na skali. Po kontroli wszystkich zmiennych dostęp do Copilota nie przyniósł istotnej poprawy w throughputcie PR-ów, cycle time ani doświadczeniu developera. Zero. Jedyna metryka, która istotnie się zmieniła, to liczba bugów. Poszła w górę.

Czego managerowie nie widzą

Martwy punkt to nie głupota. To problem strukturalny. Managerowie widzą to, co są wyposażeni zobaczyć.

Velocity sprintu: widoczne. Story pointy: widoczne. Częstotliwość commitów: widoczna. Wskaźnik merge’owania PR-ów: widoczny.

Obciążenie poznawcze developera: niewidoczne. Degradacja jakości review: niewidoczna. Formowanie zależności: niewidoczne. Ukrywanie użycia AI: niewidoczne. Nocne sesje napędzane pętlami “prawie działa”: niewidoczne.

Developerzy nie raportują tych kosztów, bo ukrywają, ile korzystają z AI. Dashboard ich nie wyłapuje, bo dashboardy mierzą output, nie ludzki koszt jego produkcji. A vendor sprzedający narzędzie AI nie ma motywacji mierzyć kosztów, które jego produkt generuje.

Więc manager optymalizuje pod to, co widzi. Więcej velocity. Więcej adopcji AI. Wyższe normy, bo “każdy ma copilota.” Pętla zwrotna się zacieśnia: AI poprawia dashboard, dashboard napędza decyzje, decyzje wymuszają więcej AI, więcej AI napompowuje dashboard.

Nikt nie pyta developera, który dostarczył sześć feature’ów w tym sprincie, jak się czuje. Jak spał. Czy potrafiłby rozwiązać choćby jeden z tych problemów bez narzędzia.

Co śledzić zamiast tego

Nie musisz porzucać narzędzi AI. Musisz mierzyć to, co ma znaczenie.

Stosunek bugów do commitów w czasie. Więcej commitów nie powinno oznaczać więcej bugów. Jeśli liczba błędów wzrosła po adopcji AI, masz problem z jakością, który metryki velocity ukrywają.

Wskaźnik churnu kodu. Jaki procent kodu z tego tygodnia zostanie przepisany w ciągu dwóch tygodni? Jeśli liczba rośnie, produkujesz jednorazowy output. Szybki jednorazowy output to wciąż jednorazowy output.

Godziny review na PR. Śledź to przed i po adopcji AI. Jeśli godziny review na PR poszły w górę, twój “zysk produktywności” to częściowo transfer kosztów z piszącego na przeglądającego.

Samoocena obciążenia poznawczego developerów. Pytaj wprost, co tydzień. “W skali 1-10, jak bardzo wyczerpany psychicznie byłeś na koniec tego tygodnia?” Porównaj z tym samym pytaniem sprzed sześciu miesięcy. Jeśli obciążenie wzrosło, gdy output wzrósł, spalasz paliwo szybciej — nie robisz silnika wydajniejszym.

Wzorce nocnych commitów. Czy developerzy commitują kod po 22:00 częściej niż przed adopcją AI? Refaktor o 3 w nocy to nie historia o produktywności. To historia o kompulsji.

Test zależności. Zapytaj zespół: “Gdyby narzędzie AI było niedostępne przez cały tydzień, o ile spadłby wasz output?” Jeśli odpowiedź to “50% lub więcej,” masz zależność operacyjną. To ryzyko, nie feature.

Niewygodne pytanie

Managerowie pytający “jak wycisnąć więcej z narzędzi AI?” zadają złe pytanie.

Właściwe pytanie: “Jaki jest pełny koszt outputu, który produkują nasze narzędzia AI — włącznie z kosztami, których nie widać na dashboardzie?”

AI redukuje koszt produkcji. Zwiększa koszt koordynacji, koszt review, koszt zapewnienia jakości i obciążenie poznawcze. Te koszty spadają w całości na człowieka. A człowiek nie pojawia się na wykresie velocity.

Dopóki nie odejdzie.

Quiz OnTilt mierzy sześć wymiarów wzorców pracy z AI. Dwa z nich — Negatywne Konsekwencje i Utrata Kontroli — mapują się na to, co opisuje ten artykuł. Twoi developerzy mogą wypełnić go anonimowo. 14 pytań. 3 minuty. Żadne dane identyfikujące nie są zbierane.

Jeśli jesteś managerem, rozważ udostępnienie go zespołowi. Nie jako nakaz. Jako lustro.

Źródła:

  • Uplevel Data Labs. (2024). “Gen AI for Coding Research Report.” 800 developerów, GitHub Copilot, 6-miesięczna analiza. 41% wzrost błędów, brak istotnego wzrostu produktywności. resources.uplevelteam.com
  • GitClear. (2025). “AI Copilot Code Quality Research.” 211 milionów zmienionych linii, 2020–2024. Churn w górę (5,5% → 7,9%), duplikacja 4x (8,3% → 12,3%), refaktoring w dół (24,1% → 9,5%). gitclear.com
  • Kellerman, G.R. & Kropp, M. (2026). Badanie “AI Brain Fry.” BCG / Harvard Business Review. ~1500 pracowników w USA. 14% większy wysiłek umysłowy, 12% większe zmęczenie, 19% więcej przeciążenia informacyjnego wśród pracowników z wysokim nadzorem AI. Fortune
  • Khare, S. (2026, 8 lutego). “AI Fatigue Is Real and Nobody Talks About It.” siddhantkhare.com. Cytat: “AI redukuje koszt produkcji, ale zwiększa koszt koordynacji.”

OnTilt to projekt badawczy analizujący wzorce behawioralne w pracy z AI. Quiz to narzędzie autorefleksji, nie instrument diagnostyczny. Więcej na stronie O projekcie.