Codziennie przekazujemy agentom kodującym prawdziwe zgłoszenia i prawie zawsze dostarczają coś, co działa. To nigdy nie było zmartwieniem. Zmartwieniem jest jak pracują: nowy helper obok trzech, które już wykonują to zadanie, świeża abstrakcja dla jednego wywołującego, poprawka, która łata jedną ścieżkę wskazaną w zgłoszeniu i zostawia czworo rodzeństwa zepsutych, ustalenie, które “prawdopodobnie jest błędem”, bez dowodu w którąkolwiek stronę. Każda zmiana jest lokalnie sensowna. W sumie to entropia.
TL;DR: W pięciu pull requestach Poziomu 3 w naszym rdzeniu orkiestracji agentów trzy komponowalne umiejętności —
ponytail(odejmuj),grain(dopasuj) ireview-proof(udowodnij) — usunęły 821 linii, jednocześnie dostarczając pięć funkcji, wychwyciły ciche złamanie kontraktu, które sama wiarygodność by scaliła, i utrzymały każdą zmianę zgodnie ze słojami istniejącej architektury. Oto co robi każda z nich, z prawdziwymi diffami na poparcie.
Odbierz barierki, a agent kodujący staje się bardzo szybkim generatorem wiarygodnie wyglądających zobowiązań. Dlatego opieramy się na trzech małych umiejętnościach, które pchają w drugą stronę — po jednym instynkcie każda: odejmuj, dopasuj, udowodnij.
ponytail— napisz najleniwszą rzecz, która faktycznie działa. Usuwaj, zanim dodasz. (Tej nie napisaliśmy — to otwartoźródłowa umiejętność Dietricha Geberta , którą zaadaptowaliśmy do naszego stacku.)grain/grain-review— umieść to tam, gdzie codebase już zdecydował, że to należy. Nie wymyślaj drugiego sposobu.review-proof— nie wierz ustaleniu, dopóki nie odtworzy się jako failing test.
grain i review-proof zbudowaliśmy w tym samym duchu co ponytail, dostrojone do naszej architektury. Każdy z pięciu poniższych PR-ów dotyka naszego rdzenia orkiestracji agentów — najdroższego miejsca w repozytorium, by coś spaprać — i każdy jest sklasyfikowany jako Poziom 3: dodatkowe pokrycie testami i przegląd człowieka ponad zautomatyzowanego recenzenta, bez wyjątków.
Trzy umiejętności w skrócie: ponytail odejmuje, grain dopasowuje, review-proof udowadnia.
Część 1 · CO — entropia jest stanem domyślnym
Oto rzecz, o której nikt cię nie ostrzega, gdy oddajesz repozytorium agentom AI: każdy agent optymalizuje lokalnie i niczego nie pamięta. Widzi zgłoszenie, a nie miesiące konwencji, do których doszła twoja drużyna. Nie ma powodu, by przedkładać twoją istniejącą usługę e-mail nad świeżą, nie pamięta, że zbiór statusów przekierowań jest już zdefiniowany trzy pliki dalej, nie ma instynktu, że “poprawka idzie do wspólnej funkcji, a nie do tego jednego wywołującego”. Pozostawione samym sobie, N agentów produkuje N nieco różnych sposobów robienia tej samej rzeczy. To nie problem jakości kodu, który wylintujesz — to strukturalny dryf, który się kumuluje.
Każda z trzech umiejętności celuje w jedną oś tego dryfu.
ponytail — najleniwsza rzecz, która działa
Ponytail to senior developer, którego o 3 w nocy budzono z powodu cudzej sprytnej abstrakcji i który odmawia napisania następnej. Przechodzi drabinę i zatrzymuje się na pierwszym szczeblu, który się trzyma: czy to w ogóle musi istnieć (YAGNI) → czy już jest w tym codebase → czy robi to standardowa biblioteka → natywna funkcja platformy → już zainstalowana zależność → czy może być jedną linią → dopiero wtedy minimalny kod, który działa.
Szczebel, który dla agentów ma największe znaczenie, to “czy to już jest w tym codebase?” Ponowne implementowanie czegoś, co jest kilka plików dalej, to najczęstsza forma agentskiego bałaganu. A zasada ponytaila dotycząca poprawek błędów trzyma diffy w ryzach: napraw przyczynę źródłową, nie objaw. Zgrepuj każdego wywołującego funkcji, której zaraz dotkniesz; jedna straż w funkcji wspólnej to mniejszy diff niż straż u każdego wywołującego — i nie zostawia rodzeństwa zepsutego.
grain / grain-review — idź ze słojami
Jeśli ponytail rządzi tym, jak mało piszesz, grain rządzi tym, gdzie to trafia i jaki ma kształt. Jego jedyna zasada: znajdź najbliższy istniejący przykład, skopiuj jego kształt, nazwij to, co skopiowałeś. Nowy kod powinien czytać się tak, jakby napisała go ta sama osoba, która napisała plik obok.
Grain to także miejsce, w którym egzekwowana jest architektura. Nasz backend to dość standardowy układ vertical-slice + hexagonal — prezentacja woła aplikację, aplikacja woła domenę, infrastruktura zależy do wewnątrz, a domena nigdy nie sięga na zewnątrz. Ustalenie typu “ta trasa pomija swój kontroler i sięga bezpośrednio do serwisu” to nie pedanteria — to różnica między codebase, po którym agent będzie umiał się poruszać za miesiąc, a takim, po którym nie będzie. grain-review poluje dokładnie na takie rzeczy: zduplikowane helperty, przekroczone granice warstw, sięganie do wnętrzności innej funkcjonalności, druga konwencja dla czegoś, co już zostało zrobione jednym sposobem.
review-proof — zasłuż na ustalenie
Standardowy przegląd kodu przez AI produkuje wiarygodne ustalenia. Część jest prawdziwa; część to pewne siebie bzdury; z zewnątrz wyglądają identycznie. review-proof odmawia zaufania samemu sobie: recenzuje, a potem wymusza, by każde ustalenie dotyczące poprawności odtworzyło się jako prawdziwy failing test lub uruchamialny repro, i odrzuca wszystko, co tego nie zrobi. Zamyka się przejściem grain-review pod kątem dopasowania strukturalnego. Efekt to recenzja, w której każdy punkt ma wykonywalny dowód — nie wrażenie.
Co powinniśmy zobaczyć, jeśli to działa
- H1 — Usuwanie pojawia się w PR-ach z funkcjami. Jeśli ponytail + grain działają, dodawanie funkcji powinno często usuwać netto struktury, a nie tylko ją dodawać.
- H2 — Poprawki lądują raz, w miejscu wspólnym. Poprawki przyczyny źródłowej powinny zwijać wiele miejsc wywołań do jednej straży, a nie rozsypywać straże po wywołujących.
- H3 — Recenzja wychwytuje złamania kontraktu, które człowiek przegapia. Recenzja poparta dowodem powinna wydobywać błędy, które przegląd “wygląda dobrze” pomija — zwłaszcza te ciche.
Część 2 · I CO Z TEGO — pięć PR-ów, po jednym instynkcie każdy
Pięć prawdziwych zmian w naszym rdzeniu agentowym. Celowo trzymamy wnętrzności mgliste — repozytorium jest prywatne — ale liczby są policzone z rzeczywistych diffów, a wnioski to część, którą da się przenieść.
Odejmij: jedna straż dla kilkunastu miejsc pobierania
Jedna rodzina kroków przepływu pobierała URL-e podane przez użytkownika bez sprawdzenia bezpieczeństwa rozwiązującego DNS, więc nazwa hosta, która rozwiązywała się na adres wewnętrzny, mogła z backendu dotrzeć do metadanych chmury. Kusząca poprawka dodaje sprawdzenie w każdym z kilkunastu miejsc pobierania. Odpowiedź ponytaila była odwrotna: jeden wspólny, strzeżony helper pobierania, używany wszędzie — a my usunęliśmy ręcznie skleconą tabelę sieci prywatnych, którą trik z wildcardowym DNS przechodził na wylot, plus trzy zduplikowane pętle przekierowań i sprawdzenie sieci kopiowane do kilku plików.
Diff dodał wspólny helper i usunął ~90 linii duplikacji w 22 plikach. To usunięcie jest tu historią: to H2 wcielone w życie — poprawka przyczyny źródłowej przeprowadziła każdego wywołującego przez jedną straż zamiast łatać jedną ścieżkę wskazaną w zgłoszeniu.
Poprawka przyczyny źródłowej: kilkanaście doraźnych miejsc pobierania zwija się do jednego wspólnego, strzeżonego helpera. Leniwa poprawka i bezpieczna poprawka to ta sama poprawka.
Odejmij + udowodnij: jedna straż kształtu, udowodniona na prawdziwym runtime
Nasz runtime workerów utrwala wynik uruchomienia jako serializowany string, czasem opakowany w jednoelementową listę. Konsumenci oczekujący zwykłego obiektu wywalali się na tym. Zła poprawka rozsypuje defensywne sprawdzenia typów u każdego konsumenta. Zamiast tego: jeden mały helper normalizujący kształt i każdy konsument przekierowany na niego — niemal czyste dodanie jednej straży, które zastępuje N doraźnych, jakie napisałby mniej zdyscyplinowany agent (+558 / −24, 7 plików).
Częścią, która czyni z tego historię review-proof, jest test. Zamiast sprawdzać wobec założonego kształtu serializacji, przeprowadziliśmy prawdziwy workflow przez faktyczny runtime i storage — bez mocków — i udowodniliśmy kształt, który runtime faktycznie utrwala. Otwarte pytanie w zgłoszeniu brzmiało dosłownie: co runtime tu serializuje? — a jedyna uczciwa odpowiedź to taka, którą możesz uruchomić.
Udowodnij: recenzja wychwyciła ciche złamanie kontraktu
Funkcja: model fallbacku per węzeł, aby przepływ przypięty do jednego dostawcy mógł łagodnie degradować się podczas awarii. Oczywisty pierwszy szkic opakowywał model we wbudowany kombinator fallbacku frameworka.
Działało na ścieżce szczęśliwej. Wyłączyło też po cichu dwie funkcje dostawcy, które bramkują się na konkretnym typie modelu przez isinstance — opakowany obiekt nie jest już tym typem, więc natywne wyjście strukturalne i cache’owanie promptów oba po cichu się wyłączyły. Żadnego błędu. Żadnego failing testu na ścieżce szczęśliwej. Dokładnie to, co przegląd człowieka przegapia, a agent “wygląda dobrze” zatwierdza.
review-proof tego nie zatwierdził — odtworzył oba złamania jako failing testy, co wymusiło przeprojektowanie: zastosować fallback niżej, w czasie wykonania, aby każdy model pozostał swoim konkretnym typem, a funkcje bramkowane typem działały dalej. H3, potwierdzone jednoznacznie: dowód wychwycił błąd, który wiarygodność by wysłała.
Dopasuj: jeden picker, nie dwie kopie
Dodanie drugiego kanału powiadomień oznaczało, że UI wyboru kanału ma teraz dwa domy — kreator tworzenia i modal ustawień. Domyślny ruch agenta dodaje nową gałąź do obu, hodując dwie kopie tego samego automatu stanów. grain powiedział: już istnieje jeden sposób, w jaki to powinno być ukształtowane — zrób to wspólne. Wyodrębniliśmy jeden hook pickera i poprowadziliśmy przez niego oba ekrany, wsunęliśmy nowy kanał do istniejącej unii konfiguracji i użyliśmy ponownie istniejącej usługi e-mail zamiast dodawać nową maszynerię wysyłki.
+1 735 / −340 w 24 plikach. Funkcja tej wielkości usuwająca 340 linii to H1 w widocznej formie: deduplikacja dwóch kopii pickera w jedną zapłaciła za sporą część nowego kanału.
Dopasuj + udowodnij: użyj ponownie endpointu, odbij ścieżkę
Pozwolenie użytkownikom na załączanie plików przy tworzeniu zgłoszenia mogło oznaczać nowy endpoint uploadu, nowy mechanizm dyspozycji, nową ścieżkę promptu. grain skierował niemal wszystko na istniejące tory: istniejący endpoint uploadu, listę akceptowanych typów na froncie, która odbija dokładnie whitelistę backendu, oraz poprawkę odroczonej dyspozycji, która użyła ponownie mechanizmu kwalifikowalności już stosowanego przez zaplanowane zadania. Wyszło z poprawkami popartymi dowodem, w tym prawdziwym błędem izolacji transakcji, który zgubiłby dane przy równoległych uploadach. +1 776 / −218 w 27 plikach — duża funkcja, która mimo to znalazła 218 linii do usunięcia, dołączając do istniejących wycinków zamiast wymyślać nowe.
Tablica wyników
Pięć PR-ów Poziomu 3: co każdy dodał, co usunął i instynkt, który za tym stał.
Pięć PR-ów z funkcjami i poprawkami w rdzeniu agentowym usunęło 821 linii — nie przez robienie mniej, lecz przez odmowę duplikowania tego, co już istniało, i przez niedopuszczanie łatek objawowych, które poprawka przyczyny źródłowej uczyniła zbędnymi.
Pełne ujawnienie
- To umiejętności, nie badanie. To nie kontrolowany eksperyment z grupą bazową; to pięć prawdziwych PR-ów, w których zastosowano tę dyscyplinę. Scenariusz kontrfaktyczny — co ten sam agent dostarczyłby bez tych umiejętności — jest uświadomionym oszacowaniem, nie pomiarem. Historia z cichym złamaniem kontraktu jest najczystszym dowodem, bo widzieliśmy, jak recenzja odtwarza błąd przed przeprojektowaniem.
- Liczby linii to wartości zastępcze. −821 to prawdziwa liczba z diffów, ale “usunięte linie” zastępuje “unikniętą duplikację i martwą elastyczność”. Umiejętność, która odradza agentowi napisanie 200 spekulacyjnych linii, nie zostawia żadnego śladu w diffie — największe zwycięstwa są tu niewidoczne.
- Oszczędności tokenów mają charakter kierunkowy. Mniejsze diffy, mniej dotkniętych plików i ponownie użyte struktury oznaczają mniej tokenów zużytych na generowanie, recenzowanie i ponowne recenzowanie — ale nie podajemy twardej delty tokenów na PR.
ponytailnie jest nasz. To otwartoźródłowa umiejętność Dietricha Geberta ; zaadaptowaliśmy ją.grainireview-proofsą nasze, zbudowane w tym samym duchu. Wszystkie trzy działają jako lokalne umiejętności projektowe w Claude Code — prompt i procedura, nie binarka do zainstalowania.
Gotowy na rozwój swojej firmy?
Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.
Część 3 · CO DALEJ
Co zostało dostarczone. Trzy komponowalne umiejętności. ponytail i grain działają podczas pisania; ponytail-review, grain-review i review-proof działają na diffie. review-proof łańcuchuje grain-review jako swoją końcową fazę, więc jedna udowodniona recenzja dostaje też przegląd strukturalny za darmo.
Co możesz zrobić w poniedziałek — nie potrzebujesz naszych dokładnych umiejętności:
- Uczyń “użyj ponownie” szczeblem drugim, a nie dziesiątym. Zanim agent napisze helper, każ mu zgrepować taki, który istnieje. “Czy to już jest w tym codebase?” należy ponad “czy potrafię napisać to czysto?”
- Napraw u źródła, udowodnij listą wywołujących. Wymagaj, by każda poprawka błędu wymieniała każdego wywołującego dotkniętej funkcji. Jedna straż w funkcji wspólnej bije straż na wywołującego — i to mniejszy diff.
- Daj nowemu kodowi najbliższego sąsiada do skopiowania. “Znajdź najbliższy istniejący przykład i odbij jego kształt” zamienia architekturę z dokumentu, którego nikt nie czyta, w domyślne zachowanie agenta.
- Egzekwuj granice warstw w CI, nie na wyczucie. Zapadka, która wywala się tylko na nowych importach między warstwami, pozwala trzymać linię bez gotowania oceanu istniejącego długu.
- Nie dostarczaj ustalenia, którego nie potrafisz odtworzyć. Każ agentowi najpierw napisać failing test. Jeśli nie potrafi sprawić, by błąd się odtworzył, to nie błąd — to opinia. Odrzuć ją.
- Pozwól recenzji usuwać. Skieruj przebieg recenzji konkretnie na over-engineering — “co możemy wyciąć” — osobno od poprawności. Najlepszym wynikiem diffa jest to, że staje się krótszy.
Wypróbuj to, zwłaszcza jeśli u ciebie nie zadziała. Jeśli uruchamiasz agentów kodujących na prawdziwym codebase, entropia już się dzieje — po prostu jej nie zmierzyłeś. Zamień jedną z tych rzeczy w przebieg recenzji w swoich następnych dziesięciu PR-ach agenta i policz usunięcia. Jeśli odejmij-dopasuj-udowodnij nie zmniejsza twoich diffów albo nie wychwytuje cichego złamania, naprawdę chcielibyśmy o tym usłyszeć. Korekty i kontrprzykłady szczególnie mile widziane.
Agent dodaje. Zadanie polega na tym, by agent zasłużył na każdą linię.
