AI przyspieszyło kodowanie. Gdzie zatem są prawdziwe ograniczenia w tworzeniu oprogramowania?

Firmy wdrażają AI do kodowania i liczą na pięciokrotne przyspieszenie. Potem płacą dziesiątki tysięcy dolarów miesięcznie za tokeny, a tempo dostarczania wygląda jak wcześniej. Albo gorzej.

Po dwóch latach pracy z AI w Pragmatic Coders widzimy coś innego: samo kodowanie przyspieszyło wielokrotnie i już rzadko hamuje nas samo delivery. Częściej robią to wymagania, feedback z biznesu, UX, decyzje i jakość procesu.

Jak zmienił się paradygmat wytwarzania oprogramowania

Przez ostatnie dekady ograniczenie w wytwarzaniu oprogramowania zmieniało się co erę. W latach 60. była to moc obliczeniowa. W latach 80. i 90. dystrybucja i koszt poprawek. Potem internet zainicjował Continuous Delivery, a ograniczeniem stało się tempo kodowania. Odpowiedzią były metody zwinne, code review, clean code, TDD.

AI zmieniło ten układ. Samo kodowanie przyspieszyło wielokrotnie. Tworzenie oprogramowania, rozumiane jako budowanie produktu, przyspiesza mniej niż samo kodowanie, gdyż poza samym tworzeniem kodu reszta systemu pracy nie nadąża. I właśnie tu firmy najczęściej się mylą. Słyszą „pięć razy szybciej”, dokładają narzędzia, patrzą na metryki i widzą to samo tempo co wcześniej. Zespół nadal dostarcza podobnie wolno. Tokeny jednak lecą.

Problem nie polega na tym, że AI „nie działa”. Rzecz w tym, że wrzuca się wszystko do jednego worka. Praca z greenfieldem, praca z legacy i przepisanie działającego systemu to trzy różne gry, i w każdej AI daje inną wartość.

Dlaczego AI w kodowaniu nie zawsze przyspiesza delivery

Największą wartość AI daje w greenfieldzie, mniejszą w klasycznym legacy, a przepisanie działającego systemu bywa dziś szybsze niż dalsze łatanie starego kodu – takie są wnioski z naszej praktyki.

Greenfield: gdzie AI w kodowaniu daje największy efekt

W projektach pisanych od zera AI, użyte dobrze, potrafi generować kod porównywalny ze statystycznym programistą. „Użyte dobrze” nie znaczy jednego prompta typu „wypuść mi aplikację”, tylko bardziej rozbudowaną pracę ze specyfikacją, architekturą i kontekstem.

Tu wchodzą dwa podejścia, o których warto mówić wprost. Spec Driven Development to praca, w której najpierw powstaje precyzyjna specyfikacja, a dopiero potem kod. AI-first architecture idzie dalej: zakłada mocniejszą dekompozycję, mniejsze moduły, czystsze granice kontekstów biznesowych. Architektura budowana pod utrzymanie przez ludzi przez ostatnie 20 lat niekoniecznie jest architekturą, w której AI pracuje najlepiej. AI lubi małe, dobrze odseparowane kawałki pracy i aktualny kontekst.

Legacy: dlaczego AI często nie przyspiesza pracy

W dużych, splątanych systemach AI nie daje takiego przyspieszenia jak w greenfieldzie. I to tłumaczy większość rozczarowań w średnich i dużych firmach. Programiści „używają AI”, firma płaci za tokeny, a throughput utrzymuje się na wcześniejszym poziomie. Bo większość pracy to właśnie legacy: dużo zależności, słabe testy, rozmyta wiedza o systemie.

AI może pomagać w refaktoringu, dokumentacji, utrzymaniu bazy wiedzy i żmudnej automatyzacji. Może też dać programistom więcej czasu na zrozumienie kodu. Ale magicznie nie „rozpląta” systemu, z którym ludzie sami radzą sobie słabo od lat. Praca z legacy nadal polega na zmniejszaniu złożoności. AI jest tu wsparciem, nie zamiennikiem myślenia architektonicznego.

Przepisanie legacy z AI: kiedy rewrite wraca do gry

Dwa lata temu pomysł przepisania średniej lub dużej aplikacji od zera wyglądał jak klasyka złych decyzji. Kent Beck, Uncle Bob, Martin Fowler i cała półka książek mówiły: nie rób tego. Ryzyko było ogromne.

Dziś to się zmienia. Przy Spec Driven Development, AI-first architecture i istniejącej wiedzy o produkcie da się odtworzyć system szybciej niż rozwijać go w starym kształcie.

