Adding a new agent to my system takes 2 days. Not because of the architecture — but because teaching it to think like me is the hard part.

Kiedy budowałem mój system code review oparty o 9 agentów, nie budowałem tylko narzędzia. Budowałem system, który od początku miał rosnąć.
Każdy nowy problem, na który trafia mój zespół, może stać się nowym agentem. Architektura — fan-out/fan-in, równoległe wykonywanie, odporne fallbacki — była zaprojektowana od pierwszego dnia tak, żeby można było dodawać kolejne agenty bez psucia reszty systemu.
Ale dodanie agenta to nie tylko podpięcie go do pipeline’u.
Najtrudniejsze jest coś zupełnie innego.
Podpięcie nowego agenta do systemu jest dość proste. Definiujesz jego domenę, łączysz go z Orchestratorem, ustawiasz format odpowiedzi. Gotowe.
To, co zajmuje czas, to kalibracja — nauczenie agenta nie tylko tego, czego ma szukać, ale też jak ma myśleć o tym, co znajduje.
Mój najnowszy agent odpowiada za konwencje Storybooka. Jego zadanie:
sprawdzać, czy developerzy używają właściwych komponentów z naszego design
systemu zamiast surowych tagów HTML. <Link> zamiast <a>. <Button> zamiast
<button>. Sprawdza też, czy implementacja zgadza się z tym, co faktycznie jest
zdefiniowane w Storybooku.
Prosta domena.
Ale ustawienie tego dobrze zajęło 2 dni.
Domena była jasna od początku. Prawdziwa praca była w trzech miejscach:
Value gates i severity — co jest blockerem, a co tylko sugestią? Użycie
surowego <a> zamiast <Link> w nowym komponencie to co innego niż znalezienie
tego w legacy pliku, którego nikt nie dotykał od miesięcy. Agent musi rozumieć
tę różnicę.
Source of truth — skąd agent ma wiedzieć, które komponenty naprawdę istnieją? Jak porównuje to, co jest w Storybooku, z tym, co pojawia się w diffie? Dobre ustawienie tego wymagało przemyślenia kontekstu i sposobu, w jaki agent ma do niego dostęp.
Czytanie outputu — w każdym cyklu kalibracji czytam wszystko, co agent zwraca. Nie po to, żeby tylko przyklepać wynik. Czytam, żeby zobaczyć, gdzie rozumuje dobrze, a gdzie zaczyna odpływać.
Ten ostatni punkt jest nienegocjowalny.
Nie da się skalibrować czegoś, czego się nie czyta.
Nie mam jednego template’u, który kopiuję między agentami. Każdy agent przechodzi własny proces kalibracji, bo każda domena ma inne sposoby, w jakie może się pomylić.
Agent TypeScriptowy psuje się inaczej niż Security Agent. Agent od Storybooka ma zupełnie inne edge case’y niż React Agent. Traktowanie ich tak samo oznaczałoby zgodę na przeciętne wyniki w całym systemie.
Ale jest też głębszy powód, dla którego ten system reviewuje kod tak jak ja.
Instrukcje są napisane tak, żeby żaden kawałek kodu nie był traktowany jak coś pobocznego. Każdy wariant dostaje ten sam poziom uwagi. Prosta funkcja pomocnicza przechodzi przez ten sam check złożoności algorytmicznej co główny komponent biznesowy. Nic nie dostaje darmowej przepustki.
To jest świadoma decyzja.
W momencie, w którym agent zaczyna pomijać edge case’y, bo coś „wygląda prosto”, cały system traci wiarygodność.
Dlatego ten system odzwierciedla sposób, w jaki ja robię code review — a nie sposób, w jaki generyczne AI robi code review. Nad pierwszymi 9 agentami spędziłem tydzień, iterując po blisko 2 900 liniach instrukcji, aż output zaczął pasować do moich standardów.
Agent od Storybooka przeszedł ten sam proces.
Krótszy — bo już wiem, czego szukać — ale nadal osobny.
Skalowanie tego systemu nie oznacza szybkiego dokładania agentów.
Oznacza dokładanie agentów, które trzymają ten sam standard co poprzednie.
Jeden nowy problem w codebase’ie. Dwa dni kalibracji. Jeden agent, który myśli jak ja, uruchamiany równolegle z pozostałą ósemką.
To właśnie system działający zgodnie z założeniem.
Pełny opis architektury: Jak zbudowałem system AI code review z 9 agentami
Czy ten wpis był pomocny?