Agentic Engineering we wdrożeniu systemu: jak zmienić programistów w menedżerów procesu

Marcin Różański

Każde wdrożenie systemu informatycznego wygląda podobnie. Analiza, planowanie, implementacja, code review, testy, poprawki – i tak w kółko, aż do momentu, gdy system działa tak, jak powinien. Dobry programista przechodzi przez cykl dziesiątki, a przy dużych projektach setki razy. Pytanie, które zaczyna się pojawiać coraz częściej, brzmi: co z tego cyklu musi robić człowiek, a co może zrobić agent AI?

W eVolpe zadaliśmy sobie to pytanie przy okazji prac nad MintHCM – naszym autorskim systemem klasy HCM. To, co z tej analizy wynikało, nie jest odpowiedzią na pytanie „czy AI może zastąpić programistów”. Jest odpowiedzią na inne: jak zorganizować pracę, żeby programiści mogli robić więcej, szybciej i lepiej. Dziś człowiek nadzoruje i weryfikuje. Docelowo – podobnie jak w relacji programista – tester – jeden agent będzie sprawdzał pracę drugiego. Odpowiedzialność za efekt końcowy stopniowo przesuwa się w stronę systemu, który sam siebie kontroluje.

Punkt wyjścia – nazwij swój proces

Zanim zaczniemy mówić o agentach, trzeba powiedzieć o czymś, co brzmi banalnie, ale w praktyce okazuje się warunkiem koniecznym: żeby automatyzować proces, trzeba go najpierw zrozumieć i nazwać.

W naszym przypadku zaczęliśmy od analizy tego, jak faktycznie wygląda praca dewelopera przy wdrożeniu. Nie jak powinna wyglądać według dokumentacji projektowej – jak wygląda naprawdę. Okazało się, że da się ją podzielić na kilka wyraźnych etapów:

  • planowanie deweloperskie – analiza user story, decyzja o sposobie implementacji
  • implementacja – pisanie kodu zgodnie z wypracowanym podejściem
  • self-testy – sprawdzenie przez autora, czy zmiany działają zgodnie z założeniami
  • code review – weryfikacja kodu przez drugiego programistę
  • testy – uruchomienie scenariuszy testowych, zbieranie wyników
  • poprawki i iteracja – cykl trwa, aż testy nie zwrócą błędów

To, co na pierwszy rzut oka wygląda jak oczywistość, w rzeczywistości jest strategicznym fundamentem. Dopiero gdy masz tak opisany proces, możesz sensownie zapytać: który z tych etapów jest powtarzalny, dający się sparametryzować i – co ważne – dający się zweryfikować? Bo agent może robić dużo, ale człowiek musi wiedzieć, co i jak sprawdzić.

Które etapy procesu wdrożenia może przejąć agent?

Krótka odpowiedź: prawie wszystkie wymienione powyżej. Planowanie, implementacja, self-testy, code review, uruchomienie testów automatycznych – każdy z tych kroków da się oddelegować agentowi AI. Narzędziem, na którym bazujemy, jest Claude Code od Anthropic – środowisko pracy agentycznej zaprojektowane z myślą o zadaniach deweloperskich.

Agent nie działa jak chatbot, któremu zadajesz pytania. Działa jak uczestnik procesu: dostaje zadanie (user story), planuje kroki, wykonuje implementację, uruchamia testy, analizuje wyniki i – jeśli coś nie gra – modyfikuje swoje działanie i próbuje ponownie. Pętla zamyka się automatycznie. Programista wkracza wtedy, gdy agent sygnalizuje gotowość do przeglądu, gdy pojawia się sytuacja, której agent nie potrafi rozwiązać samodzielnie.

Co ważne: agent odpowiada za wykonanie etapu, ale odpowiedzialność za efekt końcowy - za to, czy kod jest dobry, bezpieczny i zgodny z intencją biznesową - pozostaje po stronie programisty. Jeśli agent popełni błąd, programista nie tylko go koryguje 0 analizuje, czy źródłem problemu jest nieprecyzyjny skill, i jeśli tak, aktualizuje go. Weryfikacja wyniku jest więc jednocześnie doskonaleniem systemu. To nie jest drobiazg. To fundamentalna zasada, która sprawia, że takie podejście ma sens w środowisku produkcyjnym.
agentic engineering we wdrożeniu

Skille, czyli skąd agent wie, jak pracować w Twoim projekcie

