Le dăm agenților de codare tichete reale în fiecare zi și aproape întotdeauna livrează ceva ce funcționează. Asta nu a fost niciodată problema. Problema este cum lucrează: un helper nou lângă alți trei care fac deja treaba, o abstracție nouă pentru un singur apelant, o remediere care repară exact calea numită în tichet și lasă patru frați stricați, o constatare care este “probabil un bug” fără nicio dovadă într-un sens sau altul. Fiecare schimbare este rezonabilă local. În agregat, sunt entropie.
TL;DR: În cinci pull request-uri de Nivel 3 pe nucleul nostru de orchestrare a agenților, trei abilități combinabile —
ponytail(scade),grain(aliniază) șireview-proof(demonstrează) — au eliminat 821 de linii livrând cinci funcționalități, au prins o ruptură silențioasă de contract pe care doar plauzibilitatea ar fi integrat-o și au menținut fiecare schimbare în fibra arhitecturii existente. Iată ce face fiecare, cu diff-urile reale ca dovadă.
Scoate gardurile de protecție și un agent de codare devine un generator foarte rapid de răspunderi care par plauzibile. Așa că ne sprijinim pe trei abilități mici care împing în direcția opusă — câte un instinct fiecare: scade, aliniază, demonstrează.
ponytail— scrie cel mai leneș lucru care chiar funcționează. Șterge înainte să adaugi. (Pe acesta nu l-am scris noi — este o abilitate open-source de Dietrich Gebert pe care am adaptat-o pentru stack-ul nostru.)grain/grain-review— pune-l acolo unde baza de cod a decis deja că îi este locul. Nu inventa un al doilea mod.review-proof— nu crede o constatare până nu se reproduce ca test care eșuează.
grain și review-proof le-am construit în același spirit ca ponytail, reglate pentru arhitectura noastră. Fiecare dintre cele cinci PR-uri de mai jos atinge nucleul nostru de orchestrare a agenților — cel mai scump loc din repo în care să fii neglijent — și fiecare este clasificat Nivel 3: acoperire suplimentară de teste și revizuire umană peste revizuitorul automat, fără excepții.
Cele trei abilități dintr-o privire: ponytail scade, grain aliniază, review-proof demonstrează.
Partea 1 · CE — entropia este starea implicită
Iată lucrul despre care nu te avertizează nimeni când dai un repo pe mâna agenților AI: fiecare agent optimizează local și nu-și amintește nimic. Vede tichetul, nu lunile de convenții la care a ajuns echipa ta. Nu are niciun motiv să prefere serviciul tău de email existent în locul unuia nou, nicio memorie că setul de statusuri de redirect este deja definit cu trei fișiere mai încolo, niciun instinct că “remedierea merge în funcția partajată, nu în acest singur apelant”. Lăsați să ruleze, N agenți produc N moduri ușor diferite de a face același lucru. Nu este o problemă de calitate a codului pe care o poți elimina cu un linter — este o derivă structurală care se acumulează.
Cele trei abilități țintesc fiecare câte o axă a acelei derive.
ponytail — cel mai leneș lucru care funcționează
Ponytail este un dezvoltator senior care a fost chemat la 3 dimineața din cauza abstracției deștepte a altcuiva și refuză să o scrie pe următoarea. Rulează o scară și se oprește la prima treaptă care ține: trebuie să existe deloc (YAGNI) → este deja în această bază de cod → o face biblioteca standard → funcționalitate nativă a platformei → dependență deja instalată → poate fi o singură linie → abia apoi, codul minim care funcționează.
Treapta care contează cel mai mult pentru agenți este “este deja în această bază de cod?” Reimplementarea a ceea ce se află la câteva fișiere distanță este cea mai comună formă de mizerie produsă de agenți. Iar regula lui ponytail pentru remedierea bug-urilor ține diff-urile oneste: repară cauza rădăcină, nu simptomul. Fă grep pe fiecare apelant al funcției pe care urmează să o atingi; o singură protecție în funcția partajată este un diff mai mic decât o protecție în fiecare apelant — și nu lasă frații stricați.
grain / grain-review — mergi cu fibra
Dacă ponytail guvernează cât de puțin scrii, grain guvernează unde ajunge și ce formă ia. Regula lui unică: găsește cel mai apropiat exemplu existent, copiază-i forma, numește ce ai copiat. Codul nou ar trebui să se citească de parcă persoana care a scris fișierul alăturat l-ar fi scris și pe acesta.
Grain este și locul unde se impune arhitectura. Backend-ul nostru este un layout destul de standard de vertical-slice + hexagonal — prezentarea apelează aplicația, aplicația apelează domeniul, infrastructura depinde spre interior, iar domeniul nu ajunge niciodată înapoi spre exterior. O constatare de tipul “această rută ocolește controllerul și trage serviciul direct” nu este pedanterie — este diferența dintre o bază de cod pe care un agent o poate naviga luna viitoare și una pe care nu o poate. grain-review vânează exact acestea: helperi duplicați, granițe de strat încălcate, pătrunderea în interiorul altei funcționalități, o a doua convenție pentru ceva ce se face deja într-un singur fel.
review-proof — câștigă-ți constatarea
Revizuirea standard de cod AI produce constatări plauzibile. Unele sunt reale; altele sunt nonsens încrezător; din exterior arată identic. review-proof refuză să aibă încredere în sine: revizuiește, apoi forțează fiecare constatare de corectitudine să se reproducă ca test real care eșuează sau ca repro rulabil, și elimină tot ce nu reușește. Încheie cu o trecere grain-review pentru potrivire structurală. Ce se livrează este o revizuire în care fiecare element vine cu dovezi executabile — nu cu o impresie.
Ce ar trebui să vedem dacă funcționează
- H1 — Ștergerea apare în PR-urile de funcționalități. Dacă ponytail + grain funcționează, adăugarea unei funcționalități ar trebui să elimine frecvent structură netă, nu doar să adauge.
- H2 — Remediile ajung o dată, în locul partajat. Remediile cauzei rădăcină ar trebui să colapseze multe locuri de apel într-o singură protecție, nu să presare protecții per apelant.
- H3 — Revizuirea prinde rupturi de contract pe care un om le sare cu privirea. Revizuirea susținută de dovezi ar trebui să scoată la suprafață bug-uri pe care revizuirea de tip “pare în regulă” le ratează — mai ales cele silențioase.
Partea 2 · ȘI CE — cinci PR-uri, câte un instinct fiecare
Cinci schimbări reale în nucleul nostru de agenți. Păstrăm intenționat detaliile interne vagi — repo-ul este privat — dar cifrele sunt calculate din diff-urile reale, iar lecțiile sunt partea transferabilă.
Scade: o singură protecție pentru o duzină de locuri de fetch
O familie de pași de flux prelua URL-uri furnizate de utilizatori fără o verificare de siguranță care rezolvă DNS, astfel încât un hostname care se rezolva către o adresă internă putea ajunge la metadatele cloud din backend. Remedierea tentantă adaugă o verificare la fiecare dintre cele peste o duzină de locuri de fetch. Răspunsul lui ponytail a fost opusul: un singur helper de fetch partajat și protejat, folosit peste tot — și am șters un tabel de rețea privată scris manual, pe lângă care un truc de DNS wildcard a trecut direct, plus trei bucle de redirect duplicate și o verificare de rețea copiată-lipită în mai multe fișiere.
Diff-ul a adăugat helperul partajat și a eliminat ~90 de linii de duplicare în 22 de fișiere. Acea ștergere este povestea: acesta este H2 în carne și oase — remedierea cauzei rădăcină a direcționat fiecare apelant prin aceeași protecție, în loc să repare singura cale numită în tichet.
Remedierea cauzei rădăcină: o duzină de locuri de fetch ad-hoc se colapsează într-un singur helper partajat și protejat. Remedierea leneșă și remedierea sigură sunt aceeași remediere.
Scade + demonstrează: o singură protecție de formă, demonstrată pe runtime-ul real
Runtime-ul nostru de worker persistă rezultatul unei rulări ca șir serializat, uneori împachetat într-o listă cu un singur element. Consumatorii care se așteptau la un obiect simplu se blocau. Remedierea greșită împrăștie verificări de tip defensive la fiecare consumator. În schimb: un mic helper de normalizare a formei, iar fiecare consumator este reorientat către el — o adăugare aproape pură a unei protecții care înlocuiește cele N ad-hoc pe care le-ar fi scris un agent mai puțin disciplinat (+558 / −24, 7 fișiere).
Partea care face din asta o poveste review-proof este testul. În loc să verificăm pe baza unei forme de serializare presupuse, am rulat un workflow real prin runtime-ul și storage-ul efective — fără mock-uri — și am demonstrat forma pe care runtime-ul o persistă efectiv. Întrebarea deschisă din tichet era literalmente ce serializează runtime-ul aici? — iar singurul răspuns onest este unul pe care îl poți rula.
Demonstrează: revizuirea a prins o ruptură silențioasă de contract
Funcționalitate: un model de rezervă per nod, astfel încât un flux fixat pe un singur furnizor să degradeze elegant în timpul unei întreruperi. Prima variantă evidentă împacheta modelul în combinatorul de fallback integrat al framework-ului.
Funcționa pe calea fericită. De asemenea, a dezactivat silențios două funcționalități ale furnizorului care se bazează pe tipul concret al modelului prin isinstance — un obiect împachetat nu mai este acel tip, așa că output-ul structurat nativ și cache-ul de prompt s-au oprit amândouă fără zgomot. Nicio eroare. Niciun test pe calea fericită care să eșueze. Exact genul de lucru pe care o revizuire umană îl sare cu privirea și pe care un agent de tip “pare în regulă” îl aprobă.
review-proof nu l-a aprobat — a reprodus ambele rupturi ca teste care eșuează, ceea ce a forțat reproiectarea: aplică fallback-ul mai jos, la momentul execuției, astfel încât fiecare model să rămână tipul său concret și funcționalitățile condiționate de tip să continue să funcționeze. H3, confirmat fără echivoc: dovada a prins un bug pe care plauzibilitatea l-ar fi livrat.
Aliniază: un singur selector, nu două copii
Adăugarea unui al doilea canal de notificare a însemnat că UI-ul de selectare a canalului avea acum două locuințe — un wizard de creare și un modal de setări. Mișcarea implicită a agentului adaugă noua ramură în ambele, generând două copii ale aceleiași mașini de stări. grain a spus: există deja un singur mod în care ar trebui modelat — fă-l partajat. Am extras un singur hook de selectare și am condus ambele ecrane prin el, am încadrat noul canal în uniunea de configurare existentă și am refolosit serviciul de email existent, în loc să adăugăm mașinărie nouă de trimitere.
+1.735 / −340 în 24 de fișiere. O funcționalitate de această dimensiune care elimină 340 de linii este H1 făcut vizibil: deduplicarea a două copii ale selectorului într-una singură a plătit o bună parte din noul canal.
Aliniază + demonstrează: refolosește endpoint-ul, oglindește calea
Permiterea utilizatorilor să atașeze fișiere la crearea unui tichet ar fi putut însemna un nou endpoint de upload, un nou mecanism de dispatch, o nouă cale de prompt. grain a direcționat aproape totul pe șine existente: endpoint-ul de upload existent, o listă de acceptare în frontend care oglindește exact lista albă din backend și o remediere a dispatch-ului amânat care a refolosit mecanismul de eligibilitate pe care îl folosea deja munca programată. S-a livrat cu remedieri susținute de dovezi, inclusiv un bug real de izolare a tranzacțiilor care ar fi pierdut date la upload-uri paralele. +1.776 / −218 în 27 de fișiere — o funcționalitate mare care a găsit totuși 218 linii de eliminat alăturându-se felilor existente, în loc să inventeze altele noi.
Tabelul de scor
Cinci PR-uri de Nivel 3: ce a adăugat fiecare, ce a eliminat și instinctul din spate.
Cinci PR-uri de funcționalități și remedieri pe nucleul de agenți au eliminat 821 de linii — nu făcând mai puțin, ci refuzând să duplice ce exista deja și să păstreze peticele de simptom pe care o remediere a cauzei rădăcină le-a făcut redundante.
Dezvăluire completă
- Acestea sunt abilități, nu un studiu. Nu este un experiment controlat cu o ramură de referință; sunt cinci PR-uri reale în care disciplina a fost aplicată. Contrafactualul — ce ar fi livrat același agent fără abilități — este o estimare informată, nu o măsurătoare. Povestea rupturii silențioase de contract este cea mai curată dovadă, pentru că am văzut revizuirea reproducând bug-ul înainte de reproiectare.
- Numărul de linii este un proxy. −821 este un număr real din diff-uri, dar “linii eliminate” ține locul pentru “duplicare și flexibilitate moartă evitate”. O abilitate care convinge un agent să nu scrie 200 de linii speculative nu lasă nicio urmă într-un diff — cele mai mari câștiguri sunt invizibile aici.
- Economiile de tokeni sunt orientative. Diff-uri mai mici, mai puține fișiere atinse și structuri refolosite înseamnă mai puțini tokeni consumați pentru generare, revizuire și re-revizuire — dar nu cităm o deltă dură de tokeni per PR.
ponytailnu este al nostru. Este o abilitate open-source de Dietrich Gebert ; am adaptat-o.grainșireview-proofsunt ale noastre, construite în același spirit. Toate trei rulează ca abilități locale de proiect pe Claude Code — prompt și procedură, nu un binar pe care îl instalezi.
Pregătit să îți dezvolți afacerea?
Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.
Partea 3 · CE URMEAZĂ
Ce s-a livrat. Trei abilități combinabile. ponytail și grain rulează în timpul scrierii; ponytail-review, grain-review și review-proof rulează pe un diff. review-proof înlănțuie grain-review ca fază finală, astfel încât o singură revizuire demonstrată primește gratuit și o trecere structurală.
Ce poți face luni — nu ai nevoie de abilitățile noastre exacte:
- Fă din “refolosire” a doua treaptă, nu a zecea. Înainte ca un agent să scrie un helper, pune-l să facă grep după unul care există. “Este deja în această bază de cod?” se află deasupra lui “pot să-l scriu curat?”
- Remediază la rădăcină, demonstrează cu lista de apelanți. Cere fiecărei remedieri de bug să numească fiecare apelant al funcției atinse. O protecție în funcția partajată bate o protecție per apelant — și este un diff mai mic.
- Dă codului nou un frate apropiat de copiat. “Găsește cel mai apropiat exemplu existent și oglindește-i forma” transformă arhitectura dintr-un document pe care nimeni nu-l citește într-un comportament implicit pe care agentul îl urmează.
- Impune granițele de strat în CI, nu prin impresii. Un mecanism de tip ratchet care eșuează doar la importurile noi care traversează straturi îți permite să ții linia fără să fierbi oceanul datoriei existente.
- Nu livra o constatare pe care nu o poți reproduce. Pune agentul să scrie mai întâi testul care eșuează. Dacă nu poate face bug-ul să se reproducă, nu este un bug — este o opinie. Renunță la el.
- Lasă revizuirea să șteargă. Îndreaptă o trecere de revizuire specific către supra-inginerie — “ce putem tăia” — separat de corectitudine. Cel mai bun rezultat al unui diff este să devină mai scurt.
Încearcă, mai ales dacă pentru tine eșuează. Dacă rulezi agenți de codare pe o bază de cod reală, entropia se întâmplă deja — doar că nu ai măsurat-o. Transformă una dintre acestea într-o trecere de revizuire la următoarele zece PR-uri de agent și numără ștergerile. Dacă scade-aliniază-demonstrează nu micșorează diff-urile tale și nu prinde o ruptură silențioasă, ne-ar plăcea sincer să aflăm. Corecturile și contraexemplele sunt mai mult decât binevenite.
Un agent adaugă. Treaba este să faci agentul să merite fiecare linie.
