Trekk fra, tilpass, bevis: Tre ferdigheter som hindrer AI-agenter i å spaghettifisere repoet ditt

Vi gir kodeagenter ekte tickets hver dag, og de leverer nesten alltid noe som fungerer. Det var aldri bekymringen. Bekymringen er hvordan de jobber: en ny hjelpefunksjon ved siden av tre som allerede gjør jobben, en fersk abstraksjon for én enkelt kaller, en fiks som lapper den ene stien ticketen nevnte og lar fire søsken stå ødelagt, et funn som «sannsynligvis er en bug» uten bevis i noen retning. Hver endring er lokalt fornuftig. Samlet er de entropi.

TL;DR: På tvers av fem Tier-3-pull-forespørsler i kjernen for agent-orkestrering fjernet tre komponerbare ferdigheter — ponytail (trekk fra), grain (tilpass) og review-proof (bevis) — 821 linjer mens de leverte fem funksjoner, fanget et stille kontraktsbrudd som plausibilitet alene ville ha sluppet gjennom, og holdt hver endring i pakt med den eksisterende arkitekturen. Her er hva hver av dem gjør, med de ekte diffene som bevis.

Fjerner du rekkverkene, er en kodeagent en svært rask generator av byrder som ser plausible ut. Derfor lener vi oss på tre små ferdigheter som presser i motsatt retning — ett instinkt hver: trekk fra, tilpass, bevis.

• ponytail — skriv det lateste som faktisk virker. Slett før du legger til. (Denne skrev ikke vi — det er en åpen kildekode-ferdighet av Dietrich Gebert som vi tilpasset til stacken vår.)
• grain / grain-review — legg det der kodebasen allerede har bestemt at det skal ligge. Ikke finn opp en andre måte.
• review-proof — tro ikke på et funn før det reproduserer som en feilende test.

grain og review-proof bygget vi i samme ånd som ponytail, tunet til arkitekturen vår. Hver av de fem PR-ene nedenfor berører kjernen for agent-orkestrering — det enkeltstedet i repoet der det er dyrest å være slurvete — og alle er klassifisert som Tier 3: ekstra testdekning og menneskelig gjennomgang på toppen av den automatiske gjennomgangen, uten unntak.

De tre ferdighetene i et overblikk: ponytail trekker fra, grain tilpasser, review-proof beviser.

Del 1 · HVA — entropi er utgangspunktet

Her er det ingen advarer deg om når du overlater et repo til AI-agenter: hver agent optimaliserer lokalt og husker ingenting. Den ser ticketen, ikke alle månedene med konvensjoner teamet ditt har konvergert mot. Den har ingen grunn til å foretrekke den eksisterende e-posttjenesten din fremfor en ny, ingen hukommelse om at settet med redirect-statusser allerede er definert tre filer lenger borte, ingen instinkt om at «fiksen hører hjemme i den delte funksjonen, ikke hos denne ene kalleren». Får de løpe fritt, produserer N agenter N litt ulike måter å gjøre det samme på. Det er ikke et kodekvalitetsproblem du kan linte bort — det er en strukturell utglidning som forsterker seg.

De tre ferdighetene angriper hver sin akse av denne utglidningen.

ponytail — det lateste som faktisk virker

Ponytail er en seniorutvikler som har blitt ringt klokka 03 for noen andres smarte abstraksjon og som nekter å skrive den neste. Den går nedover en stige og stopper på første trinn som holder: trenger dette å eksistere i det hele tatt (YAGNI) → finnes det allerede i denne kodebasen → gjør standardbiblioteket det → innebygd plattformfunksjon → allerede installert avhengighet → kan det være én linje → først da: minimumskoden som virker.

Trinnet som betyr mest for agenter, er «finnes det allerede i denne kodebasen?» Å reimplementere noe som ligger noen filer unna, er den desidert vanligste formen for agent-søl. Og ponytails bugfiks-regel holder diffene ærlige: fiks rotårsaken, ikke symptomet. Grep alle kallere av funksjonen du er i ferd med å røre; én vakt i den delte funksjonen er en mindre diff enn én vakt hos hver kaller — og den lar ikke søsknene stå ødelagt.

