Jak skalować agentów AI do kodowania w zespole deweloperskim

Jeden deweloper z agentem kodującym to historia o produktywności. Łatwo to opowiedzieć, dobrze się to demonstruje i jest to naprawdę prawdziwe.

Pięciu deweloperów z dwudziestoma agentami to zupełnie inna sprawa. To problem koordynacji, a problemy koordynacyjne nie są rozwiązywane przez narzędzie, które je stworzyło. To jest część, o której nikt nie pisze, ponieważ pojawia się dopiero po fazie entuzjazmu: indywidualne zyski są realne, przychodzą natychmiast, a potem gdzieś w okolicach trzeciego lub czwartego dewelopera zespół zaczyna wydawać swoją nową prędkość na sprzątanie po sobie.

Oto porządek awarii. Nie lista najlepszych praktyk w abstrakcie, ale sekwencja, w jakiej rzeczy naprawdę się psują, ponieważ naprawianie ich w złej kolejności marnuje kwartał.

Co psuje się jako pierwsze: wspólny kontekst

Każdy deweloper uruchamiający agenta cicho uczy go swojej wersji bazy kodu.

Jedna osoba mówi swojemu agentowi, że projekt używa akcji serwera i nigdy tras API. Inna nigdy o tym nie wspomina, więc jej agent pisze trasy API. Trzecia wspomina o tym raz, w sesji, która zakończyła się trzy dni temu. Nikt nie ma racji, nikt nie kłamie, a repozytorium teraz zawiera trzy interpretacje tej samej konwencji. Zauważysz to w kolejce przeglądów, co jest złym miejscem, aby to zauważyć: do tego czasu kod już istnieje.

Naprawa jest nudna i jest to najbardziej efektywna rzecz na tej stronie. Umieść konwencje w pliku, zatwierdź plik.

CLAUDE.md dla Claude Code, AGENTS.md dla Codex i większości innych agentów CLI, a w praktyce wiele zespołów utrzymuje jeden przenośny plik kontekstowy zamiast utrzymywać dwa, które się rozjeżdżają. Mechanizm ma większe znaczenie niż nazwa pliku: instrukcje znajdują się w repozytorium, więc przychodzą z git pull zamiast przychodzić przez kogoś, kto akurat był w pokoju.

Co powinno się w nim znaleźć:

• Konwencje, których agent nie może wywnioskować z czytania kodu, szczególnie te, które baza kodu obecnie narusza w niektórych miejscach
• Komendy: jak uruchomić testy, budowę, lintera i które z nich mogą być uruchamiane automatycznie
• Części repozytorium, które są niebezpieczne do dotykania, i dlaczego
• Czego zespół nie chce: refaktoryzacja, o którą nikt nie prosił, zależność, która nie może być dodana, wzorzec, od którego się odchodzi

Co nie powinno się w nim znajdować, i tutaj zespoły się palą: cokolwiek specyficznego dla jednej maszyny. Ścieżki absolutne, osobiste tokeny API, lokalne porty, preferowany edytor kogoś. W momencie, gdy wartość specyficzna dla maszyny ląduje w zatwierdzonym pliku kontekstowym, każdy inny deweloper dziedziczy ustawienie, które jest dla nich błędne, a agenci są niezwykle dobrzy w wiernym przestrzeganiu instrukcji, które już nie mają zastosowania.

Przydatny test przed dodaniem linii: jeśli współpracownik to pobierze, czy to mu pomoże, czy go zepsuje?

Co psuje się jako drugie: dwóch agentów, jeden plik

Agenci nie negocjują. Nie sprawdzają, czy ktoś inny jest w trakcie edycji. Dwóch agentów skierowanych na ten sam moduł nadpisze się nawzajem, a żaden z nich o tym nie wspomni, ponieważ z punktu widzenia każdego z nich praca zakończyła się pomyślnie.

Solo, to jest niewidoczne. Uruchamiasz jednego agenta na raz, lub uruchamiasz kilku, a oni przypadkowo dotykają różnych rzeczy. W zespole staje się to strukturalne i produkuje najgorszą klasę błędu: praca, która cicho znika między dwoma zielonymi uruchomieniami testów.

Dwa mechanizmy to naprawiają, i chcesz oba.

Izolacja. Git worktrees dają każdemu zadaniu własne wypożyczenie repozytorium, więc równoległe agenty fizycznie nie mogą się zderzyć. To jest ta tańsza część rozwiązania i nie ma powodu, aby tego nie robić.

Własność. Izolacja zatrzymuje nadpisanie; nie zatrzymuje dwóch osób przed rozwiązaniem tego samego problemu dwa razy, w dwóch gałęziach, w dwa niekompatybilne sposoby. To jest rozwiązane w czasie przydzielania, poprzez ograniczenie każdego zadania do zestawu plików i powiedzenie tego w opisie zadania. Nie "poprawić przepływ wypożyczenia", ale "zmienić krok płatności, w tych trzech plikach, nie dotykać koszyka".

Druga część to ta, którą zespoły pomijają, i to ona decyduje, czy scalanie jest formalnością, czy popołudniem.

Co psuje się jako trzecie: przegląd

Wszystko, co dotyczy przeglądu w skali zespołu, wynika z jednej liczby: ile różnic przychodzi na godzinę.

Jeden deweloper czytający każdą linię działa dobrze. Pięciu deweloperów uruchamiających czterech agentów każdy generuje więcej różnic dziennie, niż zespół może przeczytać, a uczciwym wynikiem nie jest staranny przegląd, lecz teatr zatwierdzania. Człowiek przeglądający dziewięćset linii różnic o 18:00 produkuje podpis bez zdobycia wiedzy, co jest gorsze niż brak przeglądu, ponieważ wytwarza pewność tam, gdzie jej nie ma.

