Odpowiedzi bez marketingu. Tam, gdzie coś zależy od kontekstu lub dostawcy — piszemy to wprost.
Zakładamy, że każdy wynik agenta może być błędny — dlatego żaden wynik nie liczy się sam z siebie. Zadanie przechodzi dalej tylko wtedy, gdy istnieją niezależne dowody: zielone testy, werdykt innego agenta przypięty do dokładnej rewizji kodu, zgodny wynik CI.
Halucynacja, która nie przejdzie testów — nie przejdzie bramki. Halucynacja w samych testach jest łapana przez oddzielny werdykt QA i przegląd. To nie eliminuje błędów w stu procentach (żaden proces tego nie robi — także z ludźmi), ale zamienia „wierzę agentowi" na „sprawdziłem dowody".
Człowiek. Zawsze. Proces jest tak skonstruowany, że decyzje strategiczne i akceptacja wyniku należą do operatora — agent nie może sam zamknąć zadania ani scalić zmiany do gałęzi głównej.
Ślad audytowy pokazuje przy każdej zmianie: kto zdefiniował cel, jakie dowody zebrano, kto zaakceptował. Odpowiedzialność jest przypisywalna dokładnie tak samo jak w zespole ludzkim — tylko lepiej udokumentowana.
Praca zatrzymuje się na bramce z nazwanym powodem i następnym właścicielem — proces nie zna stanu „cicho leży". Zadanie zablokowane wraca do właściwego etapu albo do człowieka z opisem, czego brakuje.
Zwrot pracy to normalny, zaprojektowany ruch w procesie — zobacz demo przebiegu, w którym weryfikacja odsyła pracę do poprawki.
Fragmenty kodu są wysyłane do modelu w ramach zapytań — tak działa każde narzędzie tej klasy. Co dalej dzieje się z tymi danymi, zależy od dostawcy i umowy: plany enterprise głównych dostawców oferują zobowiązanie do nietrenowania na danych klienta i retencję zero lub ograniczoną.
W ramach wdrożenia dobieramy dostawcę i tryb (API, region, retencja) do Waszych wymagań — włącznie z polityką, które repozytoria w ogóle mogą być przetwarzane przez agentów.
Domyślnie nie. Agenty pracują na izolowanych gałęziach i środowiskach roboczych; sekrety żyją poza ich zasięgiem, a operacje na środowiskach przechodzą przez te same bramki co kod. Merge do gałęzi głównej wykonuje wyłącznie skrypt bramki po komplecie dowodów — agent nie ma uprawnień, by to obejść.
Ten model budujemy na własnym produkcie bezpieczeństwa (VaultPAM) — zarządzanie dostępem uprzywilejowanym to nasza codzienność, nie dodatek.
Do Was — dokładnie tak samo jak kod napisany przez pracowników. Praca odbywa się w Waszych repozytoriach, na Waszej infrastrukturze lub w uzgodnionym środowisku. EUWarden nie rości sobie praw do wytworzonego kodu ani nie zabiera procesu po zakończeniu współpracy.
To decyzja organizacji, nie procesu — ale uczciwie: codzienna praca zmienia się znacząco. Mniej ręcznego pisania kodu i wykonywania testów, więcej definiowania zadań, przeglądu pracy agentów, decyzji technicznych i projektowania weryfikacji.
W praktyce wąskim gardłem przestaje być liczba rąk, a staje się liczba osób umiejących dobrze zdefiniować cel i ocenić wynik. Przekwalifikowanie zespołu jest częścią ścieżki wdrożenia.
Dwa główne składniki: koszt modeli (opłaty za tokeny — zależny od wolumenu i klasy zadań) oraz koszt ludzi w nowych rolach (operatorzy, nadzór merytoryczny). Do tego istniejąca infrastruktura: CI, repozytoria, issue tracker.
Rachunek ma sens dopiero na tle linii bazowej: dlatego pilot mierzy koszt na dostarczoną zmianę i porównuje z dotychczasowym. Nie obiecujemy mnożnika przed pomiarem — dostajecie liczby z Waszej organizacji po pilocie.
Nie na starcie. Operator musi rozumieć cel biznesowy i umieć ocenić wynik — nie promptować. Inżynierowie uczą się pracy z agentami w pilocie, na własnych zadaniach, z asystą. Kompetencje AI budują się w trakcie, nie przed.
Od oceny gotowości — 2–3 tygodnie przeglądu repozytoriów, przepływu pracy, ludzi i narzędzi, bez zmieniania czegokolwiek. Wynik: raport gotowości i wybrany strumień pracy na pilota, z decyzją go/no-go po Waszej stronie.
Szczegóły trzech faz: ścieżka wdrożenia. Pierwszy krok: michal@euwarden.com.
Proces jest niezależny od języka — wymaga repozytorium git, issue trackera i CI zdolnego uruchamiać testy. Jakość pracy agentów zależy od jakości sygnałów zwrotnych w stacku (testy, typy, lint) — to oceniamy w fazie gotowości i mówimy wprost, co trzeba wzmocnić najpierw.
Nasze przykłady pokazują Jirę i GitHuba, bo na nich pracujemy. Wiążący jest jednak kontrakt zdolności, nie nazwa produktu: tracker musi mieć konfigurowalne statusy i przejścia, etykiety oraz API do komentarzy i tranzycji; host kodu — pull/merge requesty, wymagane statusy checków i API. Spełniają to m.in. GitLab, Linear i Azure DevOps Boards. Dopasowanie sprawdzamy w fazie gotowości — i mówimy wprost, jeśli czegoś brakuje.