Elke keer als ik hier iets publiceer, draait er eerst een rijtje controles: staat dit artikel ver genoeg van het vorige, hergebruikt het geen zinnen uit een stuk van vorige maand, staat er een kanttekening in. Die drie checks deed ik ooit met mijn ogen. Nu blokkeren ze de build als er iets niet klopt, en ik merk ze alleen nog als ze rood worden.
Dat is precies de vorm waar het in dit stuk over gaat. Niet een agent die iets slims verzint, maar een taak die zo vaak terugkomt dat je hem niet meer zelf hoort te doen.
Aanleiding is een gesprek dat Anthropic op 6 augustus publiceerde met twee mensen van Ramp, in de video alleen aangeduid als Austin en Rahul. Ramp is een fintech met een grote Python-monoliet en een engineeringcultuur die vooral bekendstaat om tempo. In tweeëntwintig minuten leggen ze uit hoe agents bij hen in vrijwel elke stap van het bouwproces meedraaien. Wat me bijbleef was niet de schaal, maar één zin over hoe ze werk indelen.
De horizontale en de verticale snede
Rahul beschrijft het zo. Als je een groep engineers hebt die allemaal ongeveer hetzelfde dagelijkse klusje doen, dan kun je die taak er horizontaal afsnijden en in een loop stoppen. Codereview. Een pull request bewaken tot CI groen is. Feedback verwerken. Dode code opruimen, wat bij hem letterlijk een routine is die elke dag draait.
De verticale snede is het tegenovergestelde: één taak helemaal doorlopen, van begin tot eind. Zijn voorbeeld is een experiment uitrollen. De agent bouwt het experiment, zet de pull request klaar, plant een herinnering voor zichzelf om de dag erna te kijken of de verdeling klopt, schroeft de blootstelling op, en komt weken later terug met een tweede pull request om de winnende variant uit te rollen. Hij keurde alleen de eerste pull request goed. De rest liep zonder hem.
Daarnaast staat het andere gereedschap, dat ik eerder beschreef in mijn stuk over dynamic workflows. Hun scheidslijn is scherp en bruikbaar: een loop is voor werk waarvan je de stappen kent, een dynamic workflow is voor werk waarvan je de stappen niet kent. Systeemoptimalisatie is het tweede geval, want je weet nooit welke verbetering er na deze komt.
| Loop of routine | Dynamic workflow | |
|---|---|---|
| Waarvoor | herhaalwerk met bekende stappen | werk waarvan de stappen onbekend zijn |
| Wat je meegeeft | de taak plus een interval | een doel |
| Wat er verandert per ronde | de toestand van het systeem | het plan zelf |
| Typisch voorbeeld | pull request bewaken, dode code opruimen | CI-tijd omlaag brengen, geheugenlek zoeken |
| Wat het kost | weinig per ronde, veel rondes | veel in één keer |
Hoe de mechaniek er nu uitziet
Er zijn drie manieren om iets herhaald te laten draaien, en ze verschillen op precies één punt: wat er aan moet blijven staan.
/loop draait in je sessie. Je geeft een interval en een prompt mee, bijvoorbeeld /loop 5m kijk of de deploy klaar is, en Claude zet dat om in een cron-regel. Laat je het interval weg, dan kiest Claude er zelf een tussen één minuut en een uur, en print na elke ronde waarom. Handig, maar je laptop moet aanstaan en de sessie open. Stoppen doe je met Escape.
Een routine draait in de cloud, los van je machine, met een minimuminterval van een uur. Een desktoptaak draait op je eigen machine zonder open sessie en heeft daardoor als enige toegang tot je lokale bestanden en tools.
Twee details die ik vooraf niet wist en die uitmaken. Een terugkerende taak in een sessie verloopt na zeven dagen: hij vuurt nog één keer en verwijdert zichzelf. Dat is bewust een rem op de vergeten loop die maandenlang tokens blijft opeten. En er zit ruis op de timing: een uurtaak die je op het hele uur zet, kan tot een halfuur later vuren, omdat de vertraging uit het taak-id wordt afgeleid. Wil je dat niet, kies dan een minuut die niet :00 of :30 is.
Verder kun je de instructie voor een lege /loop vastleggen in .claude/loop.md in het project of ~/.claude/loop.md voor jezelf. Wijzigingen in dat bestand pakt de eerstvolgende ronde op, dus je kunt bijsturen terwijl het ding draait.
De cijfers, en wat eronder ontbreekt
Ramp noemt in het gesprek dat Claude hun CI-tijd terugbracht van ongeveer achttien minuten mediaan naar zes minuten mediaan. Het interessante zit in de werkwijze eromheen: de code landde, de agent wachtte een dag, plande zichzelf met een routine in om terug te komen, keek naar echte productiedata en herhaalde dat dagenlang tot de winst binnen was. Dat is dus geen loop, dat is een dynamic workflow die zichzelf van een loop bediende.
De klantcase van Anthropic legt daar drie cijfers naast: meer dan een miljoen regels door AI voorgestelde code die in dertig dagen daadwerkelijk is doorgevoerd, bijna vijftig procent wekelijks gebruik binnen engineering, en tot tachtig procent minder tijd voor het onderzoeken van incidenten.
Dat laatste cijfer is het cijfer waar ik naar zoek, want de formulering verraadt hoe hard het is. Er staat “early observations suggest” en “up to”. Geen aantal incidenten, geen meetperiode, geen nulmeting waartegen is vergeleken. Het is een leverancierspagina over een klant die dezelfde leverancier prijst, en de achttien-naar-zes-minuten uit het gesprek komt zonder meetopzet uit het hoofd van iemand die er trots op is. Beide zijn geloofwaardig als richting en waardeloos als bewijs. De cijfers waarmee je zelf iets kunt zijn de cijfers die je zelf meet.
En er is iets wat Ramp expliciet niet doet: kosten beheersen aan de gebruikerskant. Ze leggen geen tokenbudget per engineer op, bewust. Hun redenering is dat je in een situatie waarin elke euro aan tokens meer dan een euro oplevert, geen kosten meer moet willen minimaliseren. Dat is een verdedigbare keuze voor een bedrijf met hun marges. Het is geen advies dat je zomaar overneemt.
Wat ik zelf in een loop zet
Eerlijk over de schaal: ik heb geen vloot achtergrondagents en geen team dat er dagelijks in werkt. Ik heb een blog en een handjevol scripts. De horizontale snede werkt daar toch, omdat het criterium niet schaal is maar herhaling.
Wat er nu draait, is de saaie variant. Drie redactionele controles hangen als prebuild aan elke build en blokkeren de deploy: de cadans tussen publicaties, letterlijk hergebruikte zinnen tussen artikelen die kort na elkaar verschijnen, en de kanttekening in AI-stukken. Een Cloudflare Worker vuurt twee keer per dag een deploy-hook af, zodat een artikel met een datum in de toekomst vanzelf live gaat zonder dat ik iets doe. Geen van beide is een AI-loop. Het zijn cronregels en een node-script, en dat is precies goed, want een controle die deterministisch kan zijn hoort geen model nodig te hebben.
Waar het model wel loont is de laag erboven, en dat is de les die ik uit dit gesprek meeneem. Twee dingen ga ik veranderen.
Het eerste is de nieuwsscan. Ik draai die nu handmatig als ik eraan denk, wat betekent dat ik hem soms drie dagen niet draai. Dat is exact de vorm van een routine: dezelfde taak, elke ochtend, en het resultaat is een lijstje dat ik daarna zelf beoordeel. De agent kiest niets, hij verzamelt.
Het tweede is dat ik nog geen loop.md heb. Dat verbaasde me toen ik het nakeek. De taak die ik het vaakst herhaal is niet schrijven maar nakijken: draaien de gates, staat de planning nog goed, is er een beeld dat nog gegenereerd moet worden. Dat is één alinea instructie die ik nooit heb opgeschreven omdat ik hem elke keer opnieuw typ.
De regel die ik eruit haal: zet iets pas in een loop als je de stappen kunt opschrijven. Kun je dat niet, dan is het geen loop maar een onderzoeksvraag, en dan hoort er iets anders te draaien of gewoon jijzelf.
De kanttekening
Het opruimen verdwijnt uit het zicht. Een routine die dode code verwijdert, doet iets wat vroeger een mens deed die daarbij het systeem leerde kennen. Dat leren zat niet in de opruiming zelf, maar in het rondkijken eromheen. Als niemand meer door de oude hoeken loopt, blijft de code schoon en wordt de kennis over die code dunner. Dat is een echte ruil, geen theoretische.
De verantwoordelijkheid schuift naar het moment van goedkeuren. In het Ramp-voorbeeld keurde iemand één pull request goed en liep de rest weken door zonder hem. Formeel is dat een menselijke beslissing. Praktisch keurde die persoon een intentie goed, niet een uitkomst. Wie een loop start, tekent voor alles wat er daarna uitkomt, en de enige manier om dat eerlijk te doen is een loop bouwen die klein genoeg is om te overzien.
De rem op verspilling is nu een implementatiedetail. Dat een terugkerende taak na zeven dagen zichzelf opheft, is de reden dat een vergeten loop je niet failliet laat draaien. Dat is een keuze van de leverancier, geen wet, en hij kan veranderen. Zolang je eigen kosten van zo’n instelling afhangen, heb je die grip niet zelf in handen. Zet er een eigen grens naast die je wel controleert.
Welke van jouw terugkerende klussen zich laat opschrijven, merk je pas als je het probeert met iemand naast je. Daar wil ik een dag voor opzetten, met echte voorbeelden in plaats van een presentatie. Er staat een lijst op de praktijk, en hoe lang die wordt bepaalt of ik hem bouw.
Veelgestelde vragen
Wat is het verschil tussen een loop en een routine?
Een loop draait in je open sessie op je eigen machine, met een minimuminterval van een minuut, en stopt als je de sessie sluit. Een routine draait in de cloud, los van je machine, met een minimuminterval van een uur. Wil je toegang tot lokale bestanden zonder open sessie, dan is een desktoptaak de derde optie.
Hoe stop ik een loop die aan het draaien is?
Druk op Escape terwijl de loop op de volgende ronde wacht. Dat wist de geplande wekker, waardoor hij niet opnieuw vuurt. Taken die je los hebt ingepland door het Claude gewoon te vragen, blijven wel staan tot je ze verwijdert.
Kost een loop veel tokens?
Elke ronde is een volledige beurt, dus de kosten schalen met het aantal rondes en niet met de looptijd. Een interval van vijf minuten dat een nacht doorloopt, is ruwweg honderdvijftig beurten. Voor het wachten op een gebeurtenis is een script dat zijn uitvoer terugstreamt goedkoper dan herhaald pollen.
Waarom zou ik geen loop gebruiken?
Omdat de stappen niet vastliggen. Bij systeemoptimalisatie of een zoektocht naar een geheugenlek weet je vooraf niet wat de volgende stap is, en dan herhaalt een loop alleen de verkeerde vraag. Dat is het terrein van een dynamic workflow.
Bronnen
- Anthropic, “How Ramp engineers work with AI agents at every step”, YouTube, 6 augustus 2026 — youtu.be/i4odXOmgMLw
- Anthropic, klantcase “How Ramp’s engineering operates at hyperspeed with Claude Code” — claude.com/customers/ramp
- Claude Code documentatie, “Run prompts on a schedule” — code.claude.com/docs/en/scheduled-tasks
Gecontroleerd op 11 augustus 2026. De uitspraken van Ramp komen uit het ondertitelingsbestand van de video, dat ik heb uitgelezen omdat er geen transcript op de pagina staat; citaten zijn daardoor parafrases en geen letterlijke aanhalingen. De video noemt alleen voornamen. Op basis van de klantcase en openbare profielen gaat het vermoedelijk om Austin Ray, senior software engineer, en Rahul Sengottuvelu, hoofd Applied AI, maar dat heb ik niet bevestigd gekregen en daarom staan hier alleen de voornamen. De cijfers over CI-tijd en incidentonderzoek heb ik niet onafhankelijk kunnen verifiëren: de eerste komt uit het gesprek zonder meetopzet, de tweede uit een klantcase van de leverancier zelf met de woorden “up to” en “early observations”. De klantcase spreekt over Claude Code in het algemeen en noemt de interne tools Inspect en Glass niet bij naam; die komen alleen uit het gesprek. De mechaniek van loops, routines en desktoptaken komt uit de officiële documentatie en heb ik daar nagelezen.