Polityka, która przetrwa, to nie "przeglądaj wszystko" i nie "ufaj agentom". To przenieść przegląd na dwa granice pracy: przeczytać plan przed rozpoczęciem agenta, ponieważ zły plan wykonany perfekcyjnie jest najdroższym trybem awarii, a następnie przeczytać różnicę proporcjonalnie do tego, co zmiana może zepsuć. Tekst marketingowy i CSS dostają przegląd. Autoryzacja, płatności, uprawnienia, dane osobowe i migracje są czytane linia po linii przez człowieka, za każdym razem, niezależnie od tego, jak czysta wygląda różnica.

To zasługuje na własną rozmowę, a my opisaliśmy to osobno: czy nadal powinieneś przeglądać kod swojego agenta AI przechodzi przez dziesięć obiektywnych oznak, że zmiana poszła źle, oraz tabelę promienia eksplozji, którą zespoły mogą przyjąć taką, jaka jest.

Jedna specyficzna dla zespołu uwaga. Gdy kilka agentów dzieli repozytorium, przegląd potrzebuje atrybucji: który agent, które zadanie, który deweloper. Bez tego różnica nie ma autora, a przegląd zamienia się w archeologię. To jest najważniejsza rzecz do naprawienia w twoim ustawieniu, gdy przejdziesz przez trzy lub cztery równoczesne agenty.

Co psuje się jako czwarte: koszt i rozmowa o koszcie

Wydatki na tokeny przestają być osobistym szczegółem w momencie, gdy pojawiają się na fakturze zespołu.

Pułapka polega na tym, że faktura jest miesięczna i zbiorcza, więc rozmowa, którą wywołuje, jest również miesięczna i zbiorcza, co oznacza, że produkuje politykę zamiast naprawy. Ktoś proponuje tańszy model dla wszystkich. Ktoś inny proponuje ograniczenie sesji. Oba są zgadywankami.

Rzeczywisty rozkład prawie nigdy nie jest równomierny. To niewielka liczba długotrwałych sesji, na jednym lub dwóch projektach, z kontekstem, który rósł przez cały dzień i nigdy nie został zresetowany. To jest zachowanie, które można naprawić, a możesz to naprawić tylko wtedy, gdy możesz zobaczyć wydatki na sesję i projekt, a nie na miesiąc. Omówiliśmy mechanikę tego w jak sprawdzić użycie tokenów oraz jak je ograniczyć bez spowalniania.

Uczyń tę liczbę widoczną dla osób, które ją generują, zanim stanie się tematem zarządzania. Deweloper, który może zobaczyć, że jedna sesja kosztowała więcej niż cały jego poprzedni dzień, zmienia swoje nawyki samodzielnie, a to nie kosztuje zespołu nic politycznie.

Co naprawdę zmienia się w rytuałach zespołu

Trzy rzeczy, według naszego doświadczenia i tego, co raportują zespoły.

Standup przesuwa się z statusu do usuwania blokad. To, co każda osoba zrobiła wczoraj, jest w dużej mierze widoczne w gałęziach. Co warte pięciu minut, to które agenty są zablokowane i na czym.

Podpowiedzi stają się wspólnymi zasobami. Instrukcja, która przyniosła dobry wynik dla jednego dewelopera, jest dla zespołu cenniejsza niż kod, który wyprodukowała, i to dokładnie ten rodzaj rzeczy, który znika w prywatnej historii terminala. Zespoły, które utrzymują wspólną bibliotekę podpowiedzi w repozytorium, przestają na nowo odkrywać tę samą frazę co tydzień.

Specjalizacja przesuwa się z ludzi na role. Gdy agenci zajmują się pisaniem, interesujące pytanie brzmi, kto przegląda co, a zespoły naturalnie składają się na przypisywanie ról agentom w ten sam sposób, w jaki przypisują je ludziom: jeden do wdrożenia, jeden do przeglądu, jeden do testów. To jest idea za Zespołami Agentów, gdzie zadanie jest przekazywane z roli dewelopera do roli QA z różnicą, ryzykiem i wskazówkami testowymi dołączonymi, a bramy jakości są decydowane przez twoją suite testową, a nie przez własną opinię agenta na temat swojej pracy.

Ustawienie, które się utrzymuje

Skondensowane, w kolejności, która ma znaczenie:

Pierwsze cztery nie kosztują nic poza zgodą. Ostatnie dwa to powód, dla którego zespół ostatecznie chce czegoś ponad terminal: nie dlatego, że terminale są złe, ale dlatego, że terminal pokazuje jednego agenta na raz i nie daje sposobu na odpowiedzenie na pytanie "kto uruchamia co, w jakim projekcie, w tej chwili".

To jest problem, wokół którego zbudowane jest AgentsRoom dla zespołów: każdy agent w każdym projekcie w jednym widoku, z jego rolą, statusem i kosztem dołączonym, oraz mobilnym towarzyszem na czasy, gdy zespół nie jest przy biurkach. Działa to w ten sam sposób z Claude Code i z Codex, co ma większe znaczenie, niż się wydaje: większość zespołów kończy uruchamiając oba, a ustawienie, które zakłada jednego dostawcę, cicho staje się następną rzeczą, która się psuje.

Zacznij jednak od pliku kontekstowego. Jest bezpłatny, zajmuje popołudnie i usuwa więcej tarcia niż jakiekolwiek narzędzie, które możesz zainstalować w tym kwartale.