AI przyspieszyło development. Wąskim gardłem stała się reszta firmy

Pilotaż AI, który okazał się za szybki

6 października 2026 roku Mark Ajzenstadt, założyciel firmy Limestone Digital, opisał we wpisie na X pilotaż AI u producenta sprzętu, w którym oprogramowanie stanowi dużą część wartości produktu. Po stronie klienta ponad stu inżynierów, kod rozwijany od 2017 roku i plan, żeby w przyszłym roku przebudować większość systemu siłami obecnego zespołu.

Jak relacjonuje autor, CTO bał się przede wszystkim o ludzi po stronie produktu. Jeśli AI przyspieszy zespoły scrumowe, kto napisze dla nich specyfikacje? Nie miał dziesięciu product ownerów i spodziewał się, że kłopot pojawi się dopiero wtedy, gdy z AI zacznie korzystać dziesięć zespołów.

Pojawił się w czwartym tygodniu, przy dwóch inżynierach. Pilotaż objął jedną samodzielną aplikację mobilną. Kod pisali agenci AI, a inżynierowie kierowali pracą i ją sprawdzali. Poprzeczka wisiała wysoko, bo chodziło o oprogramowanie jakości produkcyjnej, które zespół klienta utrzyma bez przeglądania każdej linijki. Gdy kod był gotowy, okazało się, że product managerowie wciąż zakładają, że mają więcej czasu. Wymagania do kolejnego etapu zamierzali opracowywać ręcznie, w Wordzie i arkuszach kalkulacyjnych.

“We could build faster than the business could decide what came next.”

„Potrafiliśmy budować szybciej, niż biznes był w stanie zdecydować, co dalej” (tłum. CAASUAL).

Nikt nie zaproponował, żeby development zwolnił. Zespół przesunął agentów AI wcześniej w procesie. Firma łączyła trzy aplikacje mobilne w jedną, więc zamiast pisać dokumentację od zera, agenci mieli w dzień lub dwa zmapować funkcje, powtórzenia i luki we wszystkich trzech. Biznes dostawał coś konkretnego do oceny, a celem było zatwierdzenie zakresu w ciągu tygodnia.

Autor zwraca uwagę na jeszcze jedną zmianę. Rok wcześniej jego rozmówca mówił, że AI nie ufa i nie jest na nie gotowy. Dziś zastanawia się, jak przygotować resztę organizacji na nowe tempo. Ajzenstadt kończy wpis wnioskiem, że pilotaż AI powinien sprawdzać także to, czy nadąża za nim część procesu, w której zapadają decyzje.

Dlaczego wąskie gardło zawsze się przesuwa

To, co spotkało CTO, ma swoją nazwę. Eliyahu Goldratt opisał ją w latach 80. w książce „Cel” jako teorię ograniczeń: przepustowość całego procesu wyznacza jego najwolniejszy etap. Przyspieszenie etapu, który nie jest wąskim gardłem, nie przyspiesza całości. Powiększa tylko kolejkę przed następnym.

AI sprawia, że widać to szybciej niż kiedykolwiek, bo potrafi wielokrotnie przyspieszyć pojedyncze zadania. Zespół DORA z Google Cloud w raporcie za 2025 rok, opartym na ankiecie wśród prawie 5 tys. specjalistów, opisuje AI jako wzmacniacz. Silnym zespołom pomaga, słabszym uwypukla problemy, które już mają. Autorzy piszą też, że przyspieszenie developmentu może odsłonić słabe punkty w dalszych etapach procesu, a największy zwrot daje uporządkowanie przepływu pracy i zgranie zespołów, a nie same narzędzia.

Andrew Ng mówił o tym samym w wystąpieniu „Building Faster with AI” na AI Startup School Y Combinator w 2025 roku. Jego zespoły budują prototypy nawet dziesięć razy szybciej, więc coraz częściej najdłużej trwa decyzja, co budować. Wspomniał nawet o zespole, który zaproponował mu więcej product managerów niż inżynierów.

Ciekawie wyglądają też dane z raportu Figmy o AI (8403 odpowiedzi ankietowe i 639 wywiadów z trzech lat). 90% badanych uważa, że design jest co najmniej tak ważny jak przed erą AI, a 65% developerów twierdzi, że jest dziś ważniejszy. Kiedy jeden zespół dostaje AI, od razu warto więc zapytać, kto będzie następnym wąskim gardłem.

Gdzie utknie Twoja firma

W opisanej historii kolejka ustawiła się przed wymaganiami produktowymi. W firmach, które tworzą produkty cyfrowe i prowadzą kampanie, takich miejsc jest więcej, a każde może zatrzymać zespół, który dostał AI jako pierwszy.

Developerzy pracujący z agentami kończą zadania szybciej, niż firma ustala, co ma powstać w następnej kolejności. Szybszy development potrzebuje też szybciej kompletnych projektów, a gdy dostaje niepełne makiety, dopytywanie i poprawki po wdrożeniu zjadają czas, który miało oszczędzić AI. Marketing pisze z AI teksty kampanii w kilka minut, ale każdy nowy format, rozmiar i wersja językowa wciąż czeka w kolejce do projektantów. W sprzedaży i HR problem wygląda inaczej. Prezentacje i ogłoszenia robione w AI na własną rękę powstają szybko, tylko nie wyglądają jak Twoja marka, więc wąskim gardłem staje się spójność.

Proces projektowy leży pośrodku tego łańcucha. Przyjmuje decyzje biznesu i oddaje gotowe materiały developmentowi, marketingowi i sprzedaży, dlatego to tam przyspieszenie z jednej strony najszybciej zamienia się w kolejkę z drugiej.

Lekcja z pilotażu: AI wcześniej w procesie

Nas w tej historii najbardziej interesuje to, co zespół zrobił, gdy zobaczył problem. Nie kazał developerom zwolnić i nie dokładał ludzi do pisania dokumentacji. Przeniósł AI na etap, który hamował całość, i użył go do przygotowania materiału do decyzji. Ludzie nadal decydowali, tyle że szybciej, bo mieli co ocenić.

W procesie projektowym wygląda to bardzo podobnie. AI może przygotować adaptacje kampanii do kolejnych formatów i języków, zanim projektant usiądzie do pracy. Może uzupełnić projekt o opisy stanów i komponentów, których potrzebuje developer, sprawdzić zgodność projektu i kodu z design systemem albo opisać markę tak, żeby narzędzia generatywne odtwarzały ją wiernie. Decyzja za każdym razem zostaje po stronie ludzi, AI skraca do niej drogę.

Jak sprawdzić, czy Twój proces nadąży za AI

Zanim rozszerzysz pilotaż AI na kolejne zespoły, odpowiedz sobie na kilka pytań:

1. Gdzie dziś czeka praca? Szukaj zadań „prawie gotowych”, które stoją przed następnym etapem.
2. Ile trwa decyzja, od pomysłu do zatwierdzonej specyfikacji i od projektu do akceptacji?
3. Czy developerzy dostają kompletne projekty, czy wracają z pytaniami?
4. Ile trwa przygotowanie kampanii w kolejnych formatach i językach?
5. Czy materiały z AI robione poza zespołem projektowym wyglądają jak Twoja marka?
6. Co właściwie mierzy pilotaż? Jeśli tylko tempo jednego zespołu, nie zobaczysz, gdzie utknie reszta.

Jeśli przy którymś pytaniu odpowiedź brzmi „to zależy” albo „nie wiemy”, właśnie tam warto zacząć.

Od czego zaczynamy w CAASUAL

Z tego samego powodu nasza usługa AI design workflows zaczyna się od mapy procesu, a nie od wyboru narzędzi. Najpierw sprawdzamy, na jakim etapie i między którymi zespołami projekty utykają. Potem wskazujemy, gdzie AI najszybciej odda zespołom czas, a czego lepiej nie automatyzować. Narzędzia dobieramy na końcu i włączamy w codzienną pracę marketingu, sprzedaży i developmentu, nie tylko zespołu projektowego.