grain / grain-review — gå med hårene

Hvis ponytail styrer hvor lite du skriver, styrer grain hvor det havner og hvilken form det får. Dens ene regel: finn det nærmeste eksisterende eksempelet, kopier formen, og navngi det du kopierte. Ny kode bør leses som om personen som skrev filen ved siden av, også skrev denne.

Grain er også der arkitekturen håndheves. Backenden vår er en ganske standard vertical-slice + hexagonal oppbygning — presentasjon kaller applikasjon kaller domene, infrastruktur avhenger innover, og domenet strekker seg aldri utover igjen. Et funn som «denne ruten hopper over controlleren sin og henter tjenesten direkte» er ikke pedanteri — det er forskjellen mellom en kodebase en agent kan navigere i neste måned og en den ikke kan. grain-review jakter nøyaktig disse: dupliserte hjelpefunksjoner, kryssede laggrenser, inngrep i en annen funksjons interne deler, en andre konvensjon for noe som allerede er gjort på én måte.

review-proof — gjør deg fortjent til funnet

Standard AI-kodegjennomgang produserer plausible funn. Noen er ekte; noen er selvsikre vås; utenfra ser de identiske ut. review-proof nekter å stole på seg selv: den gjennomgår, og tvinger deretter hvert korrekthetsfunn til å reprodusere som en ekte feilende test eller kjørbar repro, og forkaster alt som ikke gjør det. Den avslutter med en grain-review-runde for strukturell passform. Det som leveres, er en gjennomgang der hvert punkt kommer med kjørbare bevis — ikke synsing.

Hva vi bør se hvis dette virker

• H1 — Sletting dukker opp i funksjons-PR-er. Hvis ponytail + grain virker, bør det å legge til en funksjon ofte fjerne netto struktur, ikke bare legge til.
• H2 — Fikser lander én gang, på det delte stedet. Rotårsaksfikser bør kollapse mange kallesteder til én vakt, ikke strø vakter utover per kaller.
• H3 — Gjennomgangen fanger kontraktsbrudd et menneske skummer forbi. Bevisstøttet gjennomgang bør avdekke bugs som «ser fint ut»-gjennomgang overser — særlig den stille sorten.

Del 2 · HVA SÅ — fem PR-er, ett instinkt hver

Fem ekte endringer i agentkjernen vår. Vi holder detaljene bevisst vage — repoet er privat — men tallene er regnet ut fra de faktiske diffene, og det overførbare er lærdommene.

Trekk fra: én vakt for et dusin fetch-steder

Én familie av flytsteg hentet brukeroppgitte URL-er uten en DNS-oppslagende sikkerhetssjekk, så et vertsnavn som løste seg opp til en intern adresse kunne nå cloud-metadata fra backenden. Den fristende fiksen legger inn en sjekk på hvert av de drøyt dusin fetch-stedene. Ponytails svar var det motsatte: én delt, bevoktet fetch-hjelpefunksjon, brukt overalt — og vi slettet en håndlaget tabell over private nettverk som et wildcard-DNS-triks gikk rett forbi, pluss tre dupliserte redirect-løkker og en nettverkssjekk kopiert inn i flere filer.

Diffen la til den delte hjelpefunksjonen og fjernet ~90 linjer med duplisering på tvers av 22 filer. Den slettingen er historien: dette er H2 i kjøtt og blod — rotårsaksfiksen ledet hver kaller gjennom én vakt i stedet for å lappe den ene stien ticketen nevnte.

Rotårsaksfiksen: et dusin ad-hoc fetch-steder kollapser til én delt, bevoktet hjelpefunksjon. Den late fiksen og den sikre fiksen er den samme fiksen.

Trekk fra + bevis: én formvakt, bevist på det ekte runtime-miljøet

