Budowa oprogramowania w erze AI

AI w wytwarzaniu oprogramowania obiecuje uproszczenie pracy, ale w dużej organizacji łatwo o efekt odwrotny: mnożące się narzędzia, niespójne praktyki zespołów, rosnące koszty i nowe ryzyka dla jakości.

Podczas wystąpienia przyjrzymy się, gdzie AI rzeczywiście pomaga zespołom inżynierskim, a gdzie potrafi skomplikować codzienną pracę, oraz jak wprowadzać ją tak, aby zamiast kolejnej warstwy złożoności przynosiła mierzalne korzyści.

Materiały o agentach programistycznych zwykle pokazują pracę w nowym projekcie: ze świeżym repozytorium, jednym językiem i bez historii zmian. Rzeczywiste środowiska są bardziej złożone. Łączą pojedyncze i współdzielone repozytoria wielu zespołów, różne języki programowania, takie jak TypeScript i Python, warstwy interfejsu użytkownika i logiki serwerowej, testy całościowe E2E oraz infrastrukturę opisaną w Terraformie. Każdy z tych obszarów ma własne konwencje i kryteria ukończenia pracy.

Wdrożenie programowania z wykorzystaniem agentów AI w takim środowisku, określanym jako brownfield, wymaga uwzględnienia także czynnika ludzkiego. Zespoły mogą podchodzić niechętnie do zmian obejmujących niemal wszystkie aspekty ich codziennej pracy.

Zmiana wykracza poza tempo generowania kodu. Obejmuje jego przeglądy, a także planowanie, projektowanie, testowanie i utrzymanie oprogramowania. Pokażę, jak korzystać z narzędzi AI w istniejącym projekcie, aby jak najlepiej wykorzystać podejście ADLC (Agent Development Lifecycle), zachowując jakość tworzonych rozwiązań.

Omówię również procesy i nawyki potrzebne do utrzymywania narzędzi AI wraz z rozwojem oprogramowania. Instrukcje i procedury dla agentów, agenci pomocniczy oraz mechanizmy reagujące na zdarzenia wymagają regularnych przeglądów i aktualizacji.

Jak zmienia się praca zespołu, gdy agenci AI uczestniczą w procesie od doprecyzowania problemu i opracowania projektu technicznego po implementację i weryfikację zmian?

Na przykładzie Booksy pokażę, jak rozwijamy cykl wytwarzania oprogramowania w kierunku modelu AI-native, w którym współpraca z AI jest integralną częścią procesu. Przedstawię, jak dostarczamy agentom kontekst, tworzymy współdzielone instrukcje i procedury oraz środowiska pracy, a także organizujemy współpracę inżynierów z agentami i ekspertami poszczególnych platform. Omówię również zmieniającą się odpowiedzialność inżyniera za całościowy rezultat pracy.

Pokażę, gdzie AI pomaga, gdzie powstają nowe wąskie gardła i jak sprawdzamy, czy agent rzeczywiście wykonał powierzone mu zadanie.

W wielu firmowych projektach AI największą przeszkodą okazuje się jakość i dostępność danych. Pokażemy studium przypadku, w którym migrację dotychczasowej hurtowni potraktowaliśmy jako budowę fundamentu pod rozwiązania AI. Platformę danych tworzyliśmy zgodnie z zasadami inżynierii oprogramowania: z kodem w repozytorium Git, generowaniem na podstawie konfiguracji, testami, bramkami jakości i ciągłą integracją. Współpracujący agenci AI realizowali zadania od pobierania i ładowania danych, przez budowę modelu, testy i dokumentację, po przygotowanie raportu dla biznesu.

Opowiemy, jak dzieliliśmy pracę między agentów i dlaczego każdemu przypisaliśmy recenzenta, którego zadaniem było aktywne wyszukiwanie błędów. Wyjaśnimy, dlaczego wymagamy testów mutacyjnych i dlaczego sam zakaz zapisany w poleceniu dla modelu nie wystarcza. Pokażemy mechanizm oceny wymagający zgodności z poprzednią hurtownią co do grosza i co do wiersza oraz śledzenie pochodzenia danych od kolumny źródłowej do miary w raporcie. Omówimy także nieudane próby i ich koszty.

Przedstawimy wpływ tego podejścia na codzienną pracę zespołu i macierz kompetencji: architekt przygotowuje założenia i bramki jakości, a analityk realizuje całą ścieżkę od źródła danych do raportu. Wyjaśnimy również, dlaczego aplikacje operacyjne korzystające z platformy danych budujemy obecnie samodzielnie, bez zespołu programistów aplikacyjnych.

Wystąpienie poprowadzą Łukasz Lelwic, architekt danych, i Paweł Jędrzejewski z DataRiseLab. Przedstawią liczby, decyzje i wnioski z rzeczywistego wdrożenia, bez treści sprzedażowych.

Gdy mówimy o AI w wytwarzaniu oprogramowania, zwykle myślimy o szybszym pisaniu kodu. Kod jest jednak tylko częścią pracy. Najwięcej zmienia się wtedy, gdy AI wspiera cały zespół: analityka, projektanta UX, testera, właściciela produktu i programistę. To właśnie poza samym programowaniem dostrzegamy największy niewykorzystany potencjał tej technologii.

Pokażemy, jak w praktyce wygląda cykl wytwarzania oprogramowania wspierany przez AI. Oprzemy się przede wszystkim na doświadczeniach z naszego startupu: od czego zaczęliśmy, jak zmienialiśmy proces i jak pracujemy obecnie. Omówimy również, które elementy tego podejścia udało się przenieść do innych organizacji, a które okazały się najtrudniejsze do wdrożenia.