Agent AI jest na tyle dobry, na ile dobry jest kontekst, który mu dostarczysz. Bez wiedzy o projekcie – jego architekturze, standardach kodowania, strukturze plików, sposobie dodawania modułów – agent będzie działał generycznie. Może i zrobi coś działającego, ale niekoniecznie spójnego z resztą systemu.

Rozwiązaniem jest struktura zwana skillami. Skill to ustrukturyzowany zestaw instrukcji opisujący konkretną umiejętność lub obszar wiedzy – na przykład: jak dodawać nowy moduł do MintHCM, jakie są standardy nazewnictwa w projekcie, gdzie powinna trafić logika biznesowa, jak zarządzać repozytorium.

Kluczowa cecha skills – każdy skill ma krótki nagłówek opisujący, czym jest i kiedy go użyć, a dopiero za nim pełna treść. Dzięki temu agent na początku sesji ładuje nagłówki wszystkich dostępnych skills i wie, jakie umiejętności posiada – nie musi ich szukać ani zgadywać. Sięga po konkretny skill wtedy, gdy zadanie tego wymaga.

W praktyce – i to nasze własne, robocze kategoryzowanie, nie żaden oficjalny podział – skille w projekcie dzielą się na dwie grupy:

  • Skille techniczne – opisują architekturę systemu, zasady pracy z kodem, standardy, struktury plików. To wiedza o tym, jak działa MintHCM jako platforma.
  • Skille procesowe – opisują etapy pracy: jak wygląda planowanie, jak przeprowadzić code review, co sprawdzić podczas self-testów. To wiedza o tym, jak wygląda nasz proces wdrożenia.

Oba zestawy zaziębiają się – agent wie, co robić (skille procesowe) i wie, jak to robić w konkretnym systemie (skille techniczne). Bibliotekę skills można rozszerzać w dowolnym momencie – jeśli pojawia się nowy wzorzec architektoniczny albo zmieniają się standardy, wystarczy zaktualizować odpowiedni skill.

Co zostaje po stronie człowieka?

To pytanie, które opisujemy, nie jest zarezerwowane wyłącznie dla firm tworzących własne oprogramowanie. Ma bezpośrednie przełożenie na każdą organizację, która wdraża lub utrzymuje system IT – CRM, HCM, ERP – i oczekuje, aż partner wdrożeniowy będzie dostarczał zmiany sprawnie i z zachowaniem standardów jakości.

Z perspektywy klienta wdrożenia kluczowe pytania to:

  • Czy partner ma opisany i powtarzalny proces wytwarzania? Jeśli tak – może go uspójnić i przyspieszać z pomocą agentów.
  • Czy standardy kodowania i architektura systemu są udokumentowane na tyle, żeby dało się je przekazać agentowi? To pytanie o dojrzałość techniczną projektu.
  • Czy w projekcie istnieją mechanizmy weryfikacji – code review, testy automatyczne – które pozwolą wychwycić ewentualne błędy agenta? Agentic Engineering nie eliminuje potrzeby kontroli, ale zmienia, kto ją sprawuje i kiedy.

Jeśli odpowiedzi na powyższe pytania są twierdzące – jesteś w dobrym miejscu, żeby zacząć. Jeśli nie – wartościowym pierwszym krokiem jest opisanie i ustandaryzowanie procesu. Agent jest tak dobry, jak dobry jest kontekst, który mu przekazujesz.

Podsumowanie

Agentic Engineering w wdrożeniu systemu nie polega na tym, żeby „dodać AI do projektu”. Jest o czymś bardziej konkretnym – o tym, które etapy powtarzalnego procesu można delegować autonomicznym agentom, jak wyposażyć ich w kontekst niezbędny do danej pracy i jak zorganizować nadzór tak, żeby odpowiedzialność za efekt końcowy pozostała po stronie ludzi.

W eVolpe testujemy to podejście przy pracach nad MintHCM. Wnioski są obiecujące – ale ważniejsza niż sama technologia jest zasada, która za tym stoi: najpierw opisz swój proces, potem go automatyzuj. W odwrotnej kolejności AI nie pomaga. Tylko przenosi chaos na wyższe obroty.

Jesteś gotowy na prowadzenie dużego projektu wdrożeniowego w Twojej firmie?

Darmowy kurs mailowy

Marcin Różański
Przewijanie do góry