Worker-runtimen vår lagrer resultatet av en kjøring som en serialisert streng, noen ganger pakket inn i en liste med ett element. Konsumenter som forventet et vanlig objekt, krasjet på det. Feil fiks sprer defensive typesjekker utover hos hver konsument. I stedet: én liten hjelpefunksjon som normaliserer formen, og alle konsumenter pekt om til den — en nesten ren tilføyelse av én vakt som erstatter de N ad-hoc-vaktene en mindre disiplinert agent ville skrevet (+558 / −24, 7 filer).

Det som gjør dette til en review-proof-historie, er testen. I stedet for å assertere mot en antatt serialiseringsform kjørte vi en ekte workflow gjennom den faktiske runtimem og lagringen — ingen mocks — og beviste formen runtimem faktisk lagrer. Det åpne spørsmålet i ticketen var bokstavelig talt hva serialiserer runtimem her? — og det eneste ærlige svaret er ett du kan kjøre.

Bevis: gjennomgangen fanget et stille kontraktsbrudd

Funksjon: en fallback-modell per node, slik at en flyt som er låst til én leverandør, degraderer grasiøst under et avbrudd. Det åpenbare første forsøket pakket modellen inn i rammeverkets innebygde fallback-kombinator.

Den fungerte i happy path. Den slo også stille av to leverandørfunksjoner som gater på den konkrete modelltypen via isinstance — et pakket objekt er ikke lenger den typen, så native strukturert output og prompt-caching ble begge stille slått av. Ingen feil. Ingen feilende happy-path-test. Nøyaktig den typen ting en menneskelig gjennomgang skummer forbi og en «ser fint ut»-agent godkjenner.

review-proof godkjente den ikke — den reproduserte begge bruddene som feilende tester, noe som tvang frem redesignet: legg fallbacken lenger ned, på kjøretidspunktet, slik at hver modell beholder sin konkrete type og de type-gatede funksjonene fortsetter å virke. H3, bekreftet en gang for alle: bevis fanget en bug som plausibilitet ville ha sendt ut.

Tilpass: én velger, ikke to kopier

Å legge til en andre varslingskanal gjorde at kanalvelger-UI-en plutselig hadde to hjem — en opprettingsveiviser og en innstilingsmodal. Standardtrekket til en agent er å legge den nye grenen til begge, og dermed gro to kopier av den samme tilstandsmaskinen. grain sa: det finnes allerede én måte dette bør formes på — gjør det delt. Vi trakk ut én enkelt velger-hook og drev begge skjermene gjennom den, plasserte den nye kanalen inn i den eksisterende config-unionen, og gjenbrukte den eksisterende e-posttjenesten i stedet for å legge til nytt sendemaskineri.

+1 735 / −340 på tvers av 24 filer. At en funksjon av denne størrelsen fjerner 340 linjer, er H1 gjort synlig: dedupliseringen av to velgerkopier til én betalte for en god del av den nye kanalen.

Tilpass + bevis: gjenbruk endepunktet, speil stien

Å la brukere legge ved filer ved opprettelse av en sak kunne ha betydd et nytt opplastingsendepunkt, en ny dispatch-mekanisme, en ny prompt-sti. grain ledet nesten alt inn på eksisterende spor: det eksisterende opplastingsendepunktet, en accept-liste i frontend som speiler backendens whitelist nøyaktig, og en fiks for utsatt dispatch som gjenbrukte kvalifiseringsmekanismen planlagt arbeid allerede brukte. Den ble levert med bevisstøttede fikser, inkludert en ekte transaksjonsisolasjonsbug som ville ha mistet data ved parallelle opplastinger. +1 776 / −218 på tvers av 27 filer — en stor funksjon som likevel fant 218 linjer å fjerne ved å koble seg på eksisterende slices i stedet for å finne opp nye.

Resultattavlen

Fem Tier-3-PR-er: hva hver la til, hva den fjernet, og instinktet bak.

