- Co zmienia się dla klienta, gdy partner wdrożeniowy pracuje z agentami AI? - 26 października 2026
- 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
Gdy partner wdrożeniowy pracuje z agentami AI w uporządkowanym procesie, klient dostaje trzy rzeczy, których wcześniej często brakowało. Pierwsza to ślad decyzji zapisany w Redmine. Druga to testy jako dowód działania zamiast deklaracji programisty. Trzecia to testy regresji uruchamiane przy każdej poprawce. Nie zmienia się jedno: za plan, kod i odbiór odpowiadają ludzie. Poniżej pokazujemy, jak wygląda to w projektach eVolpe i o co warto zapytać dostawcę.
W skrócie: Agent AI przyspiesza implementację, ale wartość dla klienta tworzy proces wokół niego. Składają się na niego bramki akceptacji przez człowieka, testy generowane ze scenariuszy user story i regresja przy każdej zmianie. Do tego dochodzi raport, który mówi także, czego nie sprawdzono. Partnera warto oceniać po tym procesie, a nie po samej deklaracji „pracujemy z AI”.
Czym różni się partner pracujący z agentami AI od programisty, który korzysta z czatu AI?
Partner pracujący z agentami AI prowadzi każde zgłoszenie przez zdefiniowany proces. Agent wykonuje w nim kolejne kroki, a człowiek zatwierdza kierunek w ustalonych punktach kontrolnych. Programista korzystający z czatu AI dostaje fragmenty kodu i sam decyduje, co z nimi zrobić. Dla klienta różnica polega na powtarzalności. W procesie agentowym każde zgłoszenie przechodzi te same etapy: plan, testy, przegląd kodu i weryfikację, a ich wyniki są zapisywane. To podejście nazywamy Agentic Engineering i szerzej opisaliśmy je w artykule Vibe coding vs Agentic Engineering.
W procesie eVolpe biorą udział analityk, architekt, deweloper-implementator, agent AI, code reviewer i tester. Agentem AI kieruje orkiestrator, czyli mechanizm, który pilnuje kolejności kroków i tego, żeby na żadnym etapie nie pominąć człowieka. Agent AI nie zamyka zgłoszenia samodzielnie. Przekazuje wynik osobie, która go weryfikuje. Proces działa obecnie przy rozwoju SuiteCRM i MintHCM, a jego rozszerzenie na kolejne systemy jest w przygotowaniu.
Jak wygląda droga zgłoszenia od user story do środowiska testowego?
Zgłoszenie przechodzi przez stałą sekwencję etapów, a człowiek zatwierdza wynik w kluczowych momentach. W uproszczeniu proces wygląda tak:
- Start pracy. Deweloper uruchamia orkiestrator z numerem zgłoszenia w Redmine. Agent AI zmienia status na „W toku”, żeby nikt inny nie zaczął równolegle tej samej pracy.
- Plan z pytaniami. Agent AI analizuje user story i kod źródłowy. Przygotowuje plan implementacji i dopytuje o miejsca, w których opis jest niepełny. Deweloper akceptuje plan, koryguje go albo zawraca. To pierwsza bramka.
- Aktualizacja user story. Decyzje podjęte przy planowaniu agent AI dopisuje do zgłoszenia w Redmine.
- Scenariusze testów. Na podstawie user story agent AI generuje scenariusze testowe, jeszcze przed implementacją.
- Implementacja. Powstaje kod zgodny z zatwierdzonym planem.
- Samoweryfikacja. Niezależny subagent sprawdza kod pod kątem standardów zespołu. Powstają testy jednostkowe i testy przeglądarkowe, które agent AI uruchamia w pętli i na tej podstawie poprawia błędy.
- Akceptacja dewelopera. Człowiek sprawdza wynik w przeglądarce i czyta raport weryfikacji. To druga bramka.
- Code review. Automatyczny przegląd kodu generuje raport, który ocenia reviewer. Potwierdzone błędy wracają do Redmine jako zgłoszenia.
- Testy i odbiór techniczny. Tester sprawdza, czy scenariusze są kompletne, i ręcznie dotestowuje to, czego nie pokryły testy automatyczne. Na końcu podpisuje się pod wynikiem, a kod trafia do gałęzi deweloperskiej i na środowisko testowe.
Bramki nie są jedynymi momentami kontaktu z człowiekiem. Agent AI zatrzymuje się i zadaje pytanie na każdym etapie, na którym trafia na decyzję nieprzewidzianą w planie.
Jak wygląda ślad decyzji w Redmine?
Najbardziej odczuwalna zmiana dla klienta to kompletność zgłoszeń w Redmine. Decyzje podjęte w trakcie pracy wracają do user story, zamiast zostawać w rozmowach na komunikatorze. Wcześniej zdarzało się, że deweloper dopytał analityka na czacie i obaj ustalili inne rozwiązanie, ale w zgłoszeniu nie zostawał po tym ślad. Teraz agent AI po zatwierdzeniu planu dopisuje ustalenia do user story. Dzięki temu opis zgłoszenia odpowiada temu, co zostało faktycznie zbudowane.
Oprócz zaktualizowanego opisu w Redmine zostają zmiany statusów, zgłoszenia błędów z przeglądu kodu i testów oraz raport weryfikacji. Raport weryfikacji pokazuje, jakie walidacje wykonał agent AI i co znalazł w przeglądzie kodu. Wymienia też, co poprawił, czego świadomie nie poprawiał i z czym sobie nie poradził. Przy odbiorze lub zgłoszeniu reklamacyjnym klient może więc odtworzyć, kto podjął daną decyzję i dlaczego.
Dlaczego testy są dowodem, a nie deklaracją?
Test automatyczny jest dowodem, bo pokazuje wynik działania systemu, a nie opinię o kodzie. Model językowy po wygenerowaniu kodu z dużą pewnością twierdzi, że rozwiązanie działa. Zespoły IT o tym wiedzą: 30% badanych deklaruje niewielkie lub zerowe zaufanie do kodu generowanego przez AI (DORA, 2025). W naszym wcześniejszym procesie deweloper musiał ręcznie sprawdzać wynik w przeglądarce i opisywać agentowi każdy błąd. Dziś agent AI sam uruchamia testy przeglądarkowe, które odtwarzają kroki użytkownika i sprawdzają, czy na ekranie pojawia się oczekiwany wynik.
Testy przeglądarkowe powstają ze scenariuszy wygenerowanych na podstawie user story, zanim zacznie się implementacja. Tester sprawdza, czy scenariusze obejmują wszystkie przypadki, i dopisuje brakujące. Potem porównuje listę scenariuszy z testami, które faktycznie powstały w kodzie. Scenariusz bez odpowiednika automatycznego jest więc widoczny od razu i trafia do ręcznego sprawdzenia. Dla klienta oznacza to, że pokrycie testami nie jest szacunkiem, tylko listą, którą da się zweryfikować.
Co raport mówi o tym, czego nie sprawdzono?
Raport weryfikacji wymienia nie tylko testy, które przeszły, ale też obszary, których agent AI nie sprawdził, razem z powodem. W wewnętrznym przykładzie dodaliśmy do kartoteki kontrahentów pole NIP z walidacją formatu i sumy kontrolnej. Raport wskazał wtedy dwie luki. Nie przetestowano importu rekordów. Nie sprawdzono też polskich etykiet pola, bo instancja testowa nie miała zainstalowanej polskiej paczki językowej. Taka informacja mówi testerowi dokładnie, od czego zacząć ręczną weryfikację.
Jak testy regresji chronią procesy, które już działają?
Testy regresji sprawdzają, czy poprawka nie zepsuła czegoś, co wcześniej działało. W procesie eVolpe każdy test utworzony lub zmieniony w ramach zgłoszenia dostaje znacznik z numerem user story. Gdy agent AI poprawia błąd, nawet w niewielkim fragmencie funkcji, uruchamia wszystkie testy oznaczone tym zgłoszeniem. Nie ogranicza się do testu poprawianego miejsca. Jeśli coś przestaje działać, agent AI poprawia kod i powtarza cykl, aż wszystkie testy przejdą.
Uruchamianie pełnego zestawu testów systemu przy każdej zmianie trwałoby godzinami, dlatego regresja jest selektywna i obejmuje testy powiązane ze zgłoszeniem. Pętla poprawek ma limit prób. Jeśli agent AI nie poradzi sobie po kilku podejściach, zatrzymuje się i opisuje człowiekowi, gdzie utknął, zamiast próbować w nieskończoność. Mówimy też wprost o ograniczeniu: starsze procesy powiązane ze zmianą, ale nieobjęte scenariuszami, tester nadal sprawdza ręcznie.
Gdzie w procesie nadal potrzebny jest człowiek?
Człowiek jest potrzebny wszędzie tam, gdzie zapada decyzja: przy akceptacji planu, przy ocenie wyniku i przy odbiorze. Analiza artefaktów naszego procesu pokazuje, że agent AI regularnie proponuje rozwiązania, które trzeba skorygować na etapie planu. Czasem brakuje mu wiedzy, której nie ma w user story. Czasem plan jest technicznie poprawny, ale naruszyłby inny proces działający w systemie. Bywa też odwrotnie, gdy agent AI proponuje rozwiązanie lepsze, niż zakładał zespół.
Przykład z naszej praktyki: agent AI miał dostęp do kilku instancji tego samego systemu i uznał, że może analizować dane na środowisku innym niż projekt, nad którym pracował. Deweloper zatrzymał go, zanim agent podjął działanie. Ten przypadek dobrze pokazuje, dlaczego akceptacja planu przez człowieka nie jest formalnością. Pokazuje też, dlaczego klient powinien wiedzieć, do jakich środowisk i danych agent ma dostęp.
Proces poprawia się na podstawie własnych artefaktów. Zespół okresowo analizuje raporty z przeglądów kodu i korekty planów z różnych projektów, szukając powtarzających się błędów. Jeden z wykrytych wzorców dotyczył przycisków akcji na formularzach. Agent AI je dodawał, ale nie sprawdzał, czy użytkownik ma uprawnienia do wykonania akcji. Reviewerzy wyłapywali to wielokrotnie, więc reguła trafiła do instrukcji agenta odpowiedzialnego za implementację.
Czy praca z agentami AI skraca czas i obniża koszt wdrożenia?
Przy prostych zmianach tak: czas pracy dewelopera wyraźnie się skraca. Nie należy jednak oczekiwać, że każda wycena spadnie proporcjonalnie. W naszym procesie największe skrócenie widzimy przy powtarzalnych zmianach struktury, takich jak nowe pola, walidacje czy modyfikacje modułów. Przy integracjach i złożonych procesach biznesowych plan jest dłuższy, decyzji jest więcej i udział człowieka rośnie. Testy przeglądarkowe dla procesów, które wymagają wielu kroków przygotowania danych, są wciąż w rozwoju.
Warto odróżnić czas pracy dewelopera od czasu całego procesu. Agent AI wykonuje część kroków w tle, np. generuje testy i przegląda kod. Zgłoszenie może więc przechodzić przez proces dłużej, niż trwa sama praca człowieka, a jednocześnie zawiera testy automatyczne i raport, których wcześniej często nie było. Badania potwierdzają, że sama technologia nie wystarcza. Raport Google DORA opisuje AI jako wzmacniacz, który przyspiesza zespoły z dojrzałymi praktykami i uwidacznia słabości pozostałych. Według tego samego raportu adopcja AI wiąże się z niższą stabilnością dostarczania oprogramowania (DORA, 2025).
Co konkretnie zmienia się dla klienta w porównaniu z procesem bez agentów?
Najważniejsza zmiana dotyczy ilości dowodów, które klient dostaje przy każdym zgłoszeniu. Poniższa tabela porównuje częstą praktykę bez agentów AI z procesem, który stosujemy w eVolpe.
| Obszar | Częsta praktyka bez agentów AI | Proces z agentami AI w eVolpe |
| Status zgłoszenia | Zmieniany ręcznie, bywa nieaktualny | Agent AI zmienia status przy rozpoczęciu pracy |
| Decyzje w trakcie realizacji | Często zostają w komunikatorze | Dopisywane do user story w Redmine |
| Dowód działania | Deklaracja dewelopera i ręczne sprawdzenie | Testy jednostkowe i przeglądarkowe oraz raport weryfikacji |
| Obszary nieprzetestowane | Zwykle niewidoczne | Wymienione w raporcie razem z powodem |
| Regresja | Zależna od czasu i pamięci testera | Testy zgłoszenia uruchamiane przy każdej poprawce |
| Code review | Gdy reviewer znajdzie czas | Automatyczny raport oceniany przez reviewera |
| Błędy z przeglądu i testów | Różne kanały komunikacji | Zgłoszenia w Redmine |
| Odbiór techniczny | Tester bez pełnej listy pokrycia | Tester z listą scenariuszy i ich pokryciem testami |
Jakie pytania zadać partnerowi wdrożeniowemu, który pracuje z agentami AI?
Deklaracja „pracujemy z AI” nie mówi nic o jakości. Poniższe pytania pozwalają sprawdzić, czy za tą deklaracją stoi proces:
- W których momentach człowiek zatwierdza pracę agenta? Dobra odpowiedź wskazuje konkretne bramki, co najmniej akceptację planu i wyniku przed włączeniem kodu.
- Gdzie trafiają decyzje podjęte w trakcie realizacji? Powinny wracać do zgłoszenia w systemie, do którego klient ma dostęp, a nie zostawać w czacie.
- Czy dostanę dowód, że funkcja działa? Oczekuj raportu z testów, a nie zapewnienia.
- Czy raport mówi, czego nie przetestowano? Brak takiej informacji oznacza, że luki w testach są niewidoczne.
- Jak sprawdzacie, czy poprawka nie zepsuła innych funkcji? Zapytaj, które testy są uruchamiane przy poprawce i kto sprawdza powiązane procesy.
- Kto robi code review i czy agent ocenia własny kod? Przegląd powinien prowadzić niezależny agent albo człowiek, a ostateczną ocenę zawsze człowiek.
- Do jakich środowisk i danych ma dostęp agent? Zapytaj wprost, czy agent może pracować na danych produkcyjnych i kto o tym decyduje.
- Co się dzieje, gdy agent nie radzi sobie z zadaniem? Dobry proces ma limit prób i eskalację do człowieka.
- Jakich modeli i narzędzi używacie i gdzie są przetwarzane dane z mojego projektu? Odpowiedź powinna znaleźć pokrycie w umowie powierzenia przetwarzania danych.
- Kto podpisuje się pod odbiorem technicznym? Odpowiedzialność powinna mieć imię i nazwisko, a nie nazwę narzędzia.
Czego praca z agentami AI nie zmienia?
Praca z agentami AI nie przenosi odpowiedzialności z ludzi na narzędzie. Analiza biznesowa, jakość user story i decyzje architektoniczne pozostają po stronie zespołu, a agent AI pracuje tylko tak dobrze, jak precyzyjny jest opis zadania. Klient nadal przeprowadza testy akceptacyjne (UAT) i decyduje o wdrożeniu na produkcję. Nie zmieniają się też wymagania dotyczące bezpieczeństwa danych i umów powierzenia przetwarzania. Zmienia się natomiast to, ile dowodów klient dostaje na to, że praca została wykonana dobrze.
Umów bezpłatną konsultację z ekspertem wdrożeniowym eVolpe
Wybierz dogodny dla siebie termin.
Najczęściej zadawane pytania
Nie. Agent AI przygotowuje plan, kod i testy, ale każdy plan i wynik zatwierdza człowiek. Kod przechodzi code review i testy, a o wdrożeniu na produkcję decyduje klient po testach akceptacyjnych.
Przy prostych, powtarzalnych zmianach czas pracy zespołu się skraca. Przy integracjach i złożonych procesach oszczędność jest mniejsza, bo przybywa decyzji wymagających człowieka. Wycenę warto omawiać dla konkretnych zgłoszeń, a nie jako stały rabat.
Bramka jakości to punkt, w którym człowiek musi zatwierdzić pracę agenta, zanim proces pójdzie dalej. Przykłady to akceptacja planu implementacji albo akceptacja wyniku przed włączeniem kodu do gałęzi deweloperskiej.
Są wiarygodne, gdy powstają ze scenariuszy opartych na user story, a tester sprawdza ich kompletność. Raport z testów powinien wskazywać także obszary nieprzetestowane, które trzeba sprawdzić ręcznie.
Tak. Ślad pracy agenta trafia do Redmine: zmiany statusu, zaktualizowane user story, zgłoszenia błędów i raport weryfikacji. Na tej podstawie klient może odtworzyć decyzje podjęte w trakcie realizacji.
Proces działa przy rozwoju SuiteCRM i MintHCM. Przygotowujemy jego rozszerzenie na kolejne systemy, z którymi pracujemy.
Vibe coding to generowanie kodu przez AI bez systematycznej weryfikacji. Agentic Engineering to proces, w którym agenci AI działają w zdefiniowanych etapach, z testami, przeglądem kodu i akceptacją człowieka.
Źródła
- Google DORA, State of AI-assisted Software Development 2025, wrzesień 2025: research.google
- Google Cloud Blog, Announcing the 2025 DORA Report, 23.09.2025: cloud.google.com
- Co zmienia się dla klienta, gdy partner wdrożeniowy pracuje z agentami AI? - 26 października 2026
- 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
