Dlaczego AI w zwinnej dostawie oprogramowania (Agile Software Delivery) zawodzi: Przykłady i rozwiązania dla Engineering Managerów

Wielu CTO wiąże duże nadzieje z wykorzystaniem AI w zwinnym dostarczaniu oprogramowania: większa szybkość, większa automatyzacja, większa wydajność. Często jest to prawdą w krótkim okresie. Mimo to wielu zespołom i CTO nie udaje się wykazać, jak to lokalne przyspieszenie przekłada się na korzyści dla klienta i wartość biznesową.

Problem polega na tym, że w entuzjazmie dla AI firmy optymalizują niewłaściwe rzeczy: więcej tokenów zamiast większej korzyści dla klienta, więcej kodu zamiast większego zaufania, więcej agentów zamiast lepszych systemów dostarczania.

Ten artykuł świadomie nawiązuje do naszych dwóch pozostałych wpisów:

• AI w zwinnej produkcji oprogramowania: Stan badań 2026 .
• Przewodnik dla CTO i Engineering Managerów po tworzeniu oprogramowania wspieranym przez AI .

Tu chodzi o pomost pomiędzy tymi kwestiami: Dlaczego AI w zwinnym dostarczaniu oprogramowania zawodzi w praktyce? Przykłady konkretnie pokażą, co mogą zrobić menedżerowie i jakie rozwiązania są naprawdę skuteczne.

Dlaczego AI w Agile Software Delivery tak często optymalizuje pod kątem niewłaściwego celu

Gdy tylko AI zostaje wprowadzona jako dźwignia produktywności, w wielu firmach dzieje się coś bardzo przewidywalnego: to, co mierzalne, staje się celem. Odzwierciedla to nowy trend zwany Tokenmaxxing. Pragmatic Engineer o trendzie Tokenmaxxing

Oznacza to, że firmy lub zespoły traktują wysokie zużycie tokenów pośrednio lub bezpośrednio jako oznakę dobrego wykorzystania AI. Jest to niebezpieczne zarówno z punktu widzenia ekonomicznego, jak i organizacyjnego. Tokeny są bowiem co najwyżej miarą nakładów (input), a nie miarą wartości.

Ten wzorzec jest stary. Kiedyś przeceniano „linie kodu” jako metrykę, dziś właśnie zużycie tokenów lub pulpity nawigacyjne dotyczące korzystania z AI. W obu przypadkach obowiązuje wariant prawa Goodharta: gdy tylko metryka staje się celem, traci swoją wartość jako metryka. Martin Fowler o liniach kodu jako problemie z metrykami, Wikipedia o prawie Goodharta

Dla AI w zwinnym dostarczaniu oprogramowania oznacza to: kto maksymalizuje krótkoterminową aktywność, często otrzymuje więcej aktywności AI. Ale nie automatycznie lepsze zwinne dostarczanie oprogramowania.

Stan badań w tym zakresie jest otrzeźwiający: na poziomie indywidualnym widać już wyraźne efekty produktywności, natomiast na poziomie zespołu i organizacji widać znacznie mniej wiarygodnych ulepszeń. Szczegóły podsumowaliśmy tutaj: O stanie badań w 2026 r. nad AI w zwinnym wytwarzaniu oprogramowania

Cztery typowe przykłady tego, jak AI zawodzi w zwinnym dostarczaniu oprogramowania

Pierwsza porażka jest banalna: zespoły produkują znacznie więcej zmian, ale rozumieją coraz mniejszą ich część.

Dla menedżerów na początku wygląda to często dobrze:

• więcej Pull Requestów
• szybsze pierwsze implementacje
• więcej story “gotowych”

Rachunek przychodzi później:

• Review stają się bardziej powierzchowne
• Ownership (poczucie własności) rozmywa się
• Analiza incydentów trwa dłużej
• Unika się refaktoryzacji, ponieważ nikt nie jest już pewien, co i gdzie mogłoby się zepsuć