I tu pojawia się niewygodne pytanie: czy dalej warto głównie rozmawiać o AI w legacy, czy raczej o tym, które złożone systemy da się sensownie przepisać jako nowy greenfield?

Case study: przepisanie Pragmatic Meet z AI w 8 tygodni

Pragmatic Meet to aplikacja służąca do organizowania wydarzeń i zrzeszania grup wokół nich. To system, z którego realnie korzystają organizatorzy meetupów. Przepisanie go zajęło około ośmiu tygodni do wejścia na produkcję z około 70% funkcjonalności starego systemu.

Stara wersja powstała na mocno zmodyfikowanym open source (Mobilizon). Zespół rozwijał ją ponad rok… aż natrafił na ścianę. Zbudowanie jednego feature’u, ankiety przed wydarzeniem z imieniem i nazwiskiem pod recepcję, zajęło mu sześć albo siedem tygodni (sic!). Nadal wyglądał źle i nie działał dokładnie tak, jak trzeba. W tym samym czasie inne zespoły w firmie, pracujące Spec Driven Development na greenfieldzie, dowoziły wartość w zupełnie innym tempie.

Padł pomysł: przepisać. Od zera technicznie, ale z twardą wiedzą produktową. Aplikacja miała użytkowników, feedback i jasny zakres tego, co musi działać, więc dokładnie wiedzieliśmy czego chcemy.

Efekt zmierzono Monthly Delivery Rate. To metryka prosta i brutalna: sumaryczny czas zespołu (Product Owner, DevOps, UX, programiści) dzielony przez liczbę dowiezionych historyjek w miesiącu. Przed rewrite’em średnio wychodziło około 60 roboczogodzin zespołu na jedną historyjkę. Po starcie przepisywania, w lipcu, było już poniżej 20. Ponad trzykrotne przyspieszenie. I to przy pracy, która wcześniej też korzystała z AI, tylko na legacy.

Na webinarze zespół pokazał coś jeszcze mocniejszego: od wymagania do działającej funkcjonalności w aplikacji minęła niecała godzina. Następnego dnia ta funkcjonalność miała trafić na produkcję. To nie znaczy, że każdy feature zawsze powstaje w godzinę. Jednak, przy dobrej specyfikacji, agentach, skillach i architekturze pętla „wymaganie → kod → działająca rzecz” skurczyła się do skali, której dwa lata temu prawie nikt nie brał na poważnie.

• Jeśli macie własny system legacy i zastanawiacie się, czy da się go przepisać w podobnym modelu, robimy to jako kontrolowany eksperyment: analiza systemu, potem rewrite w sześciu tygodniowych iteracjach. Po 6 sprintach oceniacie jakość kodu i tempo. Jeśli efekt nie jest adekwatny do kosztu, rozstajemy się. Ryzyko startu bierzemy na siebie. Umów rozmowę o przepisaniu legacy.

Im szybciej kodujesz, tym droższe stają się złe założenia

Szybsze dostarczanie czyni błędy droższymi, bo w tym samym czasie powstaje więcej rzeczy do ewentualnego odkręcenia. To jest kontrintuicyjne i dlatego firmy wpadają w pułapkę.

Stare myślenie brzmi tak: AI pozwala szybciej budować, więc szybciej się uczymy, więc błędy są tańsze. W czasie zegarowym pętla faktycznie bywa krótsza. Ale jeśli mierzysz ilością dowiezionych historyjek, obraz się odwraca. Kiedyś w dwa tygodnie robiłeś trzy historyjki. Dziś możesz zrobić trzydzieści. Jeśli założenie produktowe było złe, odkręcasz nie trzy rzeczy. Odkręcasz trzydzieści.

Do tego dochodzi koszt utraconych korzyści. Te dwa tygodnie to nie tylko cofnięcie złej ścieżki, ale też trzydzieści historyjek, których nie zrobiłeś z powodu tej złej decyzji. Im większe przyspieszenie, tym bardziej boli cofnięcie się o sprint albo dwa.

Dlatego praktyki zwinne nie umierają w erze AI. Stają się bardziej potrzebne – żeby wcześniej łapać błędne założenia o produkcie. Jeśli zespół pędzi jak szalony i nie czeka na pętle zwrotne, złożoność niepotrzebnych funkcji rośnie razy przyspieszenie razy czas. Potem ból jest większy niż kiedykolwiek.

Nowe bottlenecki w delivery z AI: biznes, UX, decyzje, proces

