Twoje systemy już mają ślepe punkty. AI tylko je pogarsza.

W 2022 roku, zanim generatywne narzędzia kodujące stały się częścią naszej codziennej pracy inżynieryjnej, napisałem o mojej filozofii wyboru narzędzi. Okazało się to lepsze niż się spodziewałem. Wtedy argumentowałem, aby zaczynać od problemów, które naprawdę rozwiązujesz, znając swoje słabości, i priorytetyzować sposób, w jaki używasz narzędzi, zamiast po prostu rzucać się na każde narzędzie, które brzmi najlepiej, i liczyć na to, że zadziała. Poznaj siebie i swoje cele, aby móc ustalić właściwe oczekiwania wobec swoich narzędzi.

Wtedy myślałem o rozrostu SaaS, a nie o kodzie generowanym przez AI. Ale dziś moja filozofia jest jeszcze bardziej pilna i ważniejsza do obrony.

Wielu z nas przeczytało raport DORA 2025, które wykazało, że w przeciwieństwie do roku poprzedniego, przyjęcie AI teraz koreluje pozytywnie z wydajnością dostaw. Podstawowym wnioskiem było to, że niestabilność dostaw rosła, i sprawdzono, czy przyrosty prędkości to rekompensują. Nie rekompensują. To odpowiada naszym doświadczeniom. Nasz zespół przyjął agentyczny rozwój oprogramowania i odnotował 48 % wzrost wydajności w ciągu dwóch kwartałów, po czym nastąpił 16 % wzrost problemów ze stabilnością. Dziesięć osób to mała próbka, ale jest to również próbka, z której mogę zobaczyć pełny obraz, i wzorzec się utrzymał.

Przyjęcie AI już nie jest naprawdę pytaniem. Albo dopiero zaczynasz, albo jesteś już w środku. To, co się teraz różni, to fakt, że od liderów inżynierii oczekuje się przyjmowania AI i jednocześnie udowadniania, że przynosi korzyści. CEO, zarząd i dział finansów chcą wiedzieć, jak zoptymalizować ich inwestycję w AI. Pytają, czy wybrane przez Ciebie narzędzia rozwiązują rzeczywiste problemy efektywnie.

Luka zawsze była. AI tylko ją poszerzyło.

Jako CTO spędzam znaczną część czasu rozmawiając z innymi liderami inżynierii, w tym z klientami, potencjalnymi klientami i moimi rówieśnikami, aby porównywać osiągnięcia i frustracje związane z tym, co doświadczamy w kontekście AI. Po wystarczającej liczbie takich rozmów zacząłem dostrzegać wzorce w przyjmowaniu AI i ich rezultatach.

Główna obserwacja nie jest moja. DORA podkreśla to od dwóch lat: AI wzmacnia to, co już dzieje się w organizacji, zarówno mocne, jak i słabe strony. Zespół z czystą architekturą i zdrowymi nawykami przeglądu działa szybciej. Zespół, który opanował kłopotliwy bałagan długu technicznego wystarczająco, by wypuścić kod, teraz odkrywa, że dług techniczny rośnie i staje się poważną przeszkodą. To, co to ujęcie pomija, to dlaczego tak wiele zespołów jest zaskoczonych. AI nie ukryło tych słabości; systemy, na które polegaliśmy, nigdy ich nie ujawniły.

Stos zgłoszeń i raportowania, na którym opiera się większość organizacji inżynieryjnych, został zbudowany, aby odpowiadać na pytania, które mają ludzie, w ludzkim tempie, przez osoby, które w przybliżeniu rozumiały, co oznacza „zrobione” dla danego zadania. Nigdy nie był to idealny zapis. Zawsze był przybliżeniem, wypełnianym przez kogoś podsumowującego coś bardziej skomplikowanego w tle. Teraz AI zwiększa wolumen i wprowadza nowe dane wejściowe, które generują nową aktywność. Żaden z systemów (ani narzędzi) używanych do tradycyjnych, nie‑AI metod rozwoju nie został nigdy do tego zaprojektowany.

Niezależnie od tego, nadal jesteśmy odpowiedzialni za te same cele. Nadal kontrolujesz tempo, jakość, wydatki i to, jak naprawdę radzi sobie Twój zespół. Nie możesz już po prostu przyjmować zeszłorocznych pulpitów na wiarę.

Istnieje uzasadniona uwaga w tej sprawie. raport ROI DORA 2026 opisuje krzywą J: spadek produktywności zaraz po przyjęciu, spowodowany krzywą uczenia się, kosztami weryfikacji kodu generowanego przez AI oraz procesami zależnymi, które nie nadążyły. Nazywają to „kosztem edukacji” transformacji i ostrzegają liderów, aby nie mylili tego z porażką. To uczciwe. Jednak koszt edukacji i rzeczywisty problem wyglądają identycznie na pulpicie zbudowanym na podstawie zgłoszeń. Jeśli nie możesz określić, w którym jesteś, nie jesteś cierpliwy. Zgadujesz.

Musimy wrócić do podstaw. Poznaj siebie. Poznaj swój zespół. Poznaj problemy, które rozwiązujesz.

Jak z AI „poznać siebie”?

Z moich rozmów zidentyfikowałem pięć głównych obszarów, w których tradycyjne systemy, zbudowane dla pracy generowanej i raportowanej przez ludzi, są ślepe. Ignorowanie ich zwiększa ryzyko wzmocnienia Twoich słabości w miarę dalszego przyjmowania AI.

Ślepy punkt 1: Teatr tempa

Więcej commitów i PR‑ów może wydawać się postępem i często tak jest. AI podnosi oba liczniki automatycznie. studium przypadku Stanford pokazało, że przyjęcie AI zwiększyło liczbę PR‑ów o 14 %. Jednak to, co pomijasz, to ile z tej aktywności to praca nad funkcjami, które są wydawane, w porównaniu do utrzymania, poprawek lub rotacji wynikającej z refaktoryzacji, która się nie utrzymała.

Aby to rozwiązać, obserwuj podział między pracą nad funkcjami a utrzymaniem oraz monitoruj częstotliwość wdrożeń i czas realizacji w odniesieniu do własnej historycznej bazy, a nie średniej branżowej. Bez tego podziału raportujesz postęp, którego nie możesz faktycznie udokumentować.

Ślepy punkt 2: Dług przeglądowy

Pojemność przeglądu nie zwiększa się automatycznie wraz z wydajnością. Podatek weryfikacji nie jest jedynie fazą, którą przechodzi się; jest częścią stałych kosztów rozwoju agentowego. Jedno niedawne badanie liderów inżynierii stwierdziło, że 80 % zespołów poświęca co najmniej 10 % swojego czasu na przegląd, a około jeden na dziesięciu spędza ponad 40 %. Przy takim obciążeniu zespoły oscylują między rosnącym backlogiem a bezrefleksyjnym zatwierdzaniem, i żadne z nich nie jest prawdziwym rozwiązaniem.

Ograniczenie przy wydaniu nie polega już na tym, jak szybko kod jest pisany. To jest jak szybko człowiek może naprawdę być pewny, że zmiana jest poprawna, jak szybko i dokładnie można wykrywać i usuwać defekty. Obserwuj, jak obciążenie przeglądem jest faktycznie rozdzielane w twoim zespole; w przeciwnym razie ryzykujesz przeciążenie starszych inżynierów, opóźnianie wydań lub powodowanie poważnych problemów produkcyjnych.

Martwe oko 3: Ukryta praca

Refaktoryzacje i zmiany architektury mają tendencję do ukrywania się w innych zgłoszeniach, jeśli w ogóle pojawiają się w systemie zgłoszeń. AI generuje więcej takiej pracy, a nie mniej. Agent nie waha się dotknąć dwunastu plików, aby naprawić jeden błąd, podczas gdy człowiek może się zatrzymać i przemyśleć. Praca, która omija system rejestracji, pomija także planowanie, co oznacza, że Twój model pojemności jest błędny, a każda prognoza oparta na nim jest również błędna. 

Aby zrozumieć, ile pracy faktycznie jest wykonywane, musisz obserwować, ile naprawdę zmienia się w bazie kodu i w historii pull requestów. Bez tego twój plan pojemności opiera się na tym, co ludzie pamiętali, aby zalogować, a nie na tym, co naprawdę zrobili. 

Martwe oko 4: Dryf jakości

To samo badanie wykazało, że prawie połowa liderów inżynierii ma trudności z wykrywaniem problemów bezpieczeństwa tydzień po tygodniu. Złożoność, duplikacja i zależności, które nie do końca pasują, gromadzą się w wielu małych, indywidualnie uzasadnionych zmianach. Żadne z nich nie wyglądają alarmująco same w sobie. W tym samym studium przypadku Stanford, jakość kodu spadła o 9 % i jej zmienność ponad trzykrotnie się zwiększyła. Średnia zmieniła się nieco, ale rozrzut (to, co zauważasz) zmienił się znacznie. Przy wolumenie AI, problemy kumulują się szybciej niż większość procesów przeglądu je łapie. Dryf zazwyczaj ujawnia się jako alert na dyżurze, powiązany z zależnością, której nikt nie pamięta przeglądać. Zanim to nastąpi, istnieje spore prawdopodobieństwo, że najpierw zauważy to klient.

Obserwuj linie trendu dotyczące wykryć bezpieczeństwa, zależności oraz awarii i odzyskiwania – nie pojedynczego commitu. Złożoność i duplikacja narastające przez kilka tygodni mają większe znaczenie niż pojedyncza zmiana, która zostaje oznaczona w przeglądzie. Bez tego wykrywasz dryf tak, jak robią to większość zespołów: po tym, jak już spowodował incydent. 

Martwe oko 5: Nieudowodnione wydatki

Gdy adopcja AI przestaje być przedmiotem debaty, wydatki na AI i ROI stają się pytaniem, na którym skupia się wszyscy. Finansowanie chce wiedzieć, co jest kapitalizowalne, a co operacyjne. Kierownictwo chce wiedzieć, w co zainwestowano. Większość zespołów nadal podejmuje decyzje dotyczące narzędzi, licencji i zatrudnienia na podstawie intuicji, a nie dowodów na związek między pieniędzmi a dostarczoną pracą.

Obserwuj, gdzie rzeczywiście przepływa wysiłek inżynieryjny w samej bazie kodu, kwartał po kwartale — a nie tam, gdzie roadmapa mówi, że powinien płynąć. Bez tego powiązania bronisz budżetu na kolejny rok anegdotami, a anegdoty nie przetrwają trudnej rozmowy z CFO.

Zacznij od tego, czego nie możesz zobaczyć

Pytanie finansów o wydatki kapitalizowane i strona dyżurnego o 2 nad ranem wydają się niepowiązane, ale tak nie jest. Oba można „oszacować w przybliżeniu” na podstawie aktywności. Jednak oba są faktycznie możliwe do odpowiedzenia, z dowodami, z samego kodu.

Odpowiedzią DORA na to wszystko jest sam system inżynieryjny: jakość platformy, przejrzystość przepływu pracy, spójność zespołu. To prawda, ale to także nie jest pierwszy krok. Nie możesz naprawić systemu, którego nie widzisz. Każdy z tych pięciu obszarów to coś, co musisz być w stanie zaobserwować, zanim będziesz mógł argumentować za inwestowaniem w niego.

Pierwszym użytecznym krokiem nie jest nowe narzędzie ani nowy proces. To poznanie samego siebie, szczerze, i określenie, które z tych pięciu obszarów są martwymi punktami, w których brakuje rzeczywistych dowodów. Większość liderów może od razu zidentyfikować (i zwraca uwagę na) problemy w jednym z tych obszarów. Jednak to obszary, w których masz najmniej informacji, najprawdopodobniej pojawią się i ugryzą cię, gdy będziesz dalej wdrażał AI.