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ę prezentuje 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.

Poniżej przedstawiamy kolejność awarii. Nie jest to lista najlepszych praktyk w abstrakcie, ale sekwencja, w jakiej rzeczy faktycznie się psują, ponieważ naprawianie ich w złej kolejności marnuje czas.

Co psuje się jako pierwsze: wspólny kontekst

Każdy deweloper uruchamiający agenta cicho uczy go swojej własnej 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 ich 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 zawiera teraz 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 oddalają się od siebie. Mechanizm ma większe znaczenie niż nazwa pliku: instrukcje znajdują się w repozytorium, więc docierają 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, z którego się migruje

Co nie powinno się w nim znaleźć, i tutaj zespoły się palą: cokolwiek specyficznego dla jednego komputera. Ś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 podążaniu za instrukcjami, które już nie mają zastosowania.

Przydatny test przed dodaniem linii: jeśli kolega z zespołu to pobierze, czy mu to pomoże, czy mu to zaszkodzi?

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

Agenci nie negocjują. Nie sprawdzają, czy ktoś inny jest w trakcie edycji. Dwaj agenci wskazani na ten sam moduł nadpiszą 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 i 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 daje każdemu zadaniu własne wycheckoutowanie 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 powstrzymuje 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 momencie przypisania, poprzez ograniczenie każdego zadania do zestawu plików i powiedzenie tego w opisie zadania. Nie "poprawić przepływ checkout" ale "zmienić krok płatności, w tych trzech plikach, nie dotykaj 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 staranna recenzja, lecz teatr zatwierdzeń. Człowiek przeglądający dziewięćset linii różnic o 18:00 produkuje podpis bez zdobywania wiedzy, co jest gorsze niż brak przeglądu, ponieważ wytwarza pewność tam, gdzie jej nie ma.

Polityka, która przetrwa, nie brzmi "przeglądaj wszystko" i nie brzmi "ufaj agentom". Chodzi o to, aby przenieść przegląd na dwa granice pracy: przeczytać plan przed rozpoczęciem pracy przez agenta, ponieważ zły plan wykonany perfekcyjnie to najdroższy tryb awarii, a następnie przeczytać różnice 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 czyste wyglądają różnice.

To zasługuje na osobną rozmowę, a my opisaliśmy to oddzielnie: czy powinieneś nadal 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 dodatkowa kwestia. Gdy kilku agentów dzieli repozytorium, przegląd potrzebuje przypisania: który agent, które zadanie, który deweloper. Bez tego różnice nie mają 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 kosztach

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ą generuje, 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ą przypuszczeniami.

Rzeczywisty rozkład prawie nigdy nie jest równomierny. To niewielka liczba długoterminowych 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 i jak je ograniczyć bez spowolnienia.

Uczyń tę liczbę widoczną dla osób, które ją generują, zanim stanie się tematem zarządzania. Deweloper, który widzi, ż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 faktycznie zmienia się w rytuałach zespołu

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

Standup przekształca się z statusu w odblokowanie. 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 jednemu deweloperowi, jest dla zespołu cenniejsza niż kod, który wyprodukowała, i jest dokładnie tym, co znika w historii prywatnego 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ą role agentów 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 Agent Teams, 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 działa

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

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

To jest problem, wokół którego zbudowano 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 na uruchamianiu obu, a ustawienie, które zakłada jednego dostawcę, cicho staje się następną rzeczą, która się psuje.

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