Firmy dostarczające rozwiązania na bazie IT wygrają lub przegrają nie tym, czy stosują AI, czy nie do kodowania, tylko tym, czy szybciej są w stanie spełnić wymagania użytkowników.

Klasyczny agile oferuje rytm dostaw co sprint, czyli w praktyce od momentu zgłoszenia zapotrzebowania do momentu, gdy użytkownik może zacząć korzystać z funkcji to ponad tydzień do ponad miesiąca. Tyle musi czekać użytkownik i w porównaniu z podejściem kaskadowym to była rewolucja, gdzie niekiedy na nową funkcjonalność trzeba było czekać kilka miesięcy.

Modele językowe szturmem wkroczyły do świata produkcji oprogramowania trzy lata temu i wraz ze wzrostem ich jakości wnioskowania coraz lepiej udowadniają swoją wartość. Jednym wymiarem wartości jest koszt produkcji, który według moich szacunków doprowadza do spadku wycen ofert na tworzenie software czterokrotnie. Ciekawe jak w takim świecie poradzą sobie software house'y, integratorzy i firmy doradcze. Niższe ceny pewnie wzmocnia efekt Jevonsa, czyli wzrośnie popyt na nowe bardziej spersonalizowane funkcje, wzrośnie też apetyt na samodzielne tworzenie rozwiązań IT wraz ze wzrostem ich dostępności. Jednak ten wzrost popytu nie jest nieskończony i będzie miał swoje granice. Ale nie to zjawisko jest przedmiotem poniższych rozważań.

Tutaj chcę zająć się skracającym się lead time. Lead time rozumiem jako czas, jaki upływa między wyartykułowaniem potrzeby przez klienta / użytkownika, a momentem, gdy może korzystać z rozwiązania / funkcji.

Od kiedy GPT, a potem Gemini, a jeszcze później Claude zaczęły być wykorzystywane przeze mnie do wsparcia pisania kodu, zacząłem zauważać ciekawą korelację. Im lepszy był model, tym więcej go wykorzystywałem, tym więcej odpowiedzialności mu powierzałem, a w efekcie moja rola stopniowo przesuwała się w kierunku analityka wymagań i architekta.

Wraz z tym zjawiskiem coraz bardziej przyśpieszały moje cykle dostarczania. Gdy byłem na etapie, w którym LLM uzupełniał pisane przeze mnie linijki kodu o kilkanaście znaków, które ja następnie musiałem tylko zatwierdzić. Miałem subiektywne poczucie, że dynamika mojej pracy wzrosła o 20%. Byłem zachwyconą tą funkcją, bo wreszcie miałem odpowiednik korekty ortograficznej tylko, że dla programowania.

To wszystko zwiększyło apetyt użytkowników, którzy widząc, że można szybko spełnić ich oczekiwania i koszt nie jest problemem, przestali się samoograniczać.

Minęło kilka miesięcy i modele językowe rozwinęły się. W trakcie pisania LLM proponował już nie kilkanaście linii kodu, tylko całe funkcje jedynie na podstawie nagłówka. W konsekwencji to LLM zaczął nazywać funkcje i zmienne. Z czasem również komentował kod. Miałem poczucie wzrostu produktywności o kolejne kilkanaście punktów procentowych.

Po ponad roku takiej pracy nowe podejście do tworzenia kodu wjechało na rynek za pośrednictwem Lovable, Replit i innych tego typu platform. Nazwano je vibe coding. W tym modelu współpracy człowiek już nie koduje tylko opowiada, co chciałbym, aby system robił. Teoretycznie nie trzeba się znać na technologii, aby tworzyć technologię. Osobiście tak skrajne odcięcie się od kodu było dla mnie trudne do zaakceptowania. Jednak chciałbym mieć możliwość zajrzenia do środka, wyboru środowiska, czy przeniesienia mojej aplikacji w inne miejsce, gdy najdzie mnie ochota.