Wyjaśnimy, dlaczego takie podejście wymaga przemyślanego procesu oraz dyscypliny w tworzeniu i utrzymywaniu artefaktów. Bezrefleksyjne korzystanie z AI szybko prowadzi do nadprodukcji opisów, podsumowań i dokumentów. Zamiast usprawniać pracę, materiały te zwiększają szum informacyjny, pochłaniają czas i utrudniają koncentrację.

Pokażemy, jak centralizacja wiedzy wpłynęła na analizę, dokumentację, projektowanie UX, programowanie i testy. Przyjrzymy się także temu, czy klasyczny pull request i przegląd kodu wiersz po wierszu nadal odpowiadają potrzebom zespołów pracujących z AI.

Ocenimy przydatność narzędzi takich jak Spec Kit i podobnych rozwiązań. Uczestnicy dowiedzą się, jak rozpocząć pracę w tym modelu we własnym projekcie, niezależnie od wielkości zespołu i organizacji.

Podczas prezentacji pokażemy, jak agenci i asystenci AI mogą wspierać codzienną pracę projektową i testową: automatyzować powtarzalne zadania, analizować informacje i formułować trafne rekomendacje. Na przykładzie Jiry omówimy możliwości zwiększania efektywności pracy, poprawy przejrzystości procesów i podnoszenia jakości podejmowanych decyzji.

Przekazaliśmy agentowi AI framework testowy, wiedzę domenową, instrukcje i dostęp do repozytorium. Umożliwiliśmy mu samodzielne przygotowanie planu testów oraz napisanie kompletnych testów całościowych E2E. Następnie sprawdziliśmy rezultaty.

Podczas prezentacji omówię eksperyment, którego celem było ustalenie, jak dużą część pracy inżyniera testów można powierzyć agentom AI i czy w praktyce pozwala to zastąpić testera. Początkowe wyniki były obiecujące. Dopiero przy większej skali ujawniła się różnica między umiejętnością generowania testów a zdolnością decydowania, co rzeczywiście warto testować.

Opowiem, które zadania testera AI może przejąć, gdzie nadal potrzebny jest człowiek i jak wraz z rozwojem agentów zmienia się rola inżyniera jakości.

Jak przenieść bezpieczeństwo z końcowego przeglądu bezpośrednio do procesu wytwarzania? Na przykładzie „fail, fix, pass” pokażę, jak pipeline i policy as code egzekwują zasady architektoniczne. W dobie kodu tworzonego z pomocą AI takie automatyczne zabezpieczenia stają się niezbędne, aby szybko rozwijać oprogramowanie bez utraty kontroli nad jego bezpieczeństwem.

Zarządzanie podatnościami systemów wymaga od liderów IT łączenia wymogów bezpieczeństwa z kontrolą kosztów i tempem dostarczania zmian. Na przykładzie rozwiązania opracowanego w Banku Millennium pokażę, jak wykorzystujemy AI do automatyzacji usuwania podatności, aby skrócić czas przygotowania nowych wersji oprogramowania i ograniczyć koszty prac.

Przedstawię doświadczenia z realizacji oraz wnioski dla zespołów, które chcą zwiększać bezpieczeństwo aplikacji i przeznaczać więcej zasobów na rozwój funkcjonalności biznesowych.

W czerwcu 2026 roku Boris Cherny, twórca Claude Code, publicznie stwierdził, że przestał samodzielnie formułować polecenia dla AI: korzysta z pętli, które robią to za niego, a jego praca polega na tworzeniu tych pętli. Sprawdzimy, ile jest w tym prawdy.

Przejdziemy od vibe coding, przez programowanie z wykorzystaniem agentów AI, po autonomiczne pętle, w których środowisko sterujące pracą agentów (harness) rozstrzyga, czy zadanie rzeczywiście zostało ukończone. Przyjrzymy się wzorcowi gauntlet loop: agent wykonujący zadanie nie ocenia własnej pracy, a odrębny krytyk porównuje rezultat z zewnętrznym punktem odniesienia. Następnie omówimy oprogramowanie, które samodzielnie zgłasza propozycje zmian we własnym kodzie.

AI napisze kod, zbuduje aplikację i zaproponuje architekturę. Kto jednak będzie rozumiał, jak działa całe rozwiązanie? Podczas prezentacji przyjrzymy się praktyce tworzenia oprogramowania z AI, jej możliwościom i ograniczeniom.

Pokażę, gdzie AI może istotnie przyspieszyć pracę programisty, a gdzie prowadzić do problemów z jakością, bezpieczeństwem, architekturą i utrzymaniem systemu. Na koniec zastanowimy się, czy przyszłość należy do osób tworzących aplikacje metodą vibe coding, czy do programistów, którzy nauczą się skutecznie współpracować z AI.

Rozwój autonomicznych agentów wspierających programistów zmienia sposób organizacji ich środowiska pracy. Coraz większego znaczenia nabierają wybór środowiska sterującego pracą agentów (harness) oraz dobór modelu do wykonywanych zadań.

Podczas prezentacji omówię najpopularniejsze środowiska tego typu, ich możliwości i sposoby konfiguracji. Przedstawię wiodące modele, różnice między nimi oraz architekturę ich udostępniania i komunikacji ze środowiskiem pracy agentów. Pokażę także aktualne techniki optymalizacji, które przyspieszają działanie modeli w codziennej pracy.

Inżynierowie oprogramowania, architekci i kierownicy projektów dowiedzą się, jak świadomie dobrać i skonfigurować zestaw narzędzi wspierających ich pracę.