Kodeks i przepływ pracy wieloagentowy: pracuj z agentami bez utraty kontroli
· 6 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Gdy agent programujący po raz pierwszy faktycznie naprawi dla Ciebie błąd, reakcja jest prawie zawsze taka sama: mieszanina entuzjazmu i podejrzeń. Ładne, jasne. Ale potem patrzysz na różnicę i zadajesz sobie pytanie: „OK, ale czego dokładnie dotknął? Czy mogę mu zaufać? Czy jutro zrobi to ponownie w ten sam sposób?”.
Myślę, że tu zaczyna się interesująca część. Nie wtedy, gdy agent pisze funkcję, ale wtedy, gdy staje się ona na tyle zdolna, aby podjąć się całych zadań: przeczytać repozytorium, stworzyć łatkę, uruchomić testy, otworzyć PR, wrócić po komentarzu do recenzji. Codex zmierza właśnie w tym kierunku: praca w tle, oddzielne drzewa robocze, zintegrowana przeglądarka, automatyzacja, wtyczki, pamięć i bardziej wyraźna kontrola uprawnień.
Nie chodzi o to, żeby wyobrażać sobie przyszłość, w której nikt już nie czyta kodu. Byłaby to straszna przyszłość, a przy tym dość naiwna. Chodzi o to, aby dowiedzieć się, jak współpracować z agentami, którzy mogą wiele zrobić, nie pozwalając im robić wszystkiego.
Zmiana nawyku
Dzięki tradycyjnemu autouzupełnianiu zawsze byłeś za kierownicą. Sztuczna inteligencja zasugerowała linię, zdecydowałeś. Z agentem jednak relacja się zmienia: dajesz mu cel, a on samodzielnie przechodzi przez wiele etapów.
To jest potężne, ale zmienia problem. Pytanie nie brzmi już tylko „czy model można zaprogramować?”. Pytanie brzmi:
- Czy dałem mu wystarczająco mały zakres?
- wiesz jak sprawdzić wynik?
- Czy pracuję w izolowanym środowisku?
- Czy ostateczna ocena jest nadal humanitarna i ostrożna?
Zdrowy przepływ pracy wygląda bardziej jak magiczna różdżka:
Brzmi mniej romantycznie niż „agent wszystko buduje”, ale działa znacznie lepiej. I tak działają zespoły, które dobrze radzą sobie z ludźmi: jasne zadania, szybka informacja zwrotna, wyraźna odpowiedzialność.
Dobra zachęta to prawie dobry bilet
Najbardziej niebezpiecznym komunikatem jest ten niejasny, ale pewny: „napraw stronę z fakturami”, „popraw architekturę”, „wyczyść moduł uwierzytelniania”. Są to żądania, które brzmią produktywnie i generują ogromne różnice. Ale potem okazuje się, że zajmujesz się archeologią.
Pomocny monit jest bardziej nudny. Na przykład: zaimplementuj eksport CSV dla strony faktur, wiedząc, że tabela jest w app/(dashboard)/invoices/page.tsx, zapytania są w src/server/invoices.ts i podobny wzorzec istnieje już w app/(dashboard)/reports.
Następnie dodaj jasne ograniczenia: nie zmieniaj schematu bazy danych, nie dodawaj zależności, jeśli wystarczy małe narzędzie, zachowaj istniejący styl interfejsu użytkownika. I zakończ weryfikacją: npm test -- invoices i npm run build.
Celem tego rodzaju briefu nie jest „lepsze wyjaśnianie sztucznej inteligencji”. Służy przede wszystkim wyjaśnieniu Ci, co delegujesz. Jeśli nie potrafisz tego zapisać konkretnie, być może zadanie nie jest jeszcze gotowe dla agenta.
Trzy zadania, które chętnie deleguję
Pierwsza to praca powtarzalna, ale możliwa do sprawdzenia: dodawanie testów, migracja wywołań do nowego wewnętrznego API, aktualizacja importów, wymiana przestarzałych komponentów, naprawianie błędów TypeScriptu. Tutaj agent może zaoszczędzić wiele godzin, a ryzyko można kontrolować.
Druga to praca eksploracyjna: „znajdź miejsce obliczenia tej sumy”, „wyjaśnij mi, dlaczego ten test jest niestabilny”, „odtwórz błąd i powiedz mi, których plików prawdopodobnie dotyczy”. Nawet jeśli nie wyprodukuje od razu łatki, może przeprowadzić pożyteczny rekonesans.
Trzeci to powtarzające się prace konserwacyjne: małe aktualizacje zależności, czyszczenie starych flag funkcji, podsumowanie zablokowanych PR, sprawdzanie zapomnianych TODO. Nie jest to jakieś efektowne, ale to dokładnie ten rodzaj pracy, która ma tendencję do nawarstwiania się.
Trzy prace, które zachowuję jako ludzkie
Decyzje dotyczące produktu pozostają ludzkie. Jeśli zmiana zmienia sposób, w jaki użytkownik płaci, usuwa dane, widzi ceny lub rozumie pozwolenie, potrzebuję osoby odpowiedzialnej.
Na uwagę człowieka zasługują także granice bezpieczeństwa: uwierzytelnianie, role, tokeny, rejestrowanie wrażliwych danych, migracje baz danych. Agent może pomóc we wdrożeniu, ale nie musi być jedynym decydentem.
Wreszcie wszystko, co wymaga ludzkiego gustu architektonicznego, zachowuję. Agent może zaproponować refaktor, ale zrozumienie, czy abstrakcja jest naprawdę konieczna, czy też po prostu dopracowujemy nieistniejący problem, pozostaje zadaniem.
Przegląd nie jest opcjonalny
Kiedy agent jest dobry, pojawia się pokusa, aby zaufać zielonemu CI. To zrozumiałe. Wtedy też zaczynają się problemy.
Zawsze biorę pod uwagę co najmniej pięć rzeczy:
- Czy łatka rozwiązuje tylko żądane zadanie?
- Czy dotknął plików, które nie miały z tym nic wspólnego?
- Czy testy obejmują nowatorskie zachowanie, czy po prostu szczęśliwy przypadek?
- Czy kod jest zgodny z lokalnymi wzorcami?
- Czy błędy są obsługiwane tak jak w pozostałej części projektu?
Kiedy coś jest nie tak, informacja zwrotna musi być konkretna. „Napraw to” jest leniwe. Lepiej: to narzędzie duplikuje parseMoney w src/lib/money.ts; ponownie użyj tej funkcji, dodaj test dla sprawy EUR i nie zmieniaj publicznego API modułu rozliczeniowego.
Agenci znacznie lepiej reagują na drobne, weryfikowalne uwagi. Co ciekawe, ludzie też.
Poręcze warte wysiłku
Jeśli agent może czytać pliki, pisać kod i wykonywać polecenia, należy go traktować jako potężny proces. Nie ma co popadać w paranoję, wystarczy higiena.
Użyj oddzielnych drzew roboczych lub gałęzi. Możesz więc porównywać różnice, odrzucić nieudane eksperymenty i nie mieszać pracy agenta z tym, co robiłeś.
Ogranicz uprawnienia. Polecenia takie jak rg, git diff, npm test i npm run build mogą być całkiem darmowe. Wdrożenia, migracje baz danych, dostęp do sekretów i destrukcyjne polecenia muszą pozostać jawne.
Ogranicz dostęp do sieci, gdy go nie potrzebujesz. Do wielu zadań wystarczą oficjalna dokumentacja, rejestr pakietów i określone usługi wewnętrzne. Mniejsza powierzchnia, mniej niespodzianek.
Śledź działania. Kiedy łatka dotrze do przeglądu, powinieneś być w stanie zrekonstruować monity, wykonane polecenia, zaliczone testy i zmodyfikowane pliki. Nie po to, żeby tworzyć biurokrację, ale żeby móc zrozumieć, co się stanie, jeśli coś pójdzie nie tak.
Łatwy sposób na rozpoczęcie pracy w zespole
Gdybym miał wprowadzić agentów do małego zespołu, zacząłbym bez większych rewolucji.
Utworzyłbym etykietę agent-ready dla problemów o jasnym zakresie. Dodałbym szablon z kontekstem, ograniczeniami i poleceniami weryfikacyjnymi. Prosiłbym o mały PR, najlepiej poniżej kilkuset linijek. Wymagałbym testów lub zrzutów ekranu pod kątem widocznych zmian. A przede wszystkim pozostawiłbym osobę odpowiedzialną za fuzję.
Po dwóch tygodniach przyjrzałem się danym: które zadania zostały naprawdę przyspieszone, które recenzje były ciężkie, które podpowiedzi były zagmatwane, które części bazy kodu są zbyt delikatne, aby je delegować.
To mniej spektakularne podejście niż „od dzisiaj będziemy robić wszystko z agentami”, ale takie, które pozwala bez żalu przejść do trzeciego tygodnia.
Najbardziej ludzka część
Zabawne jest to, że im bardziej autonomiczni stają się agenci, tym ważniejsze znów stają się klasyczne umiejętności: pisanie dobrego zgłoszenia, dokonywanie małych cięć, tworzenie testów, czytanie różnic, komunikowanie kompromisów. Środek przyspiesza tych, którzy już wiedzą, jak dobrze pracować. Pogłębia także chaos tych, którzy źle delegują zadania.
Więc nie, nie postrzegam wieloagentowych przepływów pracy jako skrótu, dzięki któremu można przestać zajmować się inżynierią. Postrzegam je jako sposób na przeniesienie większej ilości energii na najważniejsze części: podjęcie decyzji, co zbudować, upewnienie się, że działa, utrzymanie zrozumiałości systemu.
Agenci mogą być świetnymi asynchronicznymi współpracownikami. Ale asynchroniczny współpracownik, aby był użyteczny, potrzebuje kontekstu, granic i przeglądu. Podobnie jak wszyscy inni.