Gdy AI przyspiesza kodowanie, wąskim gardłem stają się feedback biznesu, badania UX, compliance, DevOps poza zespołem i jakość decyzji. Kod przestaje być najwolniejszym elementem łańcucha.

Feedback biznesu jako bottleneck przy AI delivery

W Pragmatic Meet zespół przez chwilę wysyłał codziennie listę dowiezionych historyjek z prośbą o feedback. Sponsor projektu odpowiadał co około dziesięć dni. Nie złośliwie – prostu nie nadążał; feedback biznesu stał się bottleneckiem.

Rozwiązaniem nie było „jeszcze szybciej kodować”, tylko zmiana rytmu odbioru pracy:

• review w tygodniowym sprincie
• dokument z opisem zmian dzień wcześniej
• czas na przeklikanie i notatki. Na samym spotkaniu rozmowa o decyzjach, nie trzygodzinne demo wszystkiego, co powstało.

Refinement i wymagania w erze AI coding

Product Owner nie jest w stanie sam „produkować wymagań” w tym tempie. I nie powinien. W Scrumie Product Owner podejmuje decyzje. Wymagania powstają blisko biznesu, wspólnie z zespołem. Przy pracy z AI refinement przestaje być zapomnianym rytuałem, ale staje się rdzeniem sprintu.

W praktyce zespoły poświęcają na to co najmniej 20% czasu, a bywa że więcej. Powód ku temu jest prosty: jeśli development dowozi zapas na bieżący i następny sprint, a refinement stoi, cały system się zacina.

UX, compliance i DevOps jako ograniczenia AI delivery

Badania jakościowe nie dzieją się w tygodniowym sprincie na zawołanie. Wywiady trwają, a baza respondentów bywa wąska. Walidacja hipotez na produkcji też zajmuje czas, zwłaszcza przy mniejszej liczbie użytkowników. Możesz dowieźć piętnaście historyjek w tydzień i dopiero po dwóch miesiącach mieć powtarzalny sygnał, czy feature naprawdę działa.

Do tego dochodzą rzeczy, które wcześniej „jakoś się działy”. Regulamin blokujący deployment. Prawnik, na którego czeka się tygodniami. DevOps poza zespołem z odpowiedzią „wrzuć na backlog”. Decyzja strategiczna, której nikt nie chce podjąć, bo koszt odwrócenia jest wysoki. W erze AI ten koszt widać ostrzej. Niekoniecznie w pensjach programistów, ale w tym, ile innych rzeczy mogliście zrobić w tym samym czasie. I w tym, że konkurencja nie czeka.

Chaos procesowy i kompetencje przy wdrażaniu AI

Zespoły, które wcześniej pracowały chaotycznie, dziś płacą za to więcej. AI nie naprawia braku Definition of Done, Definition of Ready, testów ani odpowiedzialności za architekturę, ale automatyzuje tempo. Jeśli proces był słaby, dostajesz szybszy… chaos.

Brak kompetencji też drożeje. Błędna decyzja architektoniczna przy wysokim tempie generowania kodu zostawia po sobie większy ślad. Tak samo brak strategii, decyzyjności i odpowiedzialności. Procesy decyzyjne, które ciągną się tygodniami, stają się twardym ograniczeniem delivery.

AI a Agile: dlaczego praktyki zwinne są jeszcze bardziej potrzebne

Nie da się sensownie robić projektu z AI bez praktyk zwinnych. Nie musi to być Scrum ani Kanban z podręcznika. Muszą być za to krótkie pętle zwrotne, jasne kryteria akceptacji, testy, CI/CD i bliskość biznesu.

W Pragmatic Coders część zespołów zeszła z dwutygodniowych iteracji na tygodniowe sprinty. Powód był prosty: po dwóch tygodniach zmian było tyle, że review rozciągało do kilku godzin i traciło sens. W tygodniu da się zamknąć review w około 45-60 minut, jeśli interesariusze dostaną listę zmian wcześniej.

Pojawiła się też codzienna wspólna praca pod koniec dnia: szybkie testowanie tego, co powstało dziś, natychmiastowe poprawki, codzienna nowa wersja. Feedback nie raz na sprint, ale wielokrotnie w ciągu dnia.

AI wymusza rzeczy, które branża deklarowała od lat. Testy automatyczne, najlepiej też wyższego poziomu, nie tylko jednostkowe. Aktualną dokumentację. Przemyślaną architekturę. Rozmowę programistów z biznesem. Continuous Delivery przestaje być „fajną praktyką na potem”- bez niej to tempo po prostu nie działa.

