[Przesunięcie punktu wąskiego gardła] Gdy kod jest praktycznie darmowy, gdzie przesunęły się ograniczenia inżynierii oprogramowania? Transformacja inżynierii oprogramowania w erze AI — Ucz się powoli o AI 173
Gdy kod jest praktycznie darmowy, wąskie gardła przesuwają się do definiowania wymagań, integracji, weryfikacji i alignowania
Gdy produkcja kodu staje się praktycznie darmowa, wąskim gardłem dostawy oprogramowania przestaje być „pisanie kodu” — staje się nim: zdefiniowanie prawidłowego problemu, połączenie fragmentów w działający całość, zweryfikowanie, że rzeczywiście jest to prawidłowe rozwiązanie, oraz wyrównanie organizacji. To ponowne odtworzenie Teorii Ograniczeń (Theory of Constraints) w branży oprogramowania. Przemysł wytwórczy przeżył to 40 lat temu: gdy którykolwiek etap stawał się tańszy, wąskie gardło nie znikało — po prostu przesuwało się na następny, najdroższy etap. Zrozumienie tego pozwala wyjaśnić powszechny paradoks: narzędzia AI do programowania zostały wdrożone w całej firmie, pisanie kodu znacząco przyspieszyło, a tempo dostawy nie zmieniło się znacząco.
CIO jednej z grup przemysłowych pokazał mi dane z ostatnich sześciu miesięcy. Zespół IT liczył ponad 80 osób — wszyscy wykorzystywali narzędzia AI do programowania. W przypadku samego kodu: średnia liczba commitów i szybkość mergów wzrosła o ponad 30%. Ale doświadczenie z bocznego zespołu biznesowego było inne: funkcja inteligentnego planowania produkcji, od założenia do wdrożenia, nadal zajmowała minimum trzy miesiące. Oczekiwał on, że narzędzia przyspieszą proces o 2 razy — a otrzymał tylko „szybsze pisanie kodu”. Jego słowa były proste: „Zainwestowałem miliony w licencje — i dostałem tylko bardziej zatłoczone zespoły deweloperskie i bardziej nerwowe zespoły biznesowe”.
Załóżono błędnie, gdzie znajduje się wąski punkt. Prawdziwym wąskim punktem było coś innego: każda nowa funkcja musi przejść przez systemy MES, ERP, kontroli jakości, terminali produkcyjnych oraz zestaw raportów regulacyjnych — integracja i testowanie łączone zajmowały większość czasu; natomiast kod wygenerowany przez AI nie ma żadnych formalnych bramek akceptacji między nim a środowiskiem produkcyjnym. Choć kod pisze się szybko, to i tak czeka w kolejce za błędnie zidentyfikowanym wąskim punktem.
I. Produkcja: 40 lat temu już wiedziano — wąski punkt się przesuwa
Aby zrozumieć teraźniejszość, najpierw przyjrzyjmy się sytuacji przez okulary, które produkcja nosi od 40 lat.
W 1984 roku izraelski konsultant, fizyk Eliyahu Goldratt, napisał powieść „Cel” (The Goal), opowiadającą o dyrektorze fabryki na skraju upadku, który udaje się ją ożywić. Cała książka sprowadza się do jednego zdania: wydajność każdego systemu jest określana przez jego najwęższy element (ograniczenie, czyli wąski punkt).
Szerzenie nie-wąskich punktów nie zwiększa całkowitej wydajności; tylko rozszerzenie samego wąskiego punktu przyspiesza cały system. A gdy go rozszerzysz — wąski punkt natychmiast przesuwa się do następnego najwęższego miejsca. To jest Teoria Ograniczeń (Theory of Constraints, TOC).
Po 40 latach automatyzacji po przemyśle, prawie cała historia to historia „przenoszenia wąskich gardeł”. Gdy obróbka CNC uczyniła cięcie tańszym, wąskim gardeł stało się zmienianie form i kontrola jakości; gdy elastyczne linie produkcyjne przyspieszyły zmianę form, wąskie gardeło przesunęło się do planowania produkcji i koordynacji łańcucha dostaw; gdy MES uczynił planowanie dokładniejszym, wąskie gardeło przesunęło się do prognozowania popytu i koordynacji między zakładami. Każde zautomatyzowane ogniwo powoduje, że następne wypływa na powierzchnię. Automatyzacja nigdy nie eliminuje wąskich gardeł — tylko przesuwa je w inne miejsce. Ta zasada nie jest wyłącznym prawem przemysłu. W lipcu 2026 roku w podcastzie a16z „Software in the Age of Agents” były prezes Microsoft Windows Steven Sinofsky, opierając się na przykładach oprogramowania przedsiębiorstw, niezależnie doszedł do tego samego wniosku. Jego słowa brzmiały:
“The long tail got no shorter. It just got longer in a different way.”
Przykładem jest obsługa klienta Amazon: wycofanie telefonów i wdrożenie chatbota, który automatycznie wysyła nowe produkty — na pierwszy rzut oka oszczędza to人力, ale natychmiast pojawia się potrzeba analizy przyczyn korzeniowych: „Jak zapobiec powtórzeniu się tego samego problemu?” — to zadanie jest znacznie bardziej skomplikowane niż odpowiadanie na telefony. To samo dotyczy procesu rozliczeń: po automatycznym wprowadzeniu faktur za pomocą OCR, zadaniem księgowych staje się optymalizacja kosztów podróży i dynamiczne porównywanie cen — praca nie zniknęła, tylko przesunęła się z „wprowadzania” na poziom „analizy i decyzji”. Starszy pracownik Microsoftu, partner a16z, nie odwoływał się do teorii Goldratta, ale doszedł do tego samego wniosku, co produkcja 40 lat temu. Jeden pochodzi z warsztatu, drugi z oprogramowania przedsiębiorstw — dwie niezależne ścieżki prowadzą do tej samej reguły.
Jednak należy dodać do tej reguły ograniczenie, by nie była odbierana jako bezwzględna prawda. Istnieją rzeczywiście bariery, które zostały trwale wyeliminowane: maszynistki, operatorki telefoniczne, składacze czcionek — te zawody nie zostały „przesunięte”, lecz znikły bezpowrotnie. Kluczowe jest rozróżnienie: czy praca zostanie przesunięta, czy zniknie — zależy to od tego, czy automatyzacja uwolniła产能, które wywołały nowe potrzeby (w ekonomii nazywane to paradoksem Jevonsa), czy po prostu spowodowały zmniejszenie się tej potrzeby. Większość zadań wokół kluczowych systemów przedsiębiorstw należy do pierwszej kategorii: im szybciej liczy się rachunki, tym więcej i szczegółowsze analizy chce zobaczyć menedżer. Dlatego wniosek nie brzmi: „Automatyzacja zlikwiduje tyle pracy”, lecz: „Przenieś ludzi i budżet z poziomu, który został zautomatyzowany, na nowo powstały poziom.” (Długa ogona przesunięć z perspektywy oprogramowania przedsiębiorstw — pełna analiza w dodatku „Przyklejoność oprogramowania przedsiębiorstw”.)
To jest bliżej oprogramowania, niż się wydaje. W 2013 roku Gene Kim przeniósł prawie bez zmian opowieść Goldratta o fabryce do świata IT operations, tworząc „The Phoenix Project”: historię o CIO, który wykorzystał teorię ograniczeń, by ożywić dział IT, który niemal zniszczył całą firmę. Zatem „patrzenie na oprogramowanie przez pryzmat wąskich gardeł produkcji” to już zweryfikowana ścieżka, a nie chwilowy metafora. # 2. Powrót do oprogramowania: pisanie kodu staje się najtańszym etapem
Trzy liczby jasno pokazują, że koszt produkcji kodu dąży do zera.
- Copilot: Badanie przeprowadzone przez GitHub wykazało, że w plikach z włączonym Copilotem około 46% kodu zostało wygenerowane przez Copilot. Uwaga na metodologię: chodzi o udział w włączonych plikach, nie o 46% całego kodu na GitHubie.
- Stripe: Wewnętrzny agent kodowania “Minions”, który tygodniowo generuje i łączy ponad 1 300 PR (wcześniej 1 000, liczba stale rośnie). Kluczowa detale: każdy PR podlega recenzji przez człowieka przed scaleniem. Stripe zautomatyzował “pisanie”, ale recenzję pozostawił ludziom. Ten szczegół będzie wykorzystany w sekcji czwartej.
- NVIDIA: Jensen Huang publicznie stwierdził, że 100% inżynierów NVIDIA używa narzędzi AI do programowania, takich jak Cursor — “pracowanie bez AI” w NVIDIA nie jest już akceptowane.
Gdy połączymy te trzy liczby, wniosek jest jednoznaczny: koszt wyprodukowania jednej linijki kodu szybko zbliża się do zera. Powstaje ostre pytanie: skoro pisanie kodu jest prawie darmowe, dlaczego oprogramowanie nadal jest tak drogie, powolne i trudne do dostarczenia? Odpowiedź daje teoria ograniczeń: rozszerzyłeś etap “pisanie kodu”, ale wąski gardło się tylko przesunęło. Gdzie?
Trzy. Ograniczenia przesunęły się do czterech miejsc
Tym razem ograniczenia skupiły się na czterech etapach. Każdy z nich jest nieosiągalny dla AI w bliskiej przyszłości.
Pierwszy: Definiowanie prawidłowego problemu.
AI potrafi w kilka sekund wygenerować „funkcję, o której mówisz”, ale nie potrafi wygenerować „funkcji, której naprawdę potrzebujesz”. Większość projektów oprogramowania kończy się porażką, bo stworzony produkt nie jest używany — na samym początku nie zrozumiano, jaki problem ma być rozwiązany. Gdy produkcja kodu stała się tańsza, „przekształcenie niejasnego problemu biznesowego w jasny, rozwiązywalny i wart rozwiązania specyfikację” (problem formulation) stało się najrzadszą i najdroższą umiejętnością. Przemysł produkcji nie jest tym obcy: jeśli ścieżka technologiczna lub rysunki inżynierskie są błędne, to nawet najbardziej wydajna produkcja w warsztacie da tylko masową ilość wyrzutów.
Drugi: Integracja systemów.
AI świetnie generuje „fragment kodu”, „funkcję”, „stronę”. Ale system gotowy do wdrożenia to integracja setek takich fragmentów — muszą one wymieniać dane, obsługiwać granice, zachowywać spójność i wytrzymywać wyjątki. Generowanie pojedynczych fragmentów jest tanie; ich połączenie w spójną, niezawodną całość jest drogie. Ten koszt wynika z niezgodności organizacyjnej i architektonicznej — dokładnie to, czego dotyczą prawo Conwaya i topologie zespołów (patrz dwie poprzednie części tej serii). Wróćmy do CIO z przemysłu, którego wspomnieliśmy na początku: jego czas nie został zużyty na pisanie kodu, ale na koordynację między systemami MES, ERP, kontroli jakości i raportowania.
Trzecia bariera: weryfikacja. Objętość kodu rośnie wykładniczo, a jego wiarygodność jest zmienna. Kto decyduje, czy jest poprawny? Testy, przeglądy kodu, obserwowalność, wdrożenia stopniowe — te działania weryfikacyjne stają się coraz ważniejsze, a nie mniej. To najbardziej niedoceniana bariera, a jednocześnie najgłębsza odbicia w przemyśle. O tym będzie osobisty rozdział w sekcji czwartej.
Czwarta bariera: zgodność organizacyjna. Kiedy w zespole pojawiają się agenti AI, kto decyduje, co robić? Kto przegląda? Kto ponosi odpowiedzialność za wynik? To kolejne rozszerzenie prawa Conwaya i topologii zespołów — sama zgodność organizacyjna staje się barierą. W 11. części serii szczegółowo omówimy: gdy węzły organizacyjne nie są już wyłącznie ludźmi, zarządzanie staje się kluczową przewagą konkurencyjną.
# 4. Najgłębszy cięcie: weryfikacja — i czego naucza nas Toyota z „jidoka”Spośród czterech barier, najbardziej źle zrozumianą jest weryfikacja. Wiele osób postrzega ją jako „skoro AI pisze szybko, to niech testuje więcej razy”. To prawda tylko częściowo. Aby zrozumieć, dlaczego weryfikacja staje się droższa, musimy najpierw poprawnie wyjaśnić koncepcję, która jest najbardziej źle interpretowana i najczęściej błędnie cytowana: jidoka (自働化).
Najpierw poprawmy powszechnie rozpowszechniony błąd. Jidoka nie oznacza „zastępowania ludzi przez AI lub maszyny”, ani też „przekształcania ludzi w maszyny, które nieustannie pracują jak maszyny”. Oba te podejścia są odwrotne.
Słowo „jidōka” w samym sobie zawiera odpowiedź. W języku japońskim „automatyzacja” to zwykła automatyzacja, ale Toyota celowo używa „自働化” — znak „働” zawiera component „człowiek”, podkreślając „automatyzację z ludzkim dotykiem” (automation with a human touch). Jej dokładne znaczenie brzmi: gdy maszyna lub linia produkcyjna wykryje anomalie, automatycznie się zatrzymuje, by umożliwić człowiekowi介入 i usunięcie korzeniowego problemu, po czym produkcja jest wznowiona. Działa ona poprzez dwa równoległe mechanizmy: maszyny są wyposażone w wykrywanie anomalii i same się zatrzymują; każdy pracownik na linii, zauważając niezgodność, ciągnie sznurek andon — i cała linia natychmiast się zatrzymuje. Jakość nie jest sprawdzana na końcu, ale wbudowana w każdą operację i rozwiązywana na miejscu.
Tu pojawia się kontrintuicyjny wniosek, który bezpośrednio odnosi się do oprogramowania: im głębsza automatyzacja, tym większe znaczenie mają punkty kontroli jakości i rola człowieka. Jidōka wyzwala ludzi z „powtarzalnych operacji” i ponownie umieszcza ich w roli „wykrywania anomalii, zatrzymywania linii, rozwiązywania korzeniowych przyczyn”. Toyota nadaje pracownikom na linii prawo zatrzymania całej produkcji właśnie dlatego, że rozumie: nawet najbardziej zaawansowana automatyzacja wymaga człowieka, który potrafi zatrzymać proces w przypadku błędu. To jest prawdziwe znaczenie hasła „nadawanie robotom mądrości”: umożliwienie maszynom zatrzymywania się i wołania o pomoc człowieka. Człowiek zawsze jest obecny — odpowiada za rozwiązywanie korzeniowych przyczyn.
Oprogramowanie idzie tym samym ścieżką — i robi to bardzo szybko. Badania GitClear nad jakością kodu wspieranego przez AI wykazały wzrost powtarzających się bloków kodu oraz rosnący churn w krótkim terminie: AI pisze szybko, ale też pisze „wygląda to dobrze”. Gdy duża ilość kodu nie jest już pisanego ręcznie krok po kroku, tradycyjny mechanizm zaufania „programista wie, co robi” przestaje działać. Wtedy potrzebujesz wersji oprogramowania dla sznurka Andon i mechanizmu zatrzymania linii:
- Testy (jednostkowe, integracyjne, end-to-end) przechodzą z „staraj się robić” na obowiązkowy próg — bez przejścia nie można merge’ować;
- Code review skupia się nie na „sprawdzaniu sposobu pisania”, ale na „sprawdzaniu intencji i granic”: co ten kod ma rozwiązać, czy pokryto warunki brzegowe?
- Obserwowalność (monitoring, logi, śledzenie) staje się standardem, ponieważ zachowanie w produkcji mówi więcej niż sam kod;
- Wydania stopniowe / flagi funkcji pozwalają na weryfikację kodu wygenerowanego przez AI w małej skali, zanim zostanie on w pełni wdrożony.
Patrząc z powrotem na sekcję drugą — te 1 300 PR od Stripe: kod piszą agenci, ale merge’owanie pozostaje w rękach ludzi. To jest żywotny przykład samodzielnej automatyzacji w oprogramowaniu: zautomatyzuj produkcję, ale zatrzymaj akceptację u człowieka — i nadaj mu władzę „zatrzymania tego”. Produkcja staje się tańsza, kontrola jakości staje się droższa — to reguła, która nie zmieniła się przez 40 lat.
V. Premia za „sformułowanie problemu”: umiejętność bardziej wartka niż prompt
Jeśli weryfikacja jest niedocenianym węzłem, to „sformułowanie problemu” to umiejętność niedoceniana w sposób poważny. Prompt engineering przeżył swoją chwilę sławy, a wielu uważa, że „umiejętność pisania promptów” to kluczowa kompetencja. Ale prompt to tylko technika „wyrażenia problemu”. Prawdziwie rzadką umiejętnością jest krok o krok dalej: formułowanie problemu (problem formulation) — rozłożenie niejasnego problemu biznesowego na jasny, rozwiązywalny i wart rozwiązania problem. Krok ten AI na krótko nie jest w stanie wykonać, ponieważ musi najpierw usłyszeć od Ciebie: „Jaki jest problem?”.
Stare fachowce z przemysłu najlepiej rozumieją wagę tego kroku. Gdy rysunek techniczny lub linia technologiczna zostaną źle zdefiniowane, nawet najbardziej wydajna obróbka i montaż na dole spowodują masową produkcję błędów. To samo dotyczy oprogramowania: jeśli specyfikacja wymagań jest błędna, AI pomogą Ci stworzyć dziesięciokrotnie szybciej tonę rzeczy, których nikt nie chce.
Prosty test: przestań konkurencję o „szybkość pisania kodu” — ćwicz „jasność rozkładania problemów”. W organizacji oznacza to, by „definiowanie wymagań” i „weryfikacja akceptacji” stały się oficjalnymi stanowiskami, a nie zostawały zadaniem dodatkowym dla programistów. Po tym, jak AI uczyniły realizację tanią, zwrot z tych dwóch stanowisk rośnie najszybciej.
VI. Jak wyglądają prawdziwe węzły w czterech branżach
Gdy zastosujemy „przesunięcie węzła” do czterech branż, ich węzły nie leżą w pisaniu kodu.
Przemysł. Główne zagadnienie to CIO z początku artykułu. Funkcje takie jak inteligentne planowanie produkcji, śledzenie jakości i optymalizacja zużycia energii nie są technicznie trudne — modele są często już gotowe. Kluczowym wąskim gardłem jest integracja i testowanie współdziałania systemów MES/ERP/kontroli jakości/raportowania, a także weryfikacja na miejscu na terminalach produkcyjnych. Kod takich projektów pisze się szybko, ale integracja z systemami MES/ERP zajmuje kilkukrotnie więcej czasu niż samo pisanie kodu. Tylko umieszczając punkt akceptacji bezpośrednio na terminalach produkcyjnych i w etapie integracji można zatrzymać błędy na miejscu, zamiast odkrywać je dopiero po wdrożeniu.
Telekomunikacja / operatorzy. Proces zmiany pakietu lub aktywacji linii dedykowanej dla firm musi przejść przez kilka domen: kanały sprzedaży, systemy rozliczeniowe, CRM, aktywację sieci oraz harmonogramowanie instalacji. AI przyspieszyła rozwój w każdej z tych domen, ale kluczowym elementem czasu projektu pozostaje end-to-end integracja i weryfikacja spójności między domenami. Operatorzy mają dodatkowe, unikalne wąskie gardło: zgodność i rozliczenia. Różnica w rozliczeniach nawet o jednego grosza to incydent — weryfikacja ma tu większą wagę niż w jakimkolwiek innym sektorze. Przykład: aktywacja linii dedykowanej dla firm — choć AI przyspieszyła rozwój w każdej domenie, end-to-end integracja wraz z rozliczeniami nadal zajmuje większość czasu projektu.
Finanse. Zmiana reguły ryzyka kredytowego lub antypranie pieniędzy obejmuje aplikację, systemy jądra, silnik ryzyka, platformę danych i raportowanie dla regulatorów. Weryfikacja tutaj ma ogromne znaczenie, ponieważ błąd jednej transakcji to incydent niezgodności z przepisami. Wąskim gardłem jest wyjaśnialność, audytowalność i śledliwość: nawet najdokładniejsze reguły napisane przez AI nie przejdą wymogu regulatora „Dlaczego tak zdecydowano?” i nie zostaną wdrożone. Iteracja reguł antyprania pieniędzy to typowy przykład: AI przyspiesza tworzenie reguł, ale przegląd wyjaśnialności modelu i synchronizacja z raportowaniem dla regulatora często pochłania większość całego cyklu.
E-commerce. Funkcja promocji lub dużego wydarzenia sprzedażowego obejmuje produkty, transakcje, marketing, magazyn i obsługę klienta. AI pozwala szybko pisać strony i interfejsy, ale wąskim gardłem stają się testy obciążeniowe, spójność zapasów, ochrona przed wykorzystywaniem luk i reconciliacja. W nocy wielkiej promocji padają nie kody napisane zbyt wolno, tylko te, których granice nie zostały zweryfikowane. Przygotowania do promocji to doskonały przykład: strona promocyjna może być wygenerowana przez AI w rekordowym czasie, ale end-to-end testy obciążeniowe i weryfikacja spójności zapasów zajmują większość czasu przygotowawczego.
Wspólna cecha czterech branż jest jasna: AI przyspiesza „pisanie”, a zatrzymuje „łączenie, weryfikowanie i synchronizowanie”. Włożenie oszczędzonej mocy produkcyjnej w te trzy obszary to prawdziwa efektywność.
7. Co się stanie, jeśli się pomyliłeś: trzy najczęściej występujące niezgodności
Pierwsza: Traktowanie „szybkiego pisania kodu” jako „szybszego dostarczania”.
To najpowszechniejsza iluzja. Kod to tylko jeden etap łańcucha dostawy; rozszerzenie go nie przyspieszy całego łańcucha — tylko spowoduje gromadzenie się większej ilości nieukończonych produktów. Teoria ograniczeń nazywa to zapasami; w oprogramowaniu to niezaakceptowane PR i gałęzie nieprzetestowane w integracji. Efekt? Deweloperzy są bardziej zatłoczeni, biznes jest bardziej pilny, a wydajność nie zmienia się — dokładnie sytuacja opisana na początku przez tego CIO.
Druga: Przyspieszenie produkcji przy jednoczesnym usuwaniu bram jakości.
To typowy błąd sprzeczny z jidoka. Niektórzy uważają: „AI pisze szybko i dobrze, więc code review można uprościć, a testy pominąć”. Tymczasem dokładnie odwrotnie — im szybsza produkcja, tym bardziej trzeba trzymać sznurka an-dō. Usunięcie bram akceptacji to jak puszczenie linii produkcyjnej na pełnych obrotach bez nadzoru — wady będą szybciej docierały do środowiska produkcyjnego.
Trzecia: Inwestowanie w nie-bottlenecki.
Bottleneck to integracja — a ty kupujesz więcej licencji na AI do programowania; bottleneck to weryfikacja — a ty zatrudniasz więcej deweloperów. Teoria ograniczeń jasno mówi: inwestowanie w nie-bottlenecki nie przynosi żadnego przyrostu ogólnej wydajności — tylko pogarsza bilans. Poprawna kolejność: najpierw zidentyfikuj bottleneck, potem skieruj na niego wszystkie zasoby.
VIII. Wnioski dla decydentów
Pierwsza lekcja: Zanim kupisz narzędzie, narysuj wykres wąskich gardeł.
Rozłóż trzy ostatnie przeszkody w dostarczaniu, by zobaczyć, gdzie rzeczywiście marnowane są czasy. Czy problem leży w braku kodu, braku integracji, braku weryfikacji, czy niejasnych wymaganiach? Jeśli nie możesz oznaczyć przyczyny — to po prostu zgadujesz na poziomie technicznym. Wykres wąskich gardeł jest cenniejszy niż każda lista zakupów narzędzi — może zapobiec co najmniej połowie nieefektywnych inwestycji IT w dużych firmach.
Druga lekcja: Zainwestuj oszczędzone zasoby w wymagania i weryfikację.
AI przyspiesza rozwój — oznacza to, że masz więcej ludzi do wykorzystania. Przydziel ich formalnie do dwóch ról: „definicja wymagań” i „weryfikacja akceptacji”. Nie pozwól im dalej siedzieć i pisać więcej kodu. Zyski z tych dwóch ról w erze AI rosną najszybciej.
Trzecia lekcja: Zainstaluj sznurek Andon w swoim oprogramowaniu.
Najprostszym zastosowaniem samodzielnej automatyki jest ustanowienie sztywnych granic w CI/CD: nie dopuszczaj mergu, jeśli testy nie przechodzą; przegląd musi sprawdzać intencję i granice; wdrożenie na próbę zaczyna się od małego zakresu; monitorowalność staje się standardem. Im bardziej automatyzowana jest produkcja, tym silniejsza musi być ta bariera. Chodzi o zapobieganie sytuacji, w której „kod jest darmowy” staje się „awarie są darmowe”.
Czwarta lekcja: Przeprowadź ludzi, nie usuwaj ich.
Samodzielna automatyka prowadzi do jednego wniosku: im głębsza automatyka, tym bardziej ludzie muszą być przesunięci na role „decyzji, weryfikacji, analizy korzeniowych przyczyn”. Wyzwol ich z powtarzalnych operacji i ponownie wykorzystaj w weryfikacji i zgodności — to kluczowa akcja w projektowaniu organizacji w erze AI, i o tym będziemy rozmawiać w kolejnych artykułach tej serii.
IX. Możesz się zapytać
„Tylko testujemy AI w małym zakresie — czy naprawdę musimy rysować wykres wąskich gardeł całej firmy?”
Nawet testy muszą zacząć się od zrozumienia: czy ten konkretny etap, w którym testujesz AI, to naprawdę wąskie gardło? Jeśli prawdziwy węzeł leży w integracji lub weryfikacji, to wprowadzanie AI w etapie „pisania kodu” to wydawanie pieniędzy tam, gdzie nie ma wąskiego gardła — dokładnie to, o czym mówimy w rozdziale siódmym: trzecia niezgodność. Przeprowadź najpierw małą diagnozę wąskich gardeł — wtedy pieniądze na narzędzia będą dobrze wydane.
„Czy etap weryfikacji nie spowolni dostaw?”
Na krótko — będzie opór, na długo — przyspieszenie. „Szybkość” bez weryfikacji to szybkość przesuwania defektów do środowiska produkcyjnego — koszt naprawy zaczyna się od dziesięciokrotności. Doświadczenie z automatyzacją: koszt rozwiązania defektu na miejscu to ułamek kosztu jego naprawy po przesunięciu do downstream.
„A jak to się ma do naszej aktualnej transformacji AI?”
Związek jest bezpośredni. Najczęstszy błąd w transformacji AI to założenie, że wąskie gardło leży w „pisaniu kodu / produktywności”, a potem kupowanie mnóstwa narzędzi, by rozszerzyć ten właśnie etap. Najpierw zrób diagnozę wąskich gardeł — dopiero potem decyduj, gdzie wydać pieniądze. Dlatego w ramach „7-krokowego ramy trenera transformacji AI” umieszczam „ocenę zdolności” i „identyfikację scenariuszy wartościowych” na samym początku: najpierw zobacz, gdzie jest wąskie gardło — dopiero potem mów o narzędziach.
Reverse self-check (be honest in your answer): The last time you got stuck delivering something, where did the time actually go—writing code, or piecing it together, checking it over, and aligning? Out of all the code your AI tools generate, how much actually ships stably and is genuinely used by users? In your CI/CD pipeline, is there a hard gate that blocks merges unless tests pass? If you feel uneasy about even one of these three, don’t rush to buy more AI tools—first find your real bottleneck.
Następny krok
To jest trzecia z 15 części serii „Transformacja inżynierii oprogramowania w erze AI”. Przeszliśmy od Konwina (organizacja decyduje o architekturze) i team topologies (jak projektować organizację) do przesunięcia punktów wąskich gardeł (gdy kod jest praktycznie darmowy, gdzie się przesunęły wąskie gardeła?). Następny artykuł (czwarty) zmieni perspektywę na bardziej praktyczną: jak wybierać główne narzędzia AI do programowania. Ale wniosek może być nieintuicyjny: wybór narzędzia to w istocie decyzja organizacyjna—powinieneś wybierać na podstawie swojego poziomu dojrzałości i poziomu zarządzania, a nie po tym, „kto pisze najbardziej kolorowy kod”.
Uwaga o serii: Ta seria będzie śledziła najnowsze rozwój narzędzi AI do programowania, architektury organizacyjnej i paradygmatów inżynierii oprogramowania—np. nowe zastosowania prawa Konwina w erze agentów AI lub dojrzałość najnowszych ekosystemów narzędzi. Obserwuj tę serię, by otrzymywać aktualne spostrzeżenia.
O tej serii
Przemiany inżynierii oprogramowania w erze AI to głęboki serię badań przeznaczoną dla CIO/CDO/CTO oraz odpowiedzialnych za digitalizację w branżach telekomunikacji, finansów, produkcji i handlu elektronicznego — składa się z 15 artykułów. Oparta na 200+ artykułach akademickich i raportach branżowych, oferuje referencje decyzyjne z oznaczeniem poziomu dowodów.
Jestem byłym inżynierem IBM, certyfikowanym trenerem ICF, który wdrażał projekty AI i digitalizacji w operatorach i dużych firmach. To, co tu piszę, to praktyczne oceny wypracowane w trakcie wspierania firm przez ich błędy.
Źródła referencyjne (weryfikowane)
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Cytat Stevena Sinofsky’ego, byłego prezenta Windows w Microsoft: „The long tail got no shorter, it just got longer in a different way” — niezależne potwierdzenie z perspektywy oprogramowania przedsiębiorstwowego prawa przesunięcia wąskiego gardła TOC; źródło pierwszorzędne — oryginalny nagranie podcastu. Oznaczenie stanowiska: partner a16z / były menedżer Microsoftu, stanowisko VC. Goście zweryfikowani: partnerka zespołu przedsiębiorstw a16z Seema Amble, były prezes Windows w Microsoft Steven Sinofsky (board partner), autorka a16z Elena Burger; wyemitowane w lipcu 2026 r.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Pierwotne źródło teorii ograniczeń (TOC); powieść z kontekstem fabryki produkcyjnej; źródło pierwszorzędne)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Przeniesienie TOC Goldratta bezpośrednio do IT operations — most między produkcją a oprogramowaniem; źródło pierwszorzędne)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automatyzacja z znakiem „人” — zatrzymanie linii przy awarii + interwencja człowieka w celu usunięcia korzenia problemu; system Andon; źródło pierwszorzędne)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot włącza ukończenie kodu wewnątrz pliku w około 46% przypadków — metryka „enabled in-file”; źródło pierwszorzędne)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ raportuje ponad 1 300 PR tygodniowo z pełną recenzją人工ną (źródło pierwszorzędne + drugorzędne)
NVIDIA / Jensen Huang. Otwarte oświadczenia, że 100% inżynierów używa narzędzi AI do programowania, takich jak Cursor (wypowiedź pierwszorzędną)
GitClear (2025). AI-Assisted Code Quality Research. (Obserwacja wzrostu powtarzalnego kodu i krótkoterminowego churnu przy wspomaganiu AI — wspiera tezę „weryfikacja staje się droższa”; źródło drugorzędne)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Wydajność dostarczania jest określana przez kulturę, prędkość przepływu i feedback — nie przez indywidualną szybkość pisania kodu; źródło pierwszorzędne)
buymeacoffee
![[Przesunięcie punktu wąskiego gardła] Gdy kod jest praktycznie darmowy, gdzie przesunęły się ograniczenia inżynierii oprogramowania? Transformacja inżynierii oprogramowania w erze AI — Ucz się powoli o AI 173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
