Každý den předáváme coding agentům skutečné tikety a oni téměř vždy dodají něco, co funguje. To nikdy nebyl problém. Problém je jak pracují: nový helper vedle tří, které už tu práci dělají, čerstvá abstrakce pro jediného volajícího, oprava, která záplatuje jednu cestu zmíněnou v tiketu a nechá čtyři sourozence rozbité, nález, který je „pravděpodobně bug" bez jakéhokoli důkazu na jednu či druhou stranu. Každá změna je lokálně rozumná. V souhrnu jsou to entropie.
TL;DR: Napříč pěti pull requesty Tier 3 na našem jádru pro orchestraci agentů tři komponovatelné dovednosti —
ponytail(odečíst),grain(srovnat) areview-proof(dokázat) — odstranily 821 řádků, a přitom dodaly pět funkcí, zachytily tichý rozpad kontraktu, který by samotná věrohodnost nechala mergnout, a udržely každou změnu v souladu s existující architekturou. Tady je, co každá z nich dělá, s reálnými diffy na podporu.
Vezměte agentovi zábrany a je to velmi rychlý generátor věrohodně vypadajících závazků. Proto se opíráme o tři malé dovednosti, které tlačí opačným směrem — jeden instinkt každá: odečíst, srovnat, dokázat.
ponytail— napiš tu nejlínější věc, která skutečně funguje. Než přidáš, smaž. (Tuhle jsme nenapsali — je to open-source dovednost od Dietricha Geberta , kterou jsme si přizpůsobili pro náš stack.)grain/grain-review— umísti to tam, kde už se codebase rozhodla, že to patří. Nevymýšlej druhý způsob.review-proof— nevěř nálezu, dokud se nereprodukuje jako padající test.
grain a review-proof jsme postavili ve stejném duchu jako ponytail, vyladěné na naši architekturu. Každý z pěti PR níže se dotýká našeho jádra pro orchestraci agentů — nejdražšího místa v repu, kde je nedbalost nejdražší — a každý je klasifikován jako Tier 3: navíc testovací pokrytí a lidská revize nad automatickým recenzentem, bez výjimek.
Tři dovednosti v kostce: ponytail odečítá, grain srovnává, review-proof dokazuje.
Část 1 · CO — entropie je výchozí stav
Tady je věc, před kterou vás nikdo nevaruje, když předáte repo AI agentům: každý agent optimalizuje lokálně a nic si nepamatuje. Vidí tiket, ne měsíce konvencí, na kterých se váš tým shodl. Nemá důvod preferovat vaši existující e-mailovou službu před novou, nemá v paměti, že sada přesměrovacích statusů je už definovaná o tři soubory dál, nemá instinkt, že „oprava patří do sdílené funkce, ne do tohoto jednoho volajícího". Ponecháni běžet, N agentů vytvoří N mírně odlišných způsobů, jak dělat totéž. To není problém kvality kódu, který vyřešíte linterem — je to strukturální drift, který se sčítá.
Každá ze tří dovedností cílí na jednu osu tohoto driftu.
ponytail — nejlínější věc, která funguje
Ponytail je seniorní vývojář, kterého ve 3 ráno budili kvůli něčí chytré abstrakci, a odmítá napsat tu další. Prochází žebřík a zastaví se na první příčce, která drží: musí to vůbec existovat (YAGNI) → je to už v této codebase → umí to standardní knihovna → nativní funkce platformy → už nainstalovaná závislost → dá se to napsat na jeden řádek → teprve pak minimální kód, který funguje.
Příčka, která je pro agenty nejdůležitější, je „je to už v této codebase?" Znovu implementovat něco, co je o pár souborů dál, je nejčastější forma agentího slopu. A ponytailovo pravidlo pro opravy bugů drží diffy čestné: oprav kořenovou příčinu, ne symptom. Projdi grepem každého volajícího funkce, které se chystáš dotknout; jedna pojistka ve sdílené funkci je menší diff než pojistka v každém volajícím — a nenechá sourozence rozbité.
grain / grain-review — drž se vlákna
Zatímco ponytail řídí jak málo píšeš, grain řídí kam to patří a jaký to má tvar. Jeho jediné pravidlo: najdi nejbližší existující příklad, zkopíruj jeho tvar, pojmenuj, co jsi zkopíroval. Nový kód by měl působit, jako by ho napsal ten, kdo napsal soubor vedle.
Grain je také místo, kde se vynucuje architektura. Náš backend je celkem standardní vertical-slice + hexagonální uspořádání — presentation volá application, application volá domain, infrastruktura závisí směrem dovnitř a doména nikdy nesahá zpět ven. Nález jako „tato routa obchází svůj controller a tahá službu přímo" není pedantství — je to rozdíl mezi codebase, ve které se agent příští měsíc zorientuje, a tou, ve které ne. grain-review loví přesně tyto věci: duplikované helpery, překročené hranice vrstev, sahání do vnitřností jiné části systému, druhá konvence pro něco, co se už dělá jedním způsobem.
review-proof — vysluž si nález
Standardní AI code review produkuje věrohodné nálezy. Některé jsou skutečné; některé jsou sebevědomý nesmysl; zvenčí vypadají identicky. review-proof si odmítá věřit: nejdřív recenzuje, pak nutí každý nález týkající se správnosti reprodukovat jako skutečný padající test nebo spustitelný repro, a cokoli, co to nezvládne, zahodí. Končí průchodem grain-review pro strukturální soulad. Co dodá, je review, kde každá položka přichází se spustitelným důkazem — ne s pocitem.
Co bychom měli vidět, pokud to funguje
- H1 — Mazání se objevuje ve feature PR. Pokud ponytail + grain fungují, přidání funkce by mělo často odebírat čistou strukturu, ne jen přidávat.
- H2 — Opravy se objeví jednou, na sdíleném místě. Opravy kořenové příčiny by měly sloučit mnoho volajících míst do jedné pojistky, ne rozsypat pojistky po každém volajícím.
- H3 — Review zachytí rozpad kontraktu, který člověk přehlédne. Review podložené důkazem by mělo odhalit bugy, které review typu „vypadá to dobře" mine — hlavně ty tiché.
Část 2 · A CO Z TOHO — pět PR, jeden instinkt každý
Pět skutečných změn v našem agentím jádru. Vnitřnosti záměrně držíme vágní — repo je soukromé — ale čísla jsou spočítaná ze skutečných diffů a přenositelná je lekce.
Odečíst: jedna pojistka pro tucet míst s fetchem
Jedna rodina kroků flow stahovala uživatelsky zadané URL bez bezpečnostní kontroly, která by resolvovala DNS, takže hostname, který se resolvoval na interní adresu, mohl z backendu dosáhnout na cloudová metadata. Lákavá oprava přidá kontrolu na každé z více než tuctu míst s fetchem. Ponytailova odpověď byla opačná: jeden sdílený, hlídaný fetch helper, používaný všude — a smazali jsme ručně psanou tabulku privátních sítí, kterou trik s wildcard DNS hravě obešel, plus tři duplikované smyčky přesměrování a síťovou kontrolu zkopírovanou do několika souborů.
Diff přidal sdílený helper a odstranil ~90 řádků duplikace ve 22 souborech. To mazání je ten příběh: tohle je H2 v praxi — oprava kořenové příčiny provedla každého volajícího jednou pojistkou místo záplatování jedné cesty zmíněné v tiketu.
Oprava kořenové příčiny: tucet ad-hoc míst s fetchem se sbíhá do jednoho sdíleného, hlídaného helperu. Líná oprava a bezpečná oprava jsou ta samá oprava.
Odečíst + dokázat: jedna pojistka na tvar, dokázaná na skutečném runtime
Náš worker runtime ukládá výsledek běhu jako serializovaný string, někdy zabalený do jednoprvkového seznamu. Konzumenti, kteří očekávali prostý objekt, na tom padali. Špatná oprava rozsype obranné typové kontroly do každého konzumenta. Místo toho: jeden malý helper normalizující tvar a každý konzument na něj přesměrovaný — téměř čisté přidání jedné pojistky, které nahrazuje N ad-hoc pojistek, jež by napsal méně disciplinovaný agent (+558 / −24, 7 souborů).
To, co z toho dělá příběh review-proof, je test. Místo tvrzení proti předpokládanému tvaru serializace jsme spustili skutečný workflow skrz skutečný runtime a úložiště — žádné mocky — a dokázali tvar, který runtime skutečně ukládá. Otevřená otázka v tiketu byla doslova co tady runtime serializuje? — a jediná čestná odpověď je ta, kterou můžete spustit.
Dokázat: review zachytilo tichý rozpad kontraktu
Funkce: fallback model na uzel, aby flow připnutý k jednomu poskytovateli během výpadku degradoval elegantně. Zjevná první verze obalila model vestavěným fallback combinátorem frameworku.
Fungovalo to ve šťastné cestě. Také to ale tiše vypnulo dvě funkce poskytovatele, které se přes isinstance řídí konkrétním typem modelu — obalený objekt už tím typem není, takže nativní strukturovaný výstup i prompt caching se tiše vypnuly. Žádná chyba. Žádný padající test šťastné cesty. Přesně ten druh věci, který lidské review přehlédne a agent s „vypadá to dobře" schválí.
review-proof to neschválil — reprodukoval oba rozpady jako padající testy, což vynutilo redesign: aplikovat fallback níž, v čase exekuce, aby každý model zůstal svým konkrétním typem a funkce řízené typem dál fungovaly. H3, rozhodně potvrzeno: důkaz zachytil bug, který by věrohodnost dodala.
Srovnat: jeden picker, ne dvě kopie
Přidání druhého oznamovacího kanálu znamenalo, že UI pro výběr kanálu mělo teď dva domovy — create wizard a settings modal. Výchozí tah agenta přidá novou větev do obou, čímž vzniknou dvě kopie téhož stavového automatu. grain řekl: existuje už jeden způsob, jak to má být tvarované — udělej to sdílené. Vytáhli jsme jediný picker hook a obě obrazovky přes něj řídili, nový kanál zasunuli do existující konfigurační unie a znovu použili existující e-mailovou službu místo přidání nové odesílací mašinérie.
+1,735 / −340 ve 24 souborech. Funkce této velikosti, která odstraní 340 řádků, je H1 zviditelněné: deduplikace dvou kopií pickeru do jedné zaplatila pořádný kus nového kanálu.
Srovnat + dokázat: znovu použij endpoint, zrcadli cestu
Možnost přikládat soubory při vytváření issue mohla znamenat nový upload endpoint, nový mechanismus dispatch, novou cestu pro prompt. grain nasměroval téměř vše na existující koleje: existující upload endpoint, frontendový seznam povolených typů, který přesně zrcadlí backendový whitelist, a opravu odloženého dispatch, která znovu použila mechanismus způsobilosti, jaký už používala plánovaná práce. Dodáno s opravami podloženými důkazem, včetně skutečného bugu s izolací transakcí, který by při paralelních uploadech ztratil data. +1,776 / −218 ve 27 souborech — velká funkce, která i tak našla 218 řádků ke smazání tím, že se napojila na existující slicy místo vymýšlení nových.
Skóre
Pět PR Tier 3: co každé přidalo, co odstranilo a jaký instinkt za tím byl.
Pět feature a fix PR na agentím jádru odstranilo 821 řádků — ne tím, že by dělalo méně, ale tím, že odmítlo duplikovat, co už existovalo, a udržovat záplaty symptomů, které oprava kořenové příčiny udělala nadbytečnými.
Plné zveřejnění
- Tohle jsou dovednosti, ne studie. Není to kontrolovaný experiment s baseline větví; je to pět skutečných PR, na které se disciplína aplikovala. Kontrafaktuál — co by stejný agent dodal bez dovedností — je informovaný odhad, ne měření. Příběh tichého rozpadu kontraktu je nejčistší důkaz, protože jsme viděli review reprodukovat bug před redesignem.
- Počty řádků jsou proxy. Těch −821 je skutečné číslo z diffů, ale „odstraněné řádky" zastupuje „vyhnutí se duplikaci a mrtvé flexibilitě". Dovednost, která agenta přemluví, aby nenapsal 200 spekulativních řádků, nezanechá v diffu žádnou stopu — největší výhry jsou tady neviditelné.
- Úspory tokenů jsou orientační. Menší diffy, méně dotčených souborů a znovupoužité struktury znamenají méně tokenů utracených za generování, review a re-review — ale necitujeme tvrdou deltu tokenů na PR.
ponytailnení náš. Je to open-source dovednost od Dietricha Geberta ; přizpůsobili jsme si ji.grainareview-proofjsou naše, postavené ve stejném duchu. Všechny tři běží jako lokální projektové dovednosti na Claude Code — prompt a procedura, ne binárka, kterou instalujete.
Připraveni rozšířit své podnikání?
Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.
Část 3 · A CO DÁL
Co se dodalo. Tři komponovatelné dovednosti. ponytail a grain běží během psaní; ponytail-review, grain-review a review-proof běží na diffu. review-proof řetězí grain-review jako svou závěrečnou fázi, takže jediné podložené review dostane i strukturální průchod zdarma.
Co můžete udělat v pondělí — nepotřebujete přesně naše dovednosti:
- Udělejte z „znovupoužij" druhou příčku, ne desátou. Než agent napíše helper, ať si vygrepuje, jestli nějaký existuje. „Je to už v této codebase?" patří nad „umím to napsat čistě?"
- Opravuj u kořene, dokaž to seznamem volajících. Vyžaduj, aby každá oprava bugu pojmenovala každého volajícího dotčené funkce. Jedna pojistka ve sdílené funkci porazí pojistku v každém volajícím — a je to menší diff.
- Dejte novému kódu nejbližšího sourozence ke kopírování. „Najdi nejbližší existující příklad a zrcadli jeho tvar" promění architekturu z dokumentu, který nikdo nečte, ve výchozí nastavení, které agent následuje.
- Vynucujte hranice vrstev v CI, ne pocitem. Ratchet, který padá jen na nových importech přes hranice vrstev, vám umožní držet linii, aniž byste vařili oceán existujícího dluhu.
- Nedodávejte nález, který nedokážete reprodukovat. Přinuťte agenta nejdřív napsat padající test. Pokud nedokáže bug reprodukovat, není to bug — je to názor. Zahoďte to.
- Nechte review mazat. Namiřte jeden průchod review specificky na over-engineering — „co můžeme uříznout" — odděleně od správnosti. Nejlepší výsledek diffu je, že se zkrátí.
Vyzkoušejte to, zvlášť pokud to u vás selže. Pokud používáte coding agenty na skutečné codebase, entropie už probíhá — jen jste ji neměřili. Proměňte jednu z těchto věcí v průchod review na svých příštích deseti agentích PR a spočítejte mazání. Pokud subtract-align-prove nezmenší vaše diffy nebo nezachytí tichý rozpad, opravdu to rádi uslyšíme. Opravy a protipříklady vítáme obzvlášť.
Agent přidává. Úkolem je přimět agenta, aby si každý řádek vysloužil.