Jest w tym pewien paradoks historyczny. Agile powstawał jako ruch inżynierów szukających lepszych sposobów dostarczania wartości. Potem obudował się rolami, ceremoniami i transformacjami. Dziś AI znowu spycha ciężar na praktyki inżynierskie i bliskość produktu – bo bez tego budowanie produktów z AI po prostu nie działa.

Jak zmienia się rola programisty przy AI w kodowaniu

Programista w tym modelu mniej klepie kod linijka po linijce, a więcej pilnuje wymagań, architektury i weryfikacji.

W greenfieldzie przy dobrych testach i jarzmie architektonicznym klasyczne code review całego kodu bywa mniej krytyczne niż review kompletności testów. W systemach bankowych, tradingowych albo wszędzie tam, gdzie w grę wchodzi bezpieczeństwo, dane i pieniądze, review zostaje ostre. W legacy też. Bo AI średnio radzi sobie z dużą złożonością i couplingiem. Programista nadal musi świadomie zdecydować, czy propozycja modelu nie rozwali systemu.

Zmienia się za to środek ciężkości. Mniej czasu developerzy spędzają w samym kodzie, a więcej w założeniach, granicach modułów, jakości testów i decyzjach, których odwrócenie będzie drogie. To nadal praca inżynierska, tylko inna.

Jak wdrożyć AI w wytwarzaniu oprogramowania bez przepalania budżetu

Jeśli dziś zaczynasz projekt od zera, nie kopiuj procesu z 2018 roku i nie dokładaj do niego ChatGPT. Zatrzymaj się i zaprojektuj pracę inaczej: od wymagań, przez architekturę i testy, po rytm odbioru po stronie biznesu.

Kilka praktycznych wniosków z tego, jak realnie wygląda praca z AI po dwóch latach doświadczeń:

1. Po pierwsze, rozdziel konteksty i sposoby działania. Greenfield, utrzymanie legacy i rewrite to osobne strategie.
2. Po drugie, mierz delivery, nie samą aktywność z AI. Monthly Delivery Rate, czas od wymagania do produkcji, liczba rzeczy odkręcanych po złych założeniach. Jeśli tokeny rosną, a te liczby stoją, tak naprawdę wcale nie przyśpieszasz.
3. Po trzecie, przygotuj biznes na odbiór pracy. Szybszy development bez szybszego feedbacku tylko przenosi korek na inną stronę stołu. Tygodniowy rytm, wcześniejsza lista zmian i decyzje zamiast wiecznego demo pomagają bardziej niż kolejny plugin do IDE.
4. Po czwarte, nie omijaj podstaw. Testy, CI/CD, Definition of Done, refinement, odpowiedzialność za architekturę. AI bez tego nie zrobi z zespołu nowoczesnej maszyny delivery.
5. Po piąte, traktuj rewrite jako realną opcję, nie tabu. Nie zawsze. Nie wszędzie. Jeśli zespół od tygodni walczy z jedną funkcją w starym systemie, a produkt jest dobrze znany, dziś częściej opłaca się napisać ją od nowa niż dalej łatać legacy.

Zanim dołożycie kolejne licencje albo kolejny plugin do IDE, warto sprawdzić, czy zespół w ogóle jest gotowy na AI. AI Readiness Checklist to 19 pytań w czterech obszarach: cel biznesowy, fundamenty inżynierskie, sposób pracy z AI i mierzenie efektów. Odpowiedzi tak/nie. Bez ściemy. Po wypełnieniu widać, gdzie AI tylko przyspieszy chaos, a gdzie realnie ma szansę przyspieszyć delivery.

Pobierz AI Readiness Checklist

Wnioski

AI nie uczyniło wytwarzania oprogramowania magicznie tanim i bezproblemowym. Sprawiło, że kodowanie jest szybsze, przez co odsłoniło kolejne ograniczenia: jakość wymagań, tempo feedbacku, UX, compliance, decyzje i dojrzałość procesu.

Firmy, które kupują AI jako magiczną obietnicę działania „pięć razy szybciej”, często dostają ten sam chaos, powiedzmy, “w wyższej rozdzielczości”. Firmy, które przebudowują sposób pracy wokół specyfikacji, architektury, testów i krótkich pętli zwrotnych, zaczynają widzieć realne przyspieszenie. Czasem trzykrotne, a czasem wręcz takie, że bottleneckem nagle staje się biznes.

I to jest właściwy punkt startu na 2026. Nie pytaj, czy używać AI, ale „gdzie dziś jest nasze prawdziwe ograniczenie, gdy kodowanie przestaje nim być”.

Po więcej na ten temat obejrzyj: