Agenci AI pomagają zespołom programistycznym, gdy przejmują wąskie, powtarzalne zadania, takie jak wstępny code review, szkielety testów i prace przy wydaniach, z ograniczonym zestawem narzędzi i z człowiekiem zatwierdzającym każdą zmianę. Agent powinien pokazywać plan przed działaniem, rejestrować każde wywołanie narzędzia i dostarczać pracę w postaci diffów, a przed poszerzeniem jego zakresu trzeba go przetestować na prawdziwych przykładach z własnej historii.
Najpierw zadania powtarzalne, sprawdzalne i mało ryzykowne
Najlepsze pierwsze zadania dla agenta to te, które zespół już teraz wykonuje co tydzień w ten sam sposób i może szybko zweryfikować. Jeśli inżynier nie jest w stanie w ciągu minuty ocenić, czy wynik jest poprawny, agent zamiast oszczędzać pracę przy przeglądzie, dokłada jej.
Zmiany danych produkcyjnych, zmiany infrastruktury i wszystko, co nieodwracalne, warto odłożyć, dopóki agent nie wykaże się przy bezpieczniejszej pracy.
- Wstępny przegląd pull requestów: brakujące testy, ryzykowne wzorce, niejasne nazwy, problemy ze stylem
- Generowanie testów dla istniejących funkcji, zwłaszcza przypadków brzegowych i testów regresji dla naprawionych błędów
- Pull requesty z aktualizacjami zależności wraz z podsumowaniem każdego changelogu
- Szkice informacji o wydaniu przygotowane na podstawie scalonych pull requestów
- Wstępna analiza nieudanych przebiegów CI, grupowanie błędów i wskazanie prawdopodobnego commita
Właściwa warstwa: API modelu, framework agentowy czy narzędzie do workflow
Bezpośrednie wywołania API OpenAI lub Anthropic Claude z użyciem narzędzi (tool use) wystarczą do pojedynczego, dobrze zdefiniowanego zadania. LangChain dodaje integracje i typowe elementy składowe, a LangGraph modeluje agenta jako jawny graf kroków ze współdzielonym stanem, co ułatwia panowanie nad rozgałęzieniami, ponowieniami i punktami akceptacji przez człowieka.
n8n sprawdza się jako spoiwo wokół agenta: uruchomienie na webhooku z GitHub lub GitLab, wywołanie modelu, opublikowanie komentarza w przeglądzie, powiadomienie na kanale. Częsty podział to n8n do orkiestracji, a krok rozumowania w kodzie, gdzie można go wersjonować i testować jak resztę oprogramowania.
W NorthStar Network nasi inżynierowie zbudowali wewnętrzne narzędzia oparte na AI, które automatyzowały powtarzalne zadania inżynierskie dla zespołu odpowiedzialnego za narzędzia platformy.
Najmniejszy zestaw narzędzi, jakiego agent potrzebuje
Agent może wyrządzić szkodę tylko za pomocą swoich narzędzi, więc lista narzędzi to główne zabezpieczenie. Każde narzędzie powinno mieć wąski cel i walidowane dane wejściowe, zamiast dawać agentowi ogólną powłokę czy szeroki token API.
Wszystko, co agent czyta, łącznie z treścią zgłoszeń, komentarzami w kodzie i stronami internetowymi, należy traktować jako niezaufane dane wejściowe. Instrukcje ukryte w pliku mogą próbować zmienić działanie agenta, co jest ryzykiem znanym jako prompt injection, a ścisłe granice narzędzi sprawiają, że taka próba nie wyrządzi szkody.
- Domyślnie tylko odczyt: czytanie plików, diffów i logów CI
- Zapis ograniczony do gałęzi roboczej, nigdy do gałęzi głównej ani produkcji
- Osobne, krótkotrwałe dane uwierzytelniające dla każdego agenta z minimalnymi uprawnieniami
- Żadnych bezpośrednich wdrożeń: agent otwiera pull request, a zwykły pipeline wdraża zmianę po akceptacji
- Lista dozwolonych poleceń do uruchamiania testów, wykonywanych w odizolowanym kontenerze
Najpierw plan, potem działanie, a każde wywołanie narzędzia w logu
Agent powinien przygotować plan, zanim cokolwiek zmieni: które pliki przeczyta, co zamierza zmienić i jak zweryfikuje wynik. Plany o niskim ryzyku mogą być wykonywane automatycznie. Wszystko, co dotyka współdzielonego kodu, czeka na zatwierdzenie planu przez człowieka.
Każde wywołanie narzędzia należy rejestrować z danymi wejściowymi, wynikami, znacznikiem czasu i zadaniem, do którego należy. Ten log pozwala zdiagnozować zły wynik, odpowiedzieć na pytanie audytowe i zauważyć, że agent wychodzi poza swoje zadanie. Trzeba go chronić jak inne logi inżynierskie, bo może zawierać kod źródłowy.
Każdy przebieg powinien mieć twarde limity: maksymalną liczbę kroków, tokenów i minut, a po powtarzających się błędach zatrzymanie zamiast niekończącej się pętli ponowień.
Każda zmiana jako diff do przeglądu przez człowieka
Wynik pracy agenta powinien trafiać tam, gdzie inżynierowie już przeglądają pracę: do pull requestu, komentarza w przeglądzie, szkicu informacji o wydaniu. Diff pokazuje dokładnie, co się zmieniło, CI uruchamia się na nim, a obowiązują zwykłe zasady akceptacji.
Diffy od agenta powinny być małe i mieć jeden cel. Pull request, który dodaje testy dla jednego modułu, łatwo przejrzeć, a taki, który dotyka dziesięciu plików w ramach ogólnych ulepszeń, zostaje zatwierdzony bez czytania albo odrzucony. Zmiany autorstwa agenta warto oznaczać, aby osoby przeglądające sprawdzały założenia, a nie tylko składnię.
Wygenerowane testy wymagają szczególnej uwagi. Trzeba potwierdzić, że sprawdzają zamierzone zachowanie i nie przeszłyby, gdyby kod był błędny, zamiast po prostu utrwalać to, co zwraca obecny kod.
Ewaluacja na własnej historii przed poszerzeniem zakresu
Z własnych repozytoriów warto zbudować niewielki zestaw ewaluacyjny: dawne pull requesty ze znanymi problemami, funkcje ze znanymi błędami, awarie CI o znanych przyczynach. Agenta uruchamia się na nim przy każdej zmianie promptu, modelu lub narzędzi i porównuje wyniki z poprzednim przebiegiem.
W codziennym użyciu warto śledzić, jak często osoby przeglądające przyjmują sugestie agenta, ile pull requestów od agenta zostaje scalonych bez poprawek i jak często plany są odrzucane. Nowe zadanie lub szerszy dostęp agent powinien dostać dopiero wtedy, gdy te sygnały są stabilne.
Zasady dotyczące danych spisane przed pierwszym uruchomieniem
Trzeba zdecydować i spisać, jaki kod i jakie dane mogą trafiać do którego dostawcy modelu i na jakich warunkach umownych. Warto sprawdzić ustawienia przechowywania danych i trenowania modeli u każdego dostawcy przy korzystaniu z API, a sekrety, dane uwierzytelniające i dane osobowe trzymać z dala od promptów i logów.
Jeśli agent obsługuje kilka zespołów lub klientów, dane, dane uwierzytelniające i logi każdego z nich należy odizolować. SDK Pilot, nasz agent AI dla zespołów inżynierskich, obecnie w bezpłatnym wczesnym dostępie, działa według tych zasad: pokazuje plan przed wykonaniem, rejestruje każde wywołanie narzędzia, tworzy diffy do przeglądu i izoluje dane każdej organizacji.
Najważniejsze wnioski
- Agentów najlepiej zaczynać od powtarzalnych zadań, których wynik inżynier zweryfikuje w mniej więcej minutę.
- Lista narzędzi to główne zabezpieczenie, więc narzędzia powinny być wąskie, domyślnie tylko do odczytu, a zapis ograniczony do gałęzi.
- Przed działaniem wymagany jest plan, a każde wywołanie narzędzia trafia do logu z danymi wejściowymi i wynikami.
- Całą pracę agenta dostarcza się jako małe diffy przez zwykły proces przeglądu i CI.
- Agentów ocenia się na prawdziwych przykładach z własnej historii, zanim dostaną szerszy zakres.
FAQ
Czy agenci AI mogą zastąpić code review wykonywany przez ludzi?
Nie. Agenci przydają się przy wstępnym przeglądzie, który wyłapuje brakujące testy, ryzykowne wzorce i problemy ze stylem, dzięki czemu ludzie mogą skupić się na projekcie i intencji zmian. Każdą scalaną zmianę nadal powinien zatwierdzać człowiek.
Czy agent AI może bezpiecznie wdrażać na produkcję?
Nie bezpośrednio. Agent powinien otwierać pull request lub zgłoszenie zmiany, a wdrożenie powinno przejść przez istniejący pipeline po akceptacji człowieka. Dzięki temu ślad audytowy, testy i proces wycofywania zmian pozostają nienaruszone.
LangGraph czy n8n do automatyzacji pracy zespołu programistów?
Rozwiązują różne problemy. LangGraph porządkuje rozumowanie agenta w jawne kroki ze stanem i punktami akceptacji, a n8n łączy systemy za pomocą wyzwalaczy i działań. Wiele zespołów używa n8n do uruchamiania i kierowania pracy, a LangGraph lub bezpośrednich wywołań API modelu do samego agenta.