- Jak wygląda wytwarzanie oprogramowania z agentami AI w praktyce? Proces eVolpe krok po kroku - 22 października 2026
- Ile naprawdę oszczędza AI w developmencie? Jak uczciwie liczyć czas i koszt - 20 października 2026
- Czy agent AI może sam testować kod? Co automatyzujemy w testach, a co zostaje dla testera - 19 października 2026
W eVolpe wytwarzanie oprogramowania z agentami AI wygląda tak: agent AI planuje zadanie, pisze kod, generuje testy, sam sprawdza wynik i przygotowuje raport z code review, a orkiestrator pilnuje kolejności kroków. Człowiek zatwierdza plan, weryfikuje efekt i decyduje o poprawkach w stałych bramkach kontrolnych. Proces działa w projektach na SuiteCRM i MintHCM. Opisujemy go krok po kroku, z liczbami z jednego zadania i z ograniczeniami, które widzimy.
W skrócie:
Czym różni się praca z agentami AI od pracy z asystentem kodu?
Praca z agentami AI różni się od pracy z asystentem kodu tym, że agent wykonuje cały łańcuch kroków, od planu po weryfikację, a nie tylko podpowiada fragmenty kodu. W eVolpe to przejście trwało kilka miesięcy. W czerwcu 2026 r. zespół miał już skille, czyli zapisane procedury, według których agent wykonuje dany etap pracy: implementację, sprawdzenie kodu, generowanie scenariuszy testowych i code review. Każdy skill uruchamiał jednak ręcznie człowiek.
Taki model miał trzy słabości. Każde przejście między etapami wymagało człowieka, więc nie było wiadomo, ile trwa który krok. Testy funkcjonalne wykonywał ręcznie tester, a self code review uruchamiane przez dewelopera wyłapywało niewiele, bo błędy wychodziły dopiero w raporcie recenzenta. Najpoważniejszy problem polegał na tym, że po implementacji nie było dowodu działania kodu. „Po implementacji nie mieliśmy dowodu, że kod działa, tylko deklarację” – mówi Michał Nowacki z zespołu wytwarzania oprogramowania eVolpe. Deweloper otwierał przeglądarkę i opisywał agentowi każdy błąd po kolei.
| Obszar | Czerwiec 2026 | Obecny proces |
| Uruchamianie kolejnych kroków | Ręcznie, przez człowieka | Orkiestrator po podaniu numeru zagadnienia |
| Dowód, że kod działa | Deklaracja agenta | Testy jednostkowe i przeglądarkowe uruchamiane przez agenta |
| Testy funkcjonalne | Ręcznie, przez testera | Automatyczne na podstawie scenariuszy; tester weryfikuje i uzupełnia |
| Code review | Skill uruchamiany ręcznie | Automatyczny raport na osobnych serwerach; decyzję podejmuje recenzent |
| Decyzje podjęte w trakcie zadania | Często tylko w komunikatorze | Agent dopisuje je do user story w Redmine |
| Ślad przebiegu pracy | Historia sesji | Artefakty z każdego etapu |
Różnicę między pracą ad hoc z modelem językowym a procesem agentowym opisujemy szerzej w artykule Vibe coding vs Agentic Engineering — dwa paradygmaty pracy z AI.
Jak wygląda proces wytwarzania oprogramowania z agentami AI w eVolpe krok po kroku?
Proces eVolpe składa się z dziesięciu kroków: zaczyna się od kompletnego user story, a kończy instalacją kodu na środowisku testowym. Całość koordynuje orkiestrator, czyli skill, który sam nie wykonuje pracy merytorycznej, ale pilnuje, żeby kroki następowały w ustalonej kolejności i żeby człowiek uczestniczył w kluczowych decyzjach. Agent AI w tym procesie korzysta z modelu Claude, a zadania i decyzje są śledzone w Redmine.
- Deweloper uruchamia orkiestrator z numerem zagadnienia. Wejściem jest kompletne user story w Redmine, przygotowane wcześniej przez analityka. Agent zmienia status zagadnienia na „w toku”, żeby nikt nie zaczął równolegle tej samej pracy, i sprawdza, czy ma środowisko do uruchomienia testów.
- Agent analizuje user story i kod źródłowy, a potem przygotowuje plan z pytaniami. Plan określa, co i gdzie trzeba zmienić. Pytania dotyczą luk w user story i decyzji biznesowych, których agent nie powinien podejmować sam.
- Bramka 1: człowiek zatwierdza lub koryguje plan. Deweloper odpowiada na pytania, dodaje wiedzę, której nie ma w user story, i zawraca agenta, jeśli ten obrał zły kierunek, na przykład gdy zmiana naruszyłaby dwa istniejące procesy w systemie.
- Agent aktualizuje user story w Redmine. Decyzje z etapu planowania trafiają do opisu zagadnienia, więc dokumentacja odpowiada temu, co faktycznie powstanie.
- Agent generuje plan testów na podstawie user story. Tester przegląda scenariusze i dopisuje przypadki, o których agent nie pomyślał. Równolegle startuje implementacja.
- Agent implementuje zmianę zgodnie z zatwierdzonym planem.
- Agent sam weryfikuje kod. Niezależny subagent wykonuje self code review według standardów eVolpe, na przykład sprawdza, czy nowe pole jest objęte audytem. Powstają testy jednostkowe, a na podstawie scenariuszy także testy przeglądarkowe. Jeśli coś nie działa, agent poprawia kod i powtarza pętlę, maksymalnie trzy razy.
- Bramka 2: deweloper sprawdza wynik w przeglądarce, zanim zmiana zostanie zatwierdzona w repozytorium.
- Automatyczny code review i bramka 3. Na osobnych serwerach uruchamia się skill code review, który tworzy raport, a zespół dostaje powiadomienie w komunikatorze. Recenzent konfrontuje raport z kodem. Potwierdzone błędy trafiają do Redmine, deweloper je weryfikuje, a agent poprawia je w pętli.
- Bramka 4: tester sprawdza pokrycie testami i podpisuje się pod wynikiem. Po akceptacji kod trafia do gałęzi develop, a pipeline CI/CD instaluje go na środowisku testowym, gdzie analityk i tester mogą sprawdzić zmianę.
| Etap | Co robi agent AI | Co robi człowiek | Artefakt |
| Planowanie | Analizuje user story i kod, zadaje pytania | Odpowiada, koryguje, zatwierdza plan | Plan implementacji |
| Scenariusze testów | Generuje przypadki testowe z user story | Tester uzupełnia brakujące przypadki | Plan testów |
| Implementacja i samoweryfikacja | Pisze kod, testy jednostkowe i przeglądarkowe, poprawia w pętli | — | Raport weryfikacji |
| Weryfikacja implementacji | Poprawia zgłoszone uwagi | Deweloper sprawdza wynik w przeglądarce | — |
| Code review | Tworzy raport, poprawia potwierdzone błędy | Recenzent ocenia raport i kod | Raport z code review, zgłoszenia w Redmine |
| Testy akceptacyjne | Poprawia błędy, uruchamia testy zagadnienia | Tester sprawdza pokrycie, testuje ręcznie, akceptuje | Wynik testów |
| Wdrożenie na test | — | Analityk i tester sprawdzają zmianę | Instalacja na środowisku testowym |
Gdzie w procesie jest człowiek i dlaczego nie da się go usunąć?
Człowiek jest w procesie eVolpe w czterech stałych bramkach: przy zatwierdzaniu planu, przy weryfikacji implementacji, przy code review i przy testach akceptacyjnych. Bramki nie są jedynymi punktami kontaktu. Agent może zatrzymać pracę i zadać pytanie w dowolnym momencie, na przykład gdy po code review okazuje się, że zmianę trzeba zrobić zupełnie inaczej, niż zakładał plan. Michał Nowacki podsumowuje to krótko: „W praktyce człowiek trzyma ster”.
Analiza artefaktów z dotychczasowych zadań pokazała, że mniej więcej połowa decyzji podejmowanych przez agenta na etapie planu jest niepoprawna i wymaga korekty człowieka. Traktujemy ten wskaźnik jako miarę tego, gdzie skille wymagają dopracowania. Wraz z ich rozwojem odsetek korekt powinien spadać, ale zatwierdzanie planu przez człowieka zostanie. Zmieni się proporcja: więcej planów będzie akceptowanych bez uwag.
Przykład z praktyki pokazuje, jakie błędy łapie bramka. Podczas prac nad wdrożeniem MintHCM dla klienta agent miał przez MCP (Model Context Protocol) dostęp do wewnętrznej instancji MintHCM eVolpe. Uznał, że skoro oba systemy to MintHCM, może analizować dane w naszej instancji, i zaczął łączyć się z produkcją, która nie miała związku z projektem klienta. Deweloper zatrzymał to działanie. Z perspektywy agenta decyzja była logiczna, ale błędna, a bez człowieka w pętli nikt by jej nie zakwestionował.
Taki układ odpowiada wnioskom z raportu Google DORA „State of AI-assisted Software Development”. Z narzędzi AI korzysta 90% profesjonalistów zajmujących się wytwarzaniem oprogramowania, a efekt wdrożenia AI zależy od systemu pracy zespołu, m.in. kontroli wersji, dyscypliny code review i standardów, a nie od samego narzędzia (DORA, 2025). Bramki w procesie eVolpe są właśnie takim elementem systemu.
Jakie artefakty tworzy agent AI i do czego służą?
Agent AI w procesie eVolpe tworzy cztery główne artefakty: plan implementacji, scenariusze testowe, raport weryfikacji i raport z code review. Plan implementacji zawiera m.in. informację, z jakich elementów systemu skorzystać i w którym miejscu kodu umieścić zmianę. Przy prostych zadaniach, takich jak nowe pola czy zmiana struktury modułu, deweloperowi zwykle wystarcza podsumowanie planu. Scenariusze testowe opisują przypadki do sprawdzenia, a raport z code review jest punktem wyjścia dla recenzenta.
Raport weryfikacji to najważniejszy artefakt z punktu widzenia kontroli jakości. Pokazuje, jakie twarde walidacje agent wykonał, co znalazł w self code review, co uznał za warte poprawy, co poprawił i z czym sobie nie poradził. Zawiera też listę napisanych i uruchomionych testów. Jeśli agent po trzech próbach nie przejdzie testów, przerywa pętlę, a raport mówi, gdzie utknął. Człowiek nie musi odtwarzać tego z historii sesji.
Każdy test wygenerowany lub zmieniony w ramach user story dostaje tag z numerem zagadnienia. Dzięki temu agent przy każdej poprawce uruchamia dokładnie te testy, które dotyczą zadania, także te napisane przed poprawką, żeby sprawdzić, czy nie zepsuł czegoś obok. Selekcja jest konieczna, bo uruchomienie pełnego zestawu testów systemu może trwać godzinami.
Jak proces wygląda na konkretnym zadaniu? Przykład pola NIP
Przykładowe zadanie, na którym Michał Nowacki pokazał proces zespołowi, polegało na dodaniu do modułu kontrahentów pola NIP z walidacją formatu i sumy kontrolnej. Było to user story przygotowane na potrzeby demonstracji, ale przeszło pełny proces, od planu do środowiska testowego.
Na etapie planu agent zadał serię pytań biznesowych. Przy jednym z nich, dotyczącym sytuacji, w której system znajdzie rekord z tym samym numerem NIP, agent założył, że nie doda linku do istniejącego rekordu. Deweloper uznał, że link się przyda, i agent uwzględnił to w planie. W planie pojawiła się też zmiana we frontendzie (własny komponent Angular), której user story nie wymagało. Deweloper ją usunął i zatwierdził skorygowany plan.
Agent wygenerował 16 przypadków testowych. Sprawdzały m.in., czy pole NIP jest widoczne w widoku rekordu i edycji, czy jest polem tekstowym i niewymaganym, czy etykiety zgadzają się w języku polskim i angielskim oraz czy kolumna nie jest domyślnie widoczna na liście. Testy automatyczne pokryły 14 z 16 przypadków. Raport wprost wskazał dwa niesprawdzone obszary: import rekordów kontrahentów oraz polskie etykiety, bo instancja testowa nie miała zainstalowanej polskiej paczki językowej.
W samoweryfikacji agent uruchomił 35 testów, a self code review wykryło jedną nieprawidłowość, którą agent sam poprawił. Po automatycznym code review deweloper zdecydował, że test importu nie jest na tym etapie potrzebny. Agent poprawił pozostałe uwagi i w podsumowaniu zaznaczył, że pominięcie testu importu było świadomą decyzją. Udział dewelopera w samym kodzie był znikomy.
Ile czasu zajmuje zadanie wykonane z agentami AI?
Przy zadaniu z polem NIP cały proces trwał 104 minuty, a czas interakcji dewelopera z agentem wyniósł około 21 minut. Zespół szacuje, że w tradycyjnym trybie to samo zadanie zajęłoby deweloperowi 2–3 godziny, m.in. ze względu na obliczanie sumy kontrolnej i pytania o walidację numerów zagranicznych. Te liczby wymagają jednak czterech zastrzeżeń:
Skrócenia czasu nie da się ekstrapolować liniowo. Największy zysk widzimy przy prostych zadaniach, takich jak nowe pola, zmiany struktury czy nowe moduły, i na nich zespół koncentruje się w bieżącym kwartale. Przy większych mechanizmach i integracjach plan jest obszerniejszy, decyzji i interakcji z agentem jest więcej, więc oszczędność będzie mniejsza.
Ostrożność ma podstawy w badaniach. W randomizowanym badaniu METR 16 doświadczonych programistów open source, rozwiązujących 246 realnych zadań, pracowało z narzędziami AI o 19% dłużej niż bez nich, choć sami oceniali, że pracują szybciej (METR, 2025). Wniosek dla nas: czas trzeba mierzyć na całym procesie i na wielu zadaniach, a nie opierać na odczuciach zespołu.
Jakie są ograniczenia wytwarzania oprogramowania z agentami AI?
Proces eVolpe ma dziś pięć wyraźnych ograniczeń, które bierzemy pod uwagę przy planowaniu prac:
Więcej o ryzykach i granicach podejścia agentowego piszemy w artykule Agentic Engineering — czy jest i dlaczego zmienia sposób budowania oprogramowania?.
Jak proces uczy się na własnych błędach?
Proces eVolpe poprawia się dzięki cyklicznemu audytowi artefaktów. Korekty planów, uwagi z code review i błędy zgłoszone przez testerów są zapisane, więc zespół zebrał je z wielu projektów i przeanalizował pod kątem powtarzających się wzorców. Na tej podstawie wiedział, czego brakuje w skillach i które reguły trzeba do nich dopisać.
Najczęstszy wzorzec dotyczył uprawnień. Skill implementacji dodawał na przykład przycisk akcji na formularzu, ale nie sprawdzał, czy użytkownik ma uprawnienia do jej wykonania. Recenzenci zgłaszali to przez kilka tygodni. Po audycie reguła trafiła do skilla implementacji, a kolejny audyt, za miesiąc lub dwa, pokaże, czy problem zniknął i jakie wzorce pojawiły się w jego miejsce.
Skala zmian w ciągu trzech miesięcy pokazuje tempo rozwoju procesu. Liczba skilli wzrosła z 24 do 35, w skillach przybyło około 40 tys. linii, a z code review opartego na skillach zespół skorzystał w 33 projektach. Każdy z tych projektów dostarcza nowych artefaktów do kolejnego audytu, więc skille są poprawiane na podstawie realnych zgłoszeń, a nie przypuszczeń.
Na jakich systemach działa proces i co dalej?
Proces z orkiestratorem działa w projektach na SuiteCRM 8 i MintHCM, autorskim systemie HR rozwijanym przez eVolpe jako open source. Kolejne w planie są Creatio i SpiceCRM. Rozszerzenie procesu na nowy system wymaga skilli, które opisują agentowi, jak pisać testy i poruszać się po danym systemie, oraz bazowych testów jego standardowych modułów.
W kolejnych projektach zespół będzie mierzył koszt poszczególnych etapów i optymalizował te najdroższe, eliminował najczęstsze błędy wykryte w audytach oraz rozwijał testy przeglądarkowe tak, żeby obejmowały złożone procesy biznesowe. To praca na kolejne miesiące, a nie jednorazowa zmiana. Docelowo chcemy ograniczać liczbę miejsc, w których człowiek musi interweniować, ale tylko tam, gdzie dane z audytów pokażą, że agent radzi sobie stabilnie.
Co to oznacza dla firm, które zlecają rozwój systemu CRM lub HCM?
Dla firmy zlecającej rozwój systemu najważniejszą zmianą jest śledzalność. Decyzje podjęte w trakcie realizacji trafiają do user story, każda zmiana ma scenariusze testowe i raport weryfikacji, a testy przypisane do zagadnienia można uruchomić ponownie przy kolejnych zmianach. To ułatwia odbiór prac i późniejsze utrzymanie systemu, bo wiadomo, co sprawdzono, a czego nie.
Pewne rzeczy się nie zmieniają. Kompletne user story, przygotowane przez analityka we współpracy z klientem, nadal jest warunkiem startu, a odbiór na środowisku testowym nadal należy do ludzi. Szybsza realizacja prostych zadań nie oznacza też proporcjonalnie niższych wycen wszystkich prac, bo zysk zależy od złożoności zadania. Rolę analityka w tym modelu opisujemy w artykule Czy AI zabierze pracę analitykom biznesowym?.
Umów bezpłatną konsultację z ekspertem wdrożeniowym eVolpe
Wybierz dogodny dla siebie termin.
Najczęściej zadawane pytania
Tak. Agent AI implementuje zmianę według planu, który wcześniej zatwierdził człowiek. Deweloper sprawdza wynik w przeglądarce, recenzent ocenia raport z code review, a tester akceptuje wynik testów. Żadna zmiana nie trafia do gałęzi develop bez decyzji człowieka.
Orkiestrator to skill, który koordynuje kolejne kroki procesu: zmianę statusu zagadnienia, plan, scenariusze testowe, implementację, samoweryfikację i przekazanie do code review. Sam nie wykonuje pracy merytorycznej. Pilnuje kolejności kroków i udziału człowieka w bramkach kontrolnych.
Bramki kontrolne to momenty, w których agent zatrzymuje się, a człowiek zatwierdza lub koryguje wynik. W procesie eVolpe są cztery: zatwierdzenie planu, weryfikacja implementacji, code review i testy akceptacyjne. Agent może też zadać pytanie poza bramkami.
Agent AI generuje testy jednostkowe oraz testy przeglądarkowe na podstawie scenariuszy z user story i sam je uruchamia. Jeśli test nie przechodzi, poprawia kod i powtarza pętlę maksymalnie trzy razy. Wynik, w tym niesprawdzone obszary, opisuje w raporcie weryfikacji.
To zależy od złożoności zadania. Przy prostym polu NIP interakcja dewelopera z agentem trwała około 21 minut, wobec szacowanych 2–3 godzin w tradycyjnym trybie. Przy integracjach i złożonych procesach oszczędność jest mniejsza, dlatego mierzymy czas na całym procesie.
Nie. Tester weryfikuje i uzupełnia scenariusze, ręcznie sprawdza przypadki niepokryte testami automatycznymi oraz powiązane starsze procesy. Recenzent ocenia raport z automatycznego code review i decyduje, które uwagi są zasadne. Agent przejmuje powtarzalną część ich pracy.
Proces z orkiestratorem działa w projektach na SuiteCRM 8 i MintHCM. Kolejne w planie są Creatio i SpiceCRM. Każdy nowy system wymaga własnych skilli i bazowych testów modułów, dlatego proces rozszerzamy stopniowo.
Źródła
- Google Cloud, DORA — State of AI-assisted Software Development, 2025.
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, lipiec 2025.
- Jak wygląda wytwarzanie oprogramowania z agentami AI w praktyce? Proces eVolpe krok po kroku - 22 października 2026
- Ile naprawdę oszczędza AI w developmencie? Jak uczciwie liczyć czas i koszt - 20 października 2026
- Czy agent AI może sam testować kod? Co automatyzujemy w testach, a co zostaje dla testera - 19 października 2026