Fem funksjons- og fiks-PR-er i agentkjernen fjernet 821 linjer — ikke ved å gjøre mindre, men ved å nekte å duplisere det som allerede fantes, og ved å droppe symptomlapper som en rotårsaksfiks gjorde overflødige.

Full åpenhet

• Dette er ferdigheter, ikke en studie. Det er ikke et kontrollert eksperiment med en baseline-arm; det er fem ekte PR-er der disiplinen ble anvendt. Kontrafaktumet — hva den samme agenten ville ha levert uten ferdighetene — er et kvalifisert anslag, ikke en måling. Historien om det stille kontraktsbruddet er det reneste beviset, fordi vi så gjennomgangen reprodusere bugen før redesignet.
• Linjetall er proksier. −821 er et reelt tall fra diffene, men «linjer fjernet» står for «duplisering og død fleksibilitet unngått». En ferdighet som snakker en agent bort fra å skrive 200 spekulative linjer, setter ikke spor i en diff i det hele tatt — de største gevinstene er usynlige her.
• Tokenbesparelser er retningsangivende. Mindre diffs, færre berørte filer og gjenbrukte strukturer betyr færre tokens brukt på å generere, gjennomgå og gjennomgå på nytt — men vi oppgir ikke et hardt token-delta per PR.
• ponytail er ikke vår. Det er en åpen kildekode-ferdighet av Dietrich Gebert ; vi tilpasset den. grain og review-proof er våre, bygget i samme ånd. Alle tre kjører som lokale prosjektferdigheter i Claude Code — prompt og prosedyre, ikke en binærfil du installerer.

Klar til å vokse bedriften din?

Start din gratis prøveperiode i dag og se resultater i løpet av få dager.

Be om demo Logg inn

Del 3 · HVA NÅ

Hva som ble levert. Tre komponerbare ferdigheter. ponytail og grain kjører mens du skriver; ponytail-review, grain-review og review-proof kjører på en diff. review-proof kjeder grain-review som sin siste fase, så én bevist gjennomgang også får en strukturell runde på kjøpet.

Hva du kan gjøre på mandag — du trenger ikke våre eksakte ferdigheter:

1. Gjør «gjenbruk» til trinn to, ikke trinn ti. Før en agent skriver en hjelpefunksjon, la den grep-e etter en som finnes. «Finnes det allerede i denne kodebasen?» hører hjemme over «kan jeg skrive det på en ryddig måte?»
2. Fiks ved roten, bevis det med kallerlisten. Krev at hver bugfiks navngir alle kallere av funksjonen som berøres. Én vakt i den delte funksjonen slår én vakt per kaller — og det er en mindre diff.
3. Gi ny kode et nærmeste søsken å kopiere. «Finn det nærmeste eksisterende eksempelet og speil formen» gjør arkitektur fra et dokument ingen leser til en standard agenten følger.
4. Håndhev laggrenser i CI, ikke på synsing. En skralle som bare feiler på nye kryss-lag-importer lar deg holde linjen uten å koke hele havet av eksisterende gjeld.
5. Ikke lever et funn du ikke kan reprodusere. La agenten skrive den feilende testen først. Klarer den ikke å få bugen til å reprodusere, er det ikke en bug — det er en mening. Forkast det.
6. La gjennomgangen slette. Rett en gjennomgangsrunde spesifikt mot overengineering — «hva kan vi kutte» — adskilt fra korrekthet. Det beste utfallet av en diff er at den blir kortere.

Prøv det, særlig hvis det feiler for deg. Kjører du kodeagenter på en ekte kodebase, skjer entropien allerede — du har bare ikke målt den. Gjør én av disse om til en gjennomgangsrunde på dine neste ti agent-PR-er og tell slettingene. Hvis trekk-fra-tilpass-bevis ikke krymper diffene dine eller fanger et stille brudd, vil vi virkelig gjerne høre det. Korreksjoner og moteksempler er ekstra velkomne.

En agent legger til. Jobben er å få agenten til å gjøre seg fortjent til hver linje.