We geven codeeragents elke dag echte tickets, en ze leveren bijna altijd iets op dat werkt. Dat was nooit de zorg. De zorg is hoe ze werken: een nieuwe helper naast drie die het werk al doen, een frisse abstractie voor één enkele aanroeper, een fix die het ene pad uit het ticket dichtplakt en vier broertjes kapot achterlaat, een bevinding die “waarschijnlijk een bug” is zonder bewijs in welke richting dan ook. Elke wijziging is lokaal redelijk. In totaliteit zijn het entropie.
TL;DR: Over vijf Tier-3 pull requests op onze agent-orchestratiekern verwijderden drie combineerbare vaardigheden —
ponytail(aftrekken),grain(uitlijnen) enreview-proof(bewijzen) — 821 regels terwijl er vijf features werden geleverd, vingen ze een stille contractbreuk die plausibiliteit alleen gemerged zou hebben, en hielden ze elke wijziging in de lijn van de bestaande architectuur. Hieronder staat wat elk van hen doet, met de echte diffs als onderbouwing.
Haal de vangrails weg en een codeeragent is een razendsnelle generator van plausibel ogende risico’s. Daarom leunen we op drie kleine vaardigheden die de andere kant op duwen — elk één instinct: aftrekken, uitlijnen, bewijzen.
ponytail— schrijf het luiste ding dat daadwerkelijk werkt. Verwijder voordat je toevoegt. (Deze hebben we niet zelf geschreven — het is een open-sourcevaardigheid van Dietrich Gebert die we voor onze stack hebben aangepast.)grain/grain-review— zet het waar de codebase al heeft besloten dat het hoort. Verzin geen tweede manier.review-proof— geloof een bevinding pas als ze reproduceert als een falende test.
grain en review-proof bouwden we in dezelfde geest als ponytail, afgestemd op onze architectuur. Elk van de vijf PR’s hieronder raakt onze agent-orchestratiekern — de duurste plek in de repo om slordig te zijn — en elke PR is geclassificeerd als Tier 3: extra testdekking en menselijke review bovenop de geautomatiseerde reviewer, zonder uitzonderingen.
De drie vaardigheden in één oogopslag: ponytail trekt af, grain lijnt uit, review-proof bewijst.
Deel 1 · WAT — entropie is de standaard
Hier is het ding waar niemand je voor waarschuwt wanneer je een repo aan AI-agents geeft: elke agent optimaliseert lokaal en onthoudt niets. Hij ziet het ticket, niet de maanden aan conventies waar je team naartoe is gegroeid. Hij heeft geen reden om jouw bestaande e-mailservice te verkiezen boven een nieuwe, geen herinnering dat de redirect-status-set al drie bestanden verderop is gedefinieerd, geen instinct dat “de fix in de gedeelde functie hoort, niet in deze ene aanroeper”. Vrij spel en N agents produceren N licht verschillende manieren om hetzelfde te doen. Dat is geen codekwaliteitsprobleem dat je kunt weglinten — het is een structurele drift die zich opstapelt.
De drie vaardigheden richten zich elk op één as van die drift.
ponytail — het luiste ding dat werkt
Ponytail is een senior developer die om 3 uur ’s nachts is opgeroepen voor de slimme abstractie van iemand anders en weigert de volgende te schrijven. Hij loopt een ladder af en stopt bij de eerste trede die houdt: moet dit überhaupt bestaan (YAGNI) → staat het al in deze codebase → doet de standaardbibliotheek het → native platformfunctie → al geïnstalleerde dependency → kan het in één regel → pas dan de minimale code die werkt.
De trede die er voor agents het meest toe doet is “staat het al in deze codebase?” Opnieuw implementeren wat een paar bestanden verderop staat, is de meest voorkomende vorm van agentslop. En ponytails bugfix-regel houdt diffs eerlijk: fix de hoofdoorzaak, niet het symptoom. Grep elke aanroeper van de functie die je op het punt staat aan te raken; één guard in de gedeelde functie is een kleinere diff dan een guard in elke aanroeper — en het laat de broertjes niet kapot achter.
grain / grain-review — met de nerf mee
Als ponytail bepaalt hoe weinig je schrijft, bepaalt grain waar het terechtkomt en welke vorm het krijgt. De enige regel: zoek het dichtstbijzijnde bestaande voorbeeld, kopieer zijn vorm, benoem wat je hebt gekopieerd. Nieuwe code moet lezen alsof de persoon die het bestand ernaast schreef dit bestand ook heeft geschreven.
Grain is ook waar architectuur wordt afgedwongen. Onze backend is een redelijk standaard vertical-slice + hexagonale opzet — presentatie roept applicatie aan, applicatie roept domein aan, infrastructuur is naar binnen gericht afhankelijk, en het domein reikt nooit terug naar buiten. Een bevinding als “deze route slaat zijn controller over en haalt de service direct op” is geen muggenzifterij — het is het verschil tussen een codebase waarin een agent volgende maand kan navigeren en een waarin dat niet lukt. grain-review jaagt precies op deze dingen: gedupliceerde helpers, overschreden laaggrenzen, grijpen in de interne werking van een andere feature, een tweede conventie voor iets dat al op één manier gebeurt.
review-proof — verdien de bevinding
Standaard AI-codereview levert plausibele bevindingen op. Sommige zijn echt; sommige zijn zelfverzekerde onzin; van buitenaf zien ze er identiek uit. review-proof weigert zichzelf te vertrouwen: het reviewt, en dwingt vervolgens elke correctheidsbevinding om te reproduceren als een echte falende test of een uitvoerbare repro, en laat alles vallen wat dat niet doet. Het sluit af met een grain-review-ronde voor structurele fit. Wat eruit komt is een review waarin elk item met uitvoerbaar bewijs komt — niet op gevoel.
Wat we zouden moeten zien als dit werkt
- H1 — Verwijderingen duiken op in feature-PR’s. Als ponytail + grain werken, zou het toevoegen van een feature vaak netto structuur moeten verwijderen, niet alleen toevoegen.
- H2 — Fixes landen één keer, op de gedeelde plek. Hoofdoorzaakfixes zouden vele aanroepplekken op één guard moeten laten samenvallen, niet per aanroeper een guard strooien.
- H3 — De review vangt contractbreuken die een mens overheen leest. Bewijsgestaafde review zou bugs moeten opdiepen die een “ziet er goed uit”-review mist — vooral de stille soort.
Deel 2 · EN DAN — vijf PR’s, elk één instinct
Vijf echte wijzigingen aan onze agentkern. We houden de interne details bewust vaag — de repo is privé — maar de cijfers zijn berekend uit de werkelijke diffs en de lessen zijn het overdraagbare deel.
Aftrekken: één guard voor een dozijn fetch-plekken
Eén familie van flowstappen haalde door gebruikers aangeleverde URL’s op zonder een DNS-resolverende veiligheidscontrole, zodat een hostnaam die resolveerde naar een intern adres de cloudmetadata vanaf de backend kon bereiken. De verleidelijke fix voegt een controle toe op elk van de ruim twaalf fetch-plekken. Ponytails antwoord was het tegenovergestelde: één gedeelde, beveiligde fetch-helper, overal gebruikt — en we verwijderden een handgerolde private-netwerktabel waar een wildcard-DNS-truc zo doorheen liep, plus drie gedupliceerde redirect-lussen en een netwerkcontrole die in meerdere bestanden was gekopieerd.
De diff voegde de gedeelde helper toe en verwijderde ~90 regels duplicatie over 22 bestanden. Die verwijdering is het verhaal: dit is H2 in levenden lijve — de hoofdoorzaakfix leidde elke aanroeper door één guard in plaats van het ene pad uit het ticket te patchen.
De hoofdoorzaakfix: een dozijn ad-hoc fetch-plekken klapt samen op één gedeelde, beveiligde helper. De luie fix en de veilige fix zijn dezelfde fix.
Aftrekken + bewijzen: één vormguard, bewezen op de echte runtime
Onze worker-runtime bewaart het resultaat van een run als een geserialiseerde string, soms verpakt in een lijst met één element. Consumers die een gewoon object verwachtten, crashten erop. De verkeerde fix strooit defensieve typechecks bij elke consumer. In plaats daarvan: één kleine vorm-normaliserende helper, en elke consumer opnieuw daarheen geleid — een bijna pure toevoeging van één guard die de N ad-hoc guards vervangt die een minder gedisciplineerde agent zou hebben geschreven (+558 / −24, 7 bestanden).
Het deel dat hier een review-proof-verhaal van maakt, is de test. In plaats van te assereren tegen een veronderstelde serialisatievorm, lieten we een echte workflow door de werkelijke runtime en opslag lopen — geen mocks — en bewezen we de vorm die de runtime daadwerkelijk bewaart. De open vraag in het ticket was letterlijk wat serialiseert de runtime hier? — en het enige eerlijke antwoord is er een die je kunt uitvoeren.
Bewijzen: de review ving een stille contractbreuk
Feature: een fallback-model per node, zodat een flow die aan één provider is vastgepind tijdens een storing gracieus degradeert. De voor de hand liggende eerste versie wikkelde het model in de ingebouwde fallback-combinator van het framework.
Het werkte in het happy path. Het schakelde ook stilzwijgend twee providerfuncties uit die via isinstance op het concrete modeltype gaten — een gewrapt object is dat type niet meer, dus zowel native gestructureerde output als prompt-caching gingen geruisloos uit. Geen fout. Geen falende happy-path-test. Precies het soort ding waar een menselijke review overheen leest en een “ziet er goed uit”-agent goedkeurt.
review-proof keurde het niet goed — het reproduceerde beide breuken als falende tests, wat het herontwerp afdwong: pas de fallback lager toe, op uitvoeringstijd, zodat elk model zijn concrete type behoudt en de type-gated functies blijven werken. H3, overtuigend bevestigd: bewijs ving een bug die plausibiliteit verzonden zou hebben.
Uitlijnen: één picker, niet twee kopieën
Het toevoegen van een tweede notificatiekanaal betekende dat de kanaal-picker-UI nu twee thuisbases had — een create-wizard en een settings-modal. De standaard agentbeweging voegt de nieuwe tak aan beide toe, waardoor er twee kopieën van dezelfde state machine groeien. grain zei: er is al één manier waarop dit gevormd zou moeten zijn — maak het gedeeld. We extraheerden één picker-hook en stuurden beide schermen erdoorheen, plaatsten het nieuwe kanaal in de bestaande config-unie, en hergebruikten de bestaande e-mailservice in plaats van nieuwe verzendmachinerie toe te voegen.
+1.735 / −340 over 24 bestanden. Een feature van deze omvang die 340 regels verwijdert, is H1 zichtbaar gemaakt: de dedup van twee picker-kopieën naar één betaalde een flink deel van het nieuwe kanaal.
Uitlijnen + bewijzen: hergebruik het endpoint, spiegel het pad
Gebruikers bestanden laten toevoegen bij het aanmaken van een issue had kunnen betekenen: een nieuw upload-endpoint, een nieuw dispatch-mechanisme, een nieuw prompt-pad. grain leidde bijna alles naar bestaande rails: het bestaande upload-endpoint, een frontend accept-lijst die exact de backend-whitelist spiegelt, en een deferred-dispatch-fix die het geschiktheidsmechanisme hergebruikte dat gepland werk al gebruikte. Het werd uitgebracht met bewijsgestaafde fixes, inclusief een echte transactie-isolatiebug die data zou hebben verloren bij parallelle uploads. +1.776 / −218 over 27 bestanden — een grote feature die nog steeds 218 regels wist te verwijderen door zich bij bestaande slices te voegen in plaats van nieuwe te verzinnen.
Het scorebord
Vijf Tier-3 PR’s: wat elk toevoegde, wat elk verwijderde, en het instinct erachter.
Vijf feature- en fix-PR’s op de agentkern verwijderden 821 regels — niet door minder te doen, maar door te weigeren te dupliceren wat al bestond en symptoompatches te behouden die een hoofdoorzaakfix overbodig had gemaakt.
Volledige openheid
- Dit zijn vaardigheden, geen studie. Dit is geen gecontroleerd experiment met een baseline-arm; het zijn vijf echte PR’s waarin de discipline is toegepast. Het contrafeitelijke — wat dezelfde agent zonder de vaardigheden zou hebben uitgebracht — is een geïnformeerde schatting, geen meting. Het verhaal van de stille contractbreuk is het zuiverste bewijs, omdat we zagen hoe de review de bug reproduceerde vóór het herontwerp.
- Regeltellingen zijn proxy’s. De −821 is een echt getal uit de diffs, maar “verwijderde regels” staat voor “vermeden duplicatie en dode flexibiliteit”. Een vaardigheid die een agent afpraat om 200 speculatieve regels te schrijven, laat helemaal geen spoor achter in een diff — de grootste winsten zijn hier onzichtbaar.
- Tokenbesparingen zijn indicatief. Kleinere diffs, minder aangeraakte bestanden en hergebruikte structuren betekenen minder tokens voor genereren, reviewen en her-reviewen — maar we citeren geen harde token-delta per PR.
ponytailis niet van ons. Het is een open-sourcevaardigheid van Dietrich Gebert ; we hebben die aangepast.grainenreview-proofzijn van ons, in dezelfde geest gebouwd. Alle drie draaien ze als lokale projectvaardigheden op Claude Code — prompt-en-procedure, geen binary die je installeert.
Klaar om uw bedrijf te laten groeien?
Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.
Deel 3 · EN NU
Wat er is uitgebracht. Drie combineerbare vaardigheden. ponytail en grain draaien tijdens het schrijven; ponytail-review, grain-review en review-proof draaien op een diff. review-proof schakelt grain-review als laatste fase in, dus een enkele bewezen review krijgt er gratis een structurele ronde bij.
Wat je maandag kunt doen — je hebt niet onze exacte vaardigheden nodig:
- Maak “hergebruiken” trede twee, niet trede tien. Laat een agent, voordat hij een helper schrijft, greppen naar een die al bestaat. “Staat het al in deze codebase?” hoort boven “kan ik het netjes schrijven?”
- Fix bij de wortel, bewijs het met de aanroeplijst. Eis dat elke bugfix elke aanroeper van de aangeraakte functie benoemt. Eén guard in de gedeelde functie verslaat een guard per aanroeper — en het is een kleinere diff.
- Geef nieuwe code een dichtstbijzijnde broer of zus om te kopiëren. “Zoek het dichtstbijzijnde bestaande voorbeeld en spiegel zijn vorm” maakt van architectuur geen document dat niemand leest, maar een standaard die de agent volgt.
- Handhaaf laaggrenzen in CI, niet op gevoel. Een ratchet die alleen faalt op nieuwe cross-layer imports laat je de lijn vasthouden zonder de oceaan van bestaande schuld te laten koken.
- Lever geen bevinding op die je niet kunt reproduceren. Laat de agent eerst de falende test schrijven. Als hij de bug niet kan laten reproduceren, is het geen bug — het is een mening. Laat vallen.
- Laat de review verwijderen. Richt een review-ronde specifiek op over-engineering — “wat kunnen we wegknippen” — los van correctheid. De beste uitkomst van een diff is dat hij korter wordt.
Probeer het, vooral als het voor jou mislukt. Als je codeeragents op een echte codebase draait, gebeurt de entropie al — je hebt het alleen nog niet gemeten. Maak van een van deze een review-ronde op je volgende tien agent-PR’s en tel de verwijderingen. Als aftrekken-uitlijnen-bewijzen je diffs niet kleiner maakt of geen stille breuk vangt, horen we dat oprecht graag. Correcties en tegenvoorbeelden zijn extra welkom.
Een agent voegt toe. De taak is om de agent elke regel te laten verdienen.
