Mentionsy Mentionsy
Better Dev Club
Better Dev Club

Better Dev Club #39 - Czy SDLC przyspieszyło? O kodowaniu w sekundę, długu i powrocie Waterfall

24.09.2026 ·43 min 59 s · 11 rozdziałów

Czy generowanie kodu z pomocą sztucznej inteligencji faktycznie sprawiło, że zespoły dostarczają oprogramowanie 10x albo 100x szybciej? W tym odcinku bierzemy pod lupę cały cykl wytwarzania oprogramowania (SDLC) i sprawdzamy, co tak naprawdę uległo zmianie. Choć pisanie samego kodu skróciło się niemal do zera, wąskie gardła wcale nie zniknęły – przeniosły się na fazę zbierania wymagań, code review, weryfikację PR-ów, testy akceptacyjne (UAT) oraz rozmowy z klientem. Zamiast armii programistów zmagających się ze sztywnym podziałem na frontend i backend, deweloperzy wreszcie wychodzą ze swoich baniek, zaczynają przeklikiwać własne aplikacje na środowiskach deweloperskich i wyłapują błędy znacznie wcześniej. W drugiej części dyskutujemy o paradoksie Maerska (gdzie wdrożenie pojedynczej zmiany trwało 42 tygodnie, z czego samo kodowanie zaledwie 5 dni) oraz o tym, jak mierzyć efektywność zespołów, by nie wpaść w pułapkę metryk typu liczba linii kodu czy story pointy. Zastanawiamy się również nad prowokacyjną tezą: czy w epoce błyskawicznej generacji kodu hejtowany przez lata Waterfall i precyzyjne zbieranie wymagań z pomocą narzędzi takich jak Figma nie wrócą do łask, a mikroserwisy nie ustąpią miejsca dobrze zaprojektowanym monolitom? Rozdziały: 00:00 Wstęp: Suchar na start i czy jesteś już 100x deweloperem? 01:05 4 filary szybszego dostarczania: Output, Time to Market, mniej błędów i koszty 04:05 Czy da się to zmierzyć? Story pointy, kartki w backlogu i problem mierzalności 06:50 Realny deployment: Software medyczny vs specyfika e-commerce i Allegro 10:54 Jakość a nie jakość: Deweloperzy wreszcie klikają we własny soft i łapią błędy 13:20 Koniec silosów: Front vs Back – deweloperzy wychodzą poza swoje bańki 16:05 Paradoks Maerska: 42 tygodnie na zmianę, z czego tylko 5 dni kodowania 19:10 Prawdziwe wąskie gardła: Zrozumienie raportu, testy z użytkownikami i UX 22:22 Projektowanie od zera: Weryfikacja tożsamości gestem, bezpieczeństwo i on-prem 24:15 Produkt vs Konsulting: Ładowanie na taczkę i presja dowożenia sprintów 25:52 Przesunięcie wąskiego gardła: UAT-y, weryfikacja kodu i czy agent ma sprawdzać agenta? 27:18 Nowy podział ról: Mniej devów, więcej QA i analityków? 28:18 Mierzenie efektywności: Jak mierzyć postęp i pułapki metryk (Dostajesz to, co mierzysz) 31:57 Czy Waterfall wraca? Tydzień zamiast roku – renesans dokładnej analizy wymagań 34:39 Figma i nowoczesne narzędzia: Mockupy zamiast Painta i czy jeden prompt wystarczy dla banku? 38:10 Zmierzch mikroserwisów? Powrót do monolitu, gdy jeden zespół i agenci ogarniają całość 40:54 Nowa rola inżyniera: Nie bądź zombie patrzącym w licznik tokenów 42:14 Metafora taczki: Czas na myślenie i rozwiązywanie realnych problemów biznesowych 44:06 Zakończenie: Poszukiwany designer na kolejny odcinek i podsumowanie#betterdevclub #sdlc #programowanie #ai #coding #agile #waterfall #qa #codereview #figma #mikroserwisy #monolit #dora #developer

3:28 · Mierzenie efektywności 1

Zestaw wymagania, nie wiem jak jest u Ciebie w pracy, ale u nas nie ma presji tego, żeby codziennie pojawił się nowy przycisk w apce. W sensie po prostu nikt z biznesu, ani nikt z klientów, a może to tak, nikt z klientów chyba tego nie oczekuje. Więc to jest kolejna metryka, z której chyba ciężko by było się zmierzyć. Jak gadam z różnymi kolegami, no to u nich jest dość podobnie. Wiadomo, są takie firmy, zresztą sam pracowałem kiedyś w Allegro, no to tam się relisów było tyle w ciągu dnia, ile trzeba było. Jak było trzeba pięć, to było pięć, jak było jeden, to był jeden. Ale dzień bez relisów, co się nie zdarza, przynajmniej średnio dzień bez relisu się nie zdarza.

10:19 · Zmiany w zespole 2

To znaczy back-end developer Bardzo często dostarcza kod, dostarcza kontrakt API na przykład i dostarcza jakąś tam wartość, jakąś tam logikę, na którą się umówili na samym początku z frontendowcem. I to na etapie gdzieś tam wstępnych, teoretycznych rozmów, to się sprawdza. Ale potem, jak już zaczynamy klikać po tym froncie, to się okazuje, że to można by było zoptymalizować, to można by było przenieść jednak do innego requestu i załadować jakoś tam leniwie, to zrobić inaczej, to zrobić inaczej, to zrobić inaczej. No i nagle zaczyna się okazywać, że teraz backend deweloperzy, jak zaczynają klikać realnie w ten frontend zdeployowany na środowisku deweloperskim, zaczynają sami myśleć o takich rzeczach, co się jeszcze nie tak dawno w ogóle nie zdarzało.

Przynajmniej u mnie, w moim zespole, błędów, które zgłaszają QA'e jest dużo mniej niż było. W związku z tym realnie wartość, jakby sama wartość produktu rośnie, bo czas na jakieś tam łaty, właśnie na jakieś elementy związane z QA'em są skrócone. Czy to jest dobra wiadomość dla deweloperów? Ciężko powiedzieć tak naprawdę, no bo właśnie, bo znowu trochę się nie pisaliśmy na to, żeby być QA-ami, takimi pierwszymi, taką pierwszą linią obrony, bo wszyscy myśleliśmy o tym, że jesteśmy pasjonatami, którzy uwielbiają pisać kod.

31:28 · Zakłócenia i Waterfall 1

O kodowaniu w sekundę, długu i powrocie Waterfall. Nie wiem, nie jestem do tego wszystkiego przekonany. To znaczy, do tego, co powiedziałeś na temat mikroserwisów, jakby ja też ani nigdy nie rozumiałem do końca, dlaczego oddzielny zespół musi się za każdy mikroserwis brać, bo potem... Nie, nie, nie, w drugą stronę. Ja wiem, no rozumiem.

Pokazano wszystkie 4 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.