Kent Beck opisuje w swoim artykule „Trust Factory”, że praktyki takie jak testy, przeglądy, refaktoryzacja i inkrementalne dostarczanie służą przede wszystkim budowaniu zaufania. Właśnie to zaufanie znika, gdy AI produkuje szybciej, niż zespół jest w stanie zrozumieć, sprawdzić i wziąć za to odpowiedzialność. Kent Beck w Trust Factory o zaufaniu w inżynierii

Addy Osmani opisuje podobne ryzyko jako „Comprehension Debt” (dług zrozumienia): gdy zespoły dostarczają coraz więcej kodu, którego już aktywnie nie przenikają, z każdą zmianą rośnie dystans między systemem a zrozumieniem. Addy Osmani o długu zrozumienia

Pasuje to również do szerszych wniosków z praktyki: według badania Sonar podsumowanego w 2026 r., większość programistów nie ufa w pełni poprawności funkcjonalnej kodu generowanego przez AI, a znaczna część uważa jego przegląd za nawet bardziej czasochłonny niż sprawdzanie zmian napisanych przez człowieka. Problemem nie jest więc tylko słaba jakość, ale dodatkowy nakład pracy na weryfikację i zrozumienie. ITPro o badaniu Sonar dotyczącym długu weryfikacyjnego

Drugie niepowodzenie jest dla liderów jeszcze droższe: AI obniża koszty wytwarzania, ale nie automatycznie koszty pomyłki.

Jeśli zespoły słabo kroją wymagania, niewystarczająco je walidują albo uzgadniają je tylko wewnętrznie, to AI po prostu przyspiesza niewłaściwą pracę. Kelsey Hightower ujmuje to bardzo wprost w swoim poście na LinkedIn: “Productivity doesn’t matter if you’re working on the wrong thing.” Post Kelseya Hightowera na LinkedIn o fałszywej produktywności

Właśnie w tym kierunku argumentuje też Andrew Ng w często cytowanej rozmowie z 2025 roku: AI mocno przyspieszyła coding, ale przez to przesunęło się rzeczywiste wąskie gardło. Głównym problemem nie jest już implementacja, lecz pytanie produktowe:

Co właściwie powinniśmy budować i jak szybko uczymy się na podstawie prawdziwych opinii użytkowników?

Źródło: Rozmowa Business Insider z Andrew Ng o wąskim gardle Product Management

To właśnie dlatego AI w agiler dostarczaniu oprogramowania może odnieść sukces tylko przy prawdziwej bliskości z klientem. Jeśli droga od promptu do kodu staje się szybsza, ale droga od kodu do feedbacku od klienta pozostaje wolna, rosną jedynie output i zakres zmian.

Również badania nad zwinną pracą nad produktem pokazują dokładnie ten wzorzec na innym poziomie: w badaniu branżowym dotyczącym Agile Epics naukowcy opisują, że źle zdefiniowane wymagania prowadzą do churnu, opóźnień, problemów z jakością i niepotrzebnych kosztów. AI nie może magicznie rozwiązać takich wąskich gardeł. Może je co najwyżej szybciej uwidocznić. Badanie ArXiv o Agile Epics i jakości wymagań

Dlatego decydującym przeciwieństwem do ślepego używania AI nie jest mniej AI, lecz lepszy agile delivery. Kto szuka dla tego nadrzędnych dźwigni, znajdzie je tutaj: Przewodniku po przyszłości agile software development wspieranego przez AI

Wiele wizji przyszłości AI w agile software delivery wydaje się atrakcyjnych, bo elegancko czynią odpowiedzialność niewidzialną: Jeden agent analizuje opinie użytkowników, następny pisze wymagania, następny implementuje, następny testuje, a następny wdraża.

Technicznie sporo z tego jest wykonalne. Organizacyjnie szybko robi się to nieostre.

Zwłaszcza w agentowej inżynierii oprogramowania trzeba więc ostrzej postawić stare pytanie zarządcze: Kto decyduje? Kto weryfikuje? Kto ponosi konsekwencje? IBM formułuje podstawowy problem w wartym przeczytania omówieniu AI decision-making: odpowiedzialność pozostaje po stronie człowieka, zwłaszcza gdy systemy przygotowują lub przyspieszają decyzje. IBM o odpowiedzialności w AI decision-making

Także AI Agile Manifesto stawia tu właściwy kontrapunkt: więcej inteligencji maszynowej bez ludzkiego osądu nie jest postępem, lecz błędnym kierunkiem. AI Agile Manifesto w oryginale

Właśnie dlatego nie wystarczy mówić tylko o możliwościach narzędzi. Gdy agenci interpretują wymagania, wprowadzają zmiany albo uruchamiają nawet działania bliskie produkcji, odpowiedzialność musi być organizacyjnie bardziej jednoznaczna i bardziej widoczna.

Czwarte niepowodzenie często staje się widoczne dopiero z opóźnieniem: poszczególne programistki i programiści lub zespoły wydają się skrajnie produktywni, podczas gdy cała organizacja staje się bardziej ociężała.

Dzieje się tak, gdy każdy lokalnie optymalizuje się z pomocą AI, ale prawie nikt nie wzmacnia całego systemu:

• Zasady architektury są stosowane niespójnie
• te same problemy są rozwiązywane równolegle wiele razy
• Systemy review i testów są przeciążane
• Pipelines delivery stają się punktem zatoru
• Narasta obciążenie incydentami i praca odtwórcza

Birgitta Böckeler opisuje w swojej rozmowie dla InfoQ o Harness Engineering, dlaczego większa autonomia zawsze niesie ze sobą też większe ryzyko i musi być ograniczana przez odpowiednie mechanizmy feedforward i feedback. Podcast InfoQ z Birgittą Böckeler o Harness Engineering

To, że nie jest to ryzyko teoretyczne, pokazuje kilka przypadków, które stały się publicznie znane. Według doniesień Amazon zaostrzył w 2026 roku swoje wewnętrzne guardrails po poważnych seriach incydentów, w których jako czynnik współodpowiedzialny wskazywano także systemy agentowe lub bliskie AI. Wniosek był znamienny: więcej udokumentowanych zmian, więcej akceptacji, więcej “controlled friction” w krytycznych systemach. Innymi słowy: nie każde lokalne przyspieszenie poprawia cały system. Czasem tylko szybciej ujawnia jego słabe punkty. Reportaż Business Insidera o zaostrzonych guardrails Amazona dotyczących AI

Drugą, odmienną formę tej samej entropii widać w tak zwanym Vibe Coding wspieranym przez AI. Axios donosił w 2026 roku, powołując się na badaczy bezpieczeństwa, o setkach tysięcy publicznie dostępnych artefaktów, w tym tysiącach zawierających wrażliwe dane firmowe. Nie zawodzi tu przede wszystkim pojedynczy prompt, lecz cały system standardów, dostępów, domyślnych ustawień, rozumienia bezpieczeństwa i governance. Reportaż Axios o Vibe Coding i publicznie dostępnych artefaktach

Krótko mówiąc: im bardziej autonomiczna jest AI, tym ważniejsze są ramy organizacyjne i techniczne, w których działa.

Dlaczego krótkoterminowa produktywność i tokenmaxxing to zła strategia AI

Niektórzy liderzy reagują na nową dźwignię AI prostym wnioskiem: To trzeba po prostu wymusić jak najszybsze i jak największe użycie AI.

To jest dokładnie błędna reakcja zarządcza.

Dlaczego?

Ponieważ „krótkoterminowa produktywność” w tym kontekście zazwyczaj oznacza tylko to:

• więcej generowanego kodu
• więcej sesji z AI
• większe zużycie tokenów
• więcej lokalnie rozwiązywanych zadań

Ale to wszystko mówi jeszcze prawie nic o pytaniach, które dla AI w zwinnym dostarczaniu oprogramowania są naprawdę kluczowe:

• Czy rozwiązano właściwy problem?
• Czy zespół rozumie zmianę?
• Czy zmianę da się bezpiecznie wdrożyć?
• Czy system po zmianie jest lepszy, czy bardziej kruchy?
• Czy organizacja uczy się szybciej, czy tylko bardziej nerwowo?

Właśnie dlatego Tokenmaxxing jest tak dobrym sygnałem ostrzegawczym. Pokazuje, co się dzieje, gdy firmy traktują korzystanie z AI jak cel sam w sobie. Wtedy pracownicy maksymalizują dokładnie to, co jest widocznie nagradzane, nawet jeśli podnosi to koszty, entropię i pracę w ciemno. Pragmatic Engineer o trendzie Tokenmaxxing

Jez Humble już dawno przed obecną falą AI trafnie opisał ten problem zarządczy: gdy menedżerowie bezpośrednio skupiają się na produktywności, długoterminowe usprawnienia często w ogóle nie są wprowadzane. W przypadku AI w agile Software Delivery problem ten jest jeszcze bardziej nasilony. Jez Humble o skupieniu na produktywności i braku długoterminowych usprawnień

Co działa zamiast tego: Cztery solidne rozwiązania dla AI w agile Software Delivery

1. Wyraźnie utrzymać odpowiedzialność po stronie człowieka

AI może przyspieszać, proponować i odciążać. Nie może jednak stać się wymówką dla rozmycia odpowiedzialności za decyzje i jakość.

Praktycznie oznacza to:

• jasno określeni właściciele architektury, bezpieczeństwa i decyzji istotnych dla produktu
• brak metryk sukcesu, które nagradzają jedynie aktywność AI
• wyraźne zasady przeglądu i zatwierdzania zmian generowanych przez AI

2. Budować engineering harness zamiast tylko narzędzi AI

Wiele zespołów najpierw inwestuje w modele, a dopiero na końcu w warunki, w których te modele mogą bezpiecznie działać. Trzeba to dokładnie odwrócić.

Do solidnego harnessu dla AI w zwinnym dostarczaniu oprogramowania należą na przykład:

• dobre specyfikacje
• małe, możliwe do zweryfikowania pakiety pracy
• automatyczne testy
• analiza statyczna
• kontrolowane sandboxy
• jasne konteksty architektoniczne
• szybki feedback z CI, delivery i produkcji

Jeśli interesuje Cię ta myśl, OpenSpec i GitHub Spec Kit są również przydatnymi punktami odniesienia w temacie pracy z AI opartej na specyfikacjach: OpenSpec do rozwoju produktów opartego na specyfikacjach, GitHub Spec Kit do rozwoju spec-driven

3. Sprawić, by feedback od klientów był szybszy niż produkcja kodu

AI jest trwałą dźwignią w delivery tylko wtedy, gdy przyspieszane są także cykle uczenia się. W przeciwnym razie produkuje się po prostu szybciej obok rzeczywistości.

To konkretnie oznacza:

• mniejsze wydania
• więcej eksperymentów z rzeczywistymi pętlami informacji zwrotnej od klientów
• bardziej konsekwentna analiza danych o wykorzystaniu funkcji
• szybszą analizę sygnałów od wsparcia i użytkowników

Kto tylko zwiększa szybkość kodowania, ale nie szybkość i jakość feedbacku, nie buduje AI-native organization, lecz jedynie szybszą “Feature Factory”, jak opisuje to John Cutler. Zobacz: 12 Signs You’re Working in a Feature Factory

4. Traktować retrospektywy i pętle uczenia się poważnie

Jeśli AI w zwinnym dostarczaniu oprogramowania zawodzi, przyczyny są często systemowe. Wtedy niewiele pomaga optymalizowanie pojedynczych promptów czy narzędzi.

Zespoły potrzebują rutyn, w których widzą powtarzające się wzorce i systematycznie je rozwiązują:

• Gdzie tracimy zrozumienie?
• Gdzie narasta zator w review?
• Gdzie AI generuje więcej poprawiania niż korzyści?
• Gdzie optymalizujemy lokalną szybkość kosztem całego systemu?

Właśnie dlatego retrospektywy pozostają istotne. Nie jako rytuał z przeszłości Scruma, lecz jako mechanizm uczenia się organizacyjnego w środowisku o wyższej częstotliwości zmian.

Wniosek: AI w zwinnym dostarczaniu oprogramowania rzadko zawodzi z powodu zbyt małej ilości AI

Prawdziwa ironia polega na tym: Wiele organizacji nie przegrywa z AI dlatego, że są zbyt ostrożne, lecz dlatego, że zarządzają zbyt krótkowzrocznie.

Mylą krótkoterminową produktywność ze zrównoważonym tworzeniem wartości i ulepszaniem systemu delivery. Mylą zużycie tokenów z tworzeniem wartości. Mylą autonomiczne generowanie kodu z dojrzałością organizacyjną.

Lepsze pytanie przewodnie brzmi więc nie: „Jak sprawić, by nasze zespoły używały jeszcze więcej AI?”

Lecz raczej:

• W jakich warunkach AI naprawdę poprawia nasze delivery?
• Gdzie AI właśnie tworzy nowe wąskie gardła w łańcuchu wartości?
• Gdzie AI ujawnia systemowe braki, które musimy naprawić?
• Jakie zdolności organizacyjne musimy wzmocnić, aby przyspieszenie nie zamieniło się w entropię?

Jeśli najpierw chcesz otrzymać do tego trzeźwe dane empiryczne, czytaj dalej tutaj: stan badań nad KI w zwinnej inżynierii oprogramowania .

Jeśli szukasz bezpośrednio dźwigni zarządczych, przejdź dalej tutaj: Przewodnik dla CTO i Engineering Managerów po AI w agile software development .

FAQ o KI w zwinnej dostawie oprogramowania

Dlaczego AI daje mojemu zespołowi więcej outputu, ale nie lepszy delivery?

Ponieważ większy output nie oznacza automatycznie lepszego delivery. Jeśli review, testy i feedback nie nadążają, przede wszystkim rośnie złożoność.

Co oznacza Tokenmaxxing w rozwoju oprogramowania wspieranym przez AI?

Tokenmaxxing oznacza uczynienie z korzystania z AI albo zużycia tokenów celu. Mierzy aktywność, ale nie wartość.

Co powinni robić Engineering Managerowie zamiast tylko naciskać na produktywność AI?

Powinni wzmacniać odpowiedzialność, testy, review i pętle informacji zwrotnej. Dopiero to czyni AI użyteczną w długim terminie.

Czy zespoły mocno wspierane przez AI w ogóle nadal potrzebują rytuałów agile?

Tak, ale z innym naciskiem. Mniej dbania o status, więcej feedbacku, uczenia się i ciągłego doskonalenia.

Jak mam jako Engineering Manager mierzyć, czy AI w rozwoju oprogramowania naprawdę coś daje?

Mierz Lead Time, nakład pracy na review, wskaźnik błędów i korzyść dla klienta. Sam output nie wystarczy.

Dlaczego mój zespół pracuje z AI szybciej, ale wyniki nie są lepsze?

Bo więcej kodu nie daje automatycznie lepszych rezultatów. Bez solidnych review, testów i feedbacku rośnie tylko entropia.

Jakie KPI powinienem naprawdę śledzić dla AI w rozwoju oprogramowania?

Śledź czas realizacji, Defect Rate, Rework, bezpieczeństwo wdrożeń i czas do feedbacku od klienta. Same tokeny mówią za mało.

Jak zapobiec temu, żeby kod generowany przez AI później spowalniał mój zespół?

Utrzymuj zmiany małe, testuj je porządnie i wymagaj jasnego review. AI może przyspieszać, ale nie może zastępować zrozumienia.