Jednak kilka miesięcy później w edytorze VS Code w wydaniu Cursor pojawiła się najpierw możliwość uruchomienia agentów, którzy pracują na moich plikach. A niedługo później interfejs użytkownika przebudowano w ten sposób, że powitalnym ekranem jest ekran prompta, a dopiero muszę kliknąć niewielki guzi w rogu ekranu, aby zobaczyć mój kod. Przypadek, nie sądzę, raczej zaplanowana przez Cursor strategia zmiany sposobu tworzenia oprogramowania.

Z osobistych względów obraziłem się na Cursor, ale nadal korzystam z Claude. I w tym momencie pisanie kodu zaczęło wyglądać tak, że mam otwartych od jednego do siedmiu ekranów, w których rozmawiam z równolegle pracującymi agentami. Dbam o to, aby system był zbiorem w miarę niezależnych komponentów i aby agenci nie edytowali tych samych plików naraz. Ostatnio radzą sobie z tym lepiej, ale i tak jest to niepotrzebne przepalanie tokenów, gdy kilka konkurencyjnych edycji ściga się. Moja produktywność wzrosła o około 100-200 punktów procentowych.

I kilka miesięcy, na wiosnę 2026, temu odnalazłem Spec-Driven Development. Dzisiaj istnieje kilkanaście podejść do tworzenia oprogramowania w nurcie SDD, moje ulubione nazywa się SpecKit, ale i tak je zmodyfikowałem pod własne preferencje. Co więcej sam Claude zaczął jest stosować udostępniając zestaw skilli w ramach czatu oraz tworząc plik CLAUDE.md w ramach repozytorium. Pierwszą rzeczą, którą tworzę przy nowym rozwiązaniu to opisanie intencji strategicznych i wymagań dotyczących architektury i środowiska. Następnie tworzę plik konstytucji CONSTITUTION.md, w którym opisuję standardowe wymagania odnośnie każdego komponentu i funkcji, np., że ma być wielojęzyczny, wspierać WCAG, z resztą poniżej zamieszczam jego fragment.

Efekt - przyśpieszenie pisania kodu o kolejne 100-200 punktów procentowych. Takie jest moje subiektywne poczucie. Dzisiaj mam tempo przykładowo tworzenia do dwóch gier szkoleniowych dziennie, kiedy wcześniej jedna gra mogła zająć nawet miesiąc pracy popołudniami.

Przy trudniejszych i większych komponentach, albo bardziej przekrojowych zmianach, zanim model zacznie pracować, żądam przygotowania planu technicznego zmiany. Wtedy przy okazji wychodzi trochę pytań o to, jak podejść do tworzenia. Poniżej przykład takiego planu.

Po kolejnych krokach ewolucji w pisaniu kodu trwających 3 lata, oprócz poczucia euforii jaki to nagle stałem się genialny, dostrzegłem jeszcze jedno zjawisko, które z tego wynika. Dramatyczne skrócenie lead time. Mam kilka sytuacji z ostatniego miesiąca, gdy użytkownik pytał mnie, czy jest coś możliwe w systemie. Nie było tego, ale zamiast mu o tym mówić, po prostu stworzyłem taką funkcję i ją wypuściłem. Mój rekord między otrzymaniem zgłoszenia nowej funkcji, a dostarczeniem jej na produkcję to 20 minut. MINUT!

Oczywiście zdaję sobie sprawę, że jestem jednoosobowym zespołem, że nie tworzę aplikacji krytycznych i że są to małe systemy. Ale jednak, z miesiąca do 20 minut. Dzisiaj dzięki krótkiemu czasowi dostarczania nie ma problemu, aby robić wydania pięć razy dziennie. W czasie, gdy piszę ten artykuł na własnym edytorze tekstu (polecam Wiki na https://verbalu.com/narzedzia/baza-wiedzy) wdrożyłem 3 usprawnienia do tegoż edytora, bo przeszkadzało mi kilka rzeczy, i zaprojektowałem nową funkcję rysowania diagramów w tekście (jak skończę pisać, to ją przetestuję).

I tu dochodzimy do hipotezy rzuconej na początku artykułu. Wzrost produktywności produkcji oprogramowania prowadzi do mały, częstych (co godzinę nawet) release'ów, bo celem jest maksymalne skrócenie lead time. I moim zdaniem w przyśpieszającym świecie możliwość szybkiego otrzymania narzędzia jest tym, za co biznes zapłaci.

Moja teza jest taka, że wzrost jakości LLM jest negatywnie skorelowany z lead time dostarczania funkcji do użytkowników systemów IT. Czyli im lepsze modele, tym szybciej klienci dostają to, czego potrzebują. I za to będą chcieli płacić. To oznacza, że to klienci wymuszą swoimi pieniędzmi przejście na kodowanie z AI i aktualne protesty oraz krytyka pod adresem vibe coding i pokrewnych metod wraz ze wzrostem jakości modeli straci na znaczeniu.

Jeżeli zejść jeszcze niżej, to da się zauważyć mocne rozwarstwienie lead time między pierwszym działającym prototypem (taki MVP lub PoC), a dopieszczeniem rozwiązania. PoC mogę mieć w 1-2 godziny. Wczoraj kolega rzucił mi hasło stworzenia narzędzia do trenowania trudnych rozmów na bazie AI, po dwóch godzinach miałem prototyp i mogłem ocenić, czy to może mieć sens. Po dniu MVP wylądowało na Verbalu. Natomiast dopieszczanie rozwiązania zajmuje czas. Tu nadal trzeba zacząć pracować z modułem, aby ocenić, czego naprawdę brakuje, aby się w nim zakochać. Tu widzę, że i po miesiącach od wypuszczenia ciągle pojawiają się pomysły na nowe funkcjonalności. Szczególnie, gdy z modułu zaczynają korzystać nowi użytkownicy. Więc czas rozwoju systemu pewnie się nie zmieni, ale czas dostarczenia pierwszej wartości i kolejnych w odpowiedzi na nowe potrzeby już tak. I to rewolucyjnie.

Komentarz do metaforycznego przedstawienia lead time względem cyklu życia projektów agile i SDD. W SDD szybciej klient uzyskuje dostęp do pierwszej funkcjonalności niż w przypadku agile. W przypadku zgłoszenia na starcie w backlogu dużej paczki wymagań, nawet w SDD klient będzie musiał poczekać, ale wąskie gardła produktywności są ulokowane gdzie indziej. Jest nim zdolność do wielozadaniowości członków małego zespołu (konieczność obsługi wielu równoległych agentów) oraz budżet na tokeny. Jednak czas oczekiwania nawet na odległe wymagania zgłoszone na starcie i tak jest krótszy. Co więcej wiedząc, że dany projekt ma duży backlog w dużo większym stopniu możliwe jest skonwertowanie czasu projektu na koszty tokenów i zespołu. Projekty SDD są dużo bardziej kompresowalne za pomocą zainwestowania ekstra pieniędzy niż projekty zwinne, które w większym stopniu zależą od konkretnych ludzi, którymi dysponuje firma.

Wreszcie dalszy rozwój systemu po zakończeniu projektu również za pomocą SDD oferuje krótsze lead time niż w agile, co klienci z pewnością docenią.

To oznacza konieczność wprowadzenia nowych metodyk pracy, bo moim zdaniem scrum jest zbyt sztywny, za mało elastyczny, niepotrzebnie uwzględnia zespoły aż do 10 osób, kiedy wystarczą ekipy po 2-3 osoby, oraz w ogóle nie bierze pod uwagę specyfiki działania agentów AI (równoległości pracy, asynchroniczności, przesunięcia człowieka do roli architekta i analityka wymagań). Zespoły IT w świecie zdominowanym przez AI widzę jako 2-3 analityków z architektem, którzy planują architekturę, wymagania funkcjonalne i niektóre techniczne oraz testy. Resztę robi AI.

Być może za chwilę będziemy świadkami jeszcze jednego przełomu, tym razem adresującego aspekt product discovery. Największym ryzykiem nie jest dzisiaj to, czy można coś dzisiaj tanio wyproduować w IT. Największym ryzykiem jest to, czy ktoś będzie używał naszych funkcji i za nie zapłaci. Wzrost podaży oprócz spadku cena powoduje jeszcze migrowanie rynku aplikacji w kierunku długiego ogona.

Wreszcie na scenę wjeżdża jeszcze jedno zjawisko, które zilustruję osobistym przykładem. Tydzień przed napisaniem tego artykułu pisałem dość długi tekst (na ponad 20 stron). Ten tekst miał wiele odnośników, w których spisywałem uwagi, jednak te uwagi, czasem przeradzały się w osobne wielostronicowe teksty. I koniec końców Google Docs, z którego korzystałem, zaczął mnie wkurzać, bo nie wspierał mojego stylu pracy. Co zrobiłem. W jeden dzień napisałem własny edytor tekstów, nazwałem go Wiki i od kolejnego dnia zacząłem na nim pracować.

Po tygodniu kocham moje Wiki i już nie wrócę do Google Docs. Bo wyróżnia je jedna niezastąpiona rzecz. Jeżeli przyjdzie mi do głowy nowy pomysł, mogę go po prostu zrealizować, czyniąc mój edytor jeszcze wspanialszym (oczywiście z mojej subiektywnej perspektywy). Przykładowo rano w trakcie pisania tego artykułu uświadomiłem sobie, że potrzebuję narysować diagram w ramach tekstu i zamiast wrócić do Google Docs i tam go narysować, równolegle z pisaniem tego felietonu, kodowałem nowy moduł rysowania diagramów na moim ukochanym Wiki. Popołudniu wszystko jest gotowe i możecie zobaczyć gotowe rysunku w tekście

A teraz warto zadać sobie pytanie, co się stanie, gdy duże firmy dojdą do podobnego wniosku. Szczególnie, że ich subskrypcje nie kosztują kilku dolarów miesięcznie, jak Google Docs. Wówczas jedynym blokerem będzie:

  • bezwład organizacyjny,
  • przyzwyczajenie użytkowników,
  • bardzo duża złożoność rozwiązania (np. ERP),
  • regulacje prawne i
  • dostęp do unikalnych danych.

Jeżeli dany software nie spełnia żadnego z powyższych warunków, to organizacja może dojść do wniosku, że po co przepłacać, skoro mogę mieć lepsze rozwiązanie długoterminowo taniej. Strategia polegająca na tak tanim sprzedawaniu subskrypcji, aby nie opłacało się pisać systemu samodzielnie, ma krótkie nogi. Taka strategia eliminuje fundusze na rozwój i marże oraz ściga się ze spadającymi kosztami tokenów.

Podsumowując, stawiam hipotezy, że wraz ze wzrostem znaczenia LLM w tworzeniu oprogramowania pojawią się poniższe zjawiska:

  • Dramatyczny spadek cen ofert na wytworzenie oprogramowania.
  • Skrócenie lead time z tygodni i miesięcy do godzin i dni.
  • Konwertowalność czasu trwania projektu na koszty tokenów.
  • Wzrost insourcingu, przenoszenia rozwiązań z SaaS do wewnętrznych rozwiązań.

AI nie zabije, moim zdaniem, SaaS, bo niektórzy dostawcy mają swoje trudno kopiowalne przewagi. A inni nauczą się spełniać wymagania w tempie godzin i dni a nie tygodni i miesięcy. Ale na pewno odbije się na tym runku mocno.

Wróć do wszystkich artykułów