Claude Code Loop: Cron-scheduling rechtstreeks in je IDE
Het was 1:47 uur 's nachts op een dinsdag, en ik zat toe te kijken hoe een deployment zich langzaam over drie staging-omgevingen verspreidde. Niet omdat er iets kapot was — maar omdat ik er niet op kon vertrouwen dat er niets zou kapotgaan. Elke vijftien minuten wisselde ik naar mijn terminal, voerde dezelfde statuscheck uit, scande de logs en wisselde terug naar waar ik dan ook deed alsof ik aan werkte terwijl ik wachtte. Vier uur lang. Vier uur lang was ik een menselijke cron-job.
De volgende ochtend, draaiend op slechte koffie en nog slechtere nachtrust, opende ik Claude Code en typte zeven woorden die me mijn hele nacht hadden kunnen besparen.
/loop every 15 minutes check my deploy
Dat commando startte iets waar ik al maanden naar verlangde — een AI-assistent die niet alleen reageert wanneer ik iets vraag, maar op schema blijft werken terwijl ik letterlijk iets anders doe. De Loop-functie van Claude Code verandert je codeersessie in iets dat meer lijkt op een junior engineer die naast je zit en alleen op je schouder tikt wanneer iets je aandacht nodig heeft.
Maar hier is waar nog niemand het over heeft: Loop is niet zomaar een handigheidje. Het verandert fundamenteel de relatie tussen jou en je AI-assistent, door die te verschuiven van reactief naar proactief. En de manier waarop het onder de motorkap werkt — daadwerkelijke cron-scheduling die binnen je sessie draait — is zowel elegant als verrassend beperkt op manieren die je moet begrijpen voordat je erop vertrouwt.
Ik heb de afgelopen twee weken Loop tot aan zijn grenzen getest. Ik ontdekte waar het schittert, waar het breekt, en een paar trucs die nog in geen enkele documentatie staan. Er is een specifiek configuratiepatroon waar ik op dag drie per ongeluk op stuitte en dat de bruikbaarheid van de hele functie verdrievoudigde — ik neem je er doorheen nadat we de basis hebben behandeld.
Waarom je AI-assistent een klok nodig had
Hier is een scenario dat waarschijnlijk bekend klinkt. Je zit diep in een feature branch, volledig in flow-state, en ergens achterin je hoofd zit een zeurende gedachte: is die CI-pipeline al klaar? Dus je wisselt van context. Opent de browser. Checkt het dashboard. Pipeline draait nog. Terug naar code. Drie minuten later komt het gezeurd terug. Herhaal dit tot je flow-state volledig aan diggelen ligt.
Dit is geen productiviteitsprobleem. Het is een architectuurprobleem. Elke AI-codeerassistent op de markt — Claude Code, Cursor, Copilot, allemaal — werkt op een vraag-antwoordmodel. Jij vraagt, het antwoordt. Vergeet je te vragen, dan zit het er stilletjes bij. De AI heeft geen besef van tijd, geen vermogen om initiatief te nemen, geen manier om te zeggen "hé, dat ding waar je me een uur geleden naar liet kijken? Dat is net veranderd."
Loop lost dit op door Claude Code iets te geven dat het nooit eerder had: een besef van terugkerende verplichting.
De functie landde stilletjes. Geen groot lanceerevenement, geen flitsende demovideo van Anthropic. Het verscheen gewoon op een dag in de Claude Code-toolset, en de meeste ontwikkelaars die ik heb gesproken hebben het ofwel niet opgemerkt ofwel afgedaan als een gimmick. Ik bijna ook — totdat ik me realiseerde dat het je in feite een programmeerbare, AI-aangedreven cron-daemon geeft die in je ontwikkelomgeving leeft.
Bedenk wat cron doet op een server. Het voert taken uit op schema, betrouwbaar, zonder dat je erover nadenkt. Stel je nu datzelfde concept voor, maar in plaats van een shellscript uit te voeren, voert het een AI-agent uit die je codebase kan lezen, externe services kan controleren, logs kan analyseren en in natuurlijke taal kan rapporteren. Dat is Loop.
De timing van deze functie doet er ook toe. We zitten op een punt waar AI-codeerassistenten aan het plateauen zijn op de as "schrijf betere code". De modellen zijn goed genoeg. Het volgende concurrentievoordeel is niet slimmere codegeneratie — het is slimmere workflow-integratie. Loop is Anthropic's eerste echte zet in die richting, en het vertelt je veel over waar ze denken dat het product naartoe gaat.
Maar voordat ik je laat zien hoe je het instelt, moet je iets begrijpen over hoe Loop intern eigenlijk werkt — want het is niet wat je zou verwachten.
Hoe Loop onder de motorkap echt werkt
Wanneer je een Loop-taak aanmaakt, start Claude Code geen achtergrondthread en lanceert het geen apart proces. Het creëert een daadwerkelijke cron-entry binnen het schedulingsysteem van de sessie. Je kunt dit zelf zien door cron list uit te voeren na het opzetten van een loop — elke terugkerende taak verschijnt als een gestructureerde cron-job met een ID, schedule-expressie en bijbehorend commando.
Hier is hoe de basisflow eruitziet:
# Natuurlijke taal — Claude Code parst dit naar een cron-schedule
/loop every 10 minutes check if my test suite is passing
# Of gebruik het expliciete commando
cron create --schedule "*/10 * * * *" --command "Run the test suite and report failures"
# Bekijk alle actieve loops
cron list
# Stop een specifieke loop
cron delete <job-id>
De parsing van natuurlijke taal is oprecht indrukwekkend. Ik heb het getest met steeds vagere instructies:
- "every half hour" — correct gemapt naar
*/30 * * * * - "twice a day" — gemapt naar
0 */12 * * * - "every weekday morning at 9" — gemapt naar
0 9 * * 1-5 - "every 90 seconds" — deze faalde netjes, met de melding dat het minimuminterval één minuut is
Onder de motorkap draait elke loop-aanroep als een verse prompt binnen je bestaande sessie. Claude Code neemt je oorspronkelijke instructie, combineert die met de huidige sessiecontext en voert het uit alsof je dat commando zojuist handmatig had getypt. De resultaten verschijnen in je chat — elke keer dat de loop afgaat een nieuw bericht van Claude.
Deze ontwerpkeuze heeft een gevolg dat op het eerste gezicht niet voor de hand ligt. Elke loop-aanroep verbruikt tokens. Een loop die elke 10 minuten draait gedurende 8 uur gaat 48 keer af. Als elke aanroep 2.000 tokens gebruikt voor context plus antwoord, zijn dat 96.000 tokens verbrand aan een enkele terugkerende taak. Schaal dat op naar drie of vier gelijktijdige loops en je kijkt naar serieus tokenverbruik over een werkdag.
Ik heb dit op de dure manier geleerd tijdens mijn eerste week. Meer over de exacte cijfers later — ze verrassen je.
Eén ding dat ik oprecht waardeer aan de implementatie: Loop ondersteunt ook eenmalige herinneringen. Als je /loop in 2 hours remind me to merge the PR typt, maakt Claude Code een cron-job aan, laat hem eenmalig afgaan op het opgegeven tijdstip en verwijdert de job daarna automatisch. Simpel, schoon, en iets dat ik nu meerdere keren per dag gebruik voor dingen die niets met code te maken hebben.
De functie werkt op elk Claude Code-platform — de VS Code-extensie, de desktopapp en de terminal. Ik heb het voornamelijk in de terminal gebruikt omdat ik daar leef, maar de VS Code-integratie is eigenlijk soepeler voor monitoringtaken omdat de notificaties in het notificatiesysteem van de editor verschijnen.
Hier wordt de architectuur interessant — en hier duikt de eerste grote beperking op.
Het sessieprobleem waar niemand als eerste over praat
Loop-taken zijn sessiegebonden. Punt. Sluit je terminal, quit VS Code, herstart je machine — elke loop die je hebt ingesteld verdwijnt. Er is geen persistentielaag, geen state-bestand dat je loops over sessies heen onthoudt, geen manier om ze te exporteren en opnieuw te importeren.
Ik wil eerlijk zijn over waarom dit ertoe doet, want het had bijna mijn hele workflow met de functie ontspoord.
Tijdens mijn tweede week van testen had ik een prachtige setup draaien. Drie gelijktijdige loops: één die elke 15 minuten mijn staging-deployment monitorde, één die elk uur controleerde op nieuwe issues die aan mij waren toegewezen op GitHub, en één die elke 30 minuten een snelle lint-pass deed op gewijzigde bestanden. Ik was oprecht productiever. Toen ging mijn laptop in slaapstand tijdens de lunch.
Alles weg. Geen herstelmogelijkheid, geen "hervat vorige loops"-prompt toen ik Claude Code opnieuw opende. Ik moest elke loop handmatig opnieuw aanmaken, en omdat ik de exacte commando's nergens had opgeslagen, besteedde ik tien minuten aan het reconstrueren vanuit mijn geheugen.
Dit leerde me mijn eerste echte les over Loop: behandel je loop-commando's als code. Sla ze ergens op.
Ik bewaar nu een bestand genaamd loops.md in mijn project-root dat er zo uitziet:
# Active Loop Commands
## Deploy Monitor (during active deployments)
/loop every 15 minutes check the deployment status on staging and alert me if any service shows errors or restarts
## GitHub Issue Watch (daily work hours)
/loop every hour check my assigned GitHub issues and summarize any new ones or status changes
## Lint Guard (during active development)
/loop every 30 minutes run eslint on files changed in the last hour and report any new warnings or errors
## Break Reminder (always)
/loop every 90 minutes remind me to stand up, stretch, and look away from the screen for 2 minutes
Wanneer ik een nieuwe sessie start, plak ik gewoon de relevante commando's erin. Kost dertig seconden in plaats van tien minuten reconstructie. Het is niet elegant, maar het werkt.
Er is nog een beperking ingebakken in het sessiegebonden ontwerp: het driedagenmaximum. Zelfs als je een sessie continu draaiende houdt, verloopt elke loop na 72 uur. Anthropic heeft dit duidelijk ontworpen als een vangnet tegen ongecontroleerd tokenverbruik, en eerlijk gezegd denk ik dat dat de juiste keuze is. Maar het betekent dat Loop fundamenteel een tool voor de korte termijn is.
Dit onderscheid wordt cruciaal wanneer je Loop vergelijkt met Scheduled Tasks — een aparte functie die Anthropic bouwt voor langdurige, persistente automatisering. Ik ga precies uitleggen wanneer je welke moet gebruiken in het implementatiegedeelte. De korte versie: als je taak leeft en sterft met je huidige werksessie, is Loop perfect. Als het een herstart moet overleven, heb je iets anders nodig.
De sessie-isolatie creëert nog één subtiel probleem dat me overviel.
Context-verval: de verborgen kosten van langlopende loops
Na ongeveer zes uur onafgebroken loop-uitvoering merkte ik iets vreemds op. Mijn deployment-monitor loop begon steeds vagere en soms licht onnauwkeurige samenvattingen te geven. De eerste paar check-ins waren scherp — specifieke servicenamen, exacte foutaantallen, duidelijke statusindicatoren. Tegen uur zes waren de antwoorden breder en minder precies geworden.
Dit is wat ik "context-verval" ben gaan noemen, en het gebeurt vanwege de manier waarop Loop interacteert met het contextvenster van Claude Code.
Elke loop-aanroep voegt toe aan de gespreksgeschiedenis van de sessie. De oorspronkelijke context — je codebase, je initiële instructies, het opgebouwde gesprek — groeit met elke loopcyclus. Naarmate het contextvenster volloopt, wordt oudere informatie gecomprimeerd of weggelaten. De oorspronkelijke instructie van je loop blijft, maar het vermogen van de AI om scherp gefocust te blijven op wat je precies vroeg, degradeert na verloop van tijd.
Stel je voor dat je een collega vertelt om elke vijftien minuten iets te controleren. De eerste paar uur zijn ze grondig en precies. Na acht uur dezelfde taak zijn ze moe, hun aandacht is verdeeld over alles wat er die dag verder is gebeurd, en hun rapporten worden slordiger. Zelfde principe — ander mechanisme.
Ik heb drie strategieën gevonden die helpen:
1. Houd loop-instructies atomair en specifiek. In plaats van "check de deployment en laat me weten hoe het eruitziet," schrijf "voer kubectl get pods -n staging uit en rapporteer alle pods die niet in Running-status zijn met hun restart-aantallen." Hoe specifieker de instructie, hoe bestendiger tegen context-degradatie.
2. Stop en hermaak loops elke 4-6 uur. Dit reset de opgebouwde context-overhead. Ja, het is handmatig. Ja, het is vervelend. Het is ook het meest effectieve dat je kunt doen voor loop-betrouwbaarheid.
# Snelle reset-workflow
cron list # Noteer je actieve job-ID's
cron delete <id> # Verwijder de gedegradeerde loop
# Hermaak dan met hetzelfde commando uit je loops.md bestand
3. Minimaliseer gelijktijdige loops. Elke actieve loop draagt bij aan contextgroei. Ik begon met vier simultane loops en eindigde met twee als de sweet spot voor dagenlange sessies. Drie is prima voor kortere perioden. Vier of meer en je merkt kwaliteitsdegradatie binnen een paar uur.
Deze workarounds zouden niet nodig moeten zijn in een perfecte wereld, maar Loop is een v1-functie. Het kernconcept klopt — de randjes moeten alleen nog bijgeschaafd. Over randjes gesproken, laat me je de setup laten zien die Loop echt onmisbaar maakte voor mijn dagelijkse werk.
Loop instellen voor echte ontwikkelworkflows
Vergeet de speelgoedvoorbeelden. Hier is hoe ik Loop daadwerkelijk gebruik gedurende een typische ontwikkelweek, met exacte commando's die je kunt aanpassen.
De Deployment Babysitter
Dit is de loop die ik het meest gebruik. Tijdens elke deployment die langer dan een paar minuten duurt, start ik deze op en ga terug naar echt werk:
/loop every 10 minutes run kubectl get pods -n staging --no-headers and check for any pods with status other than Running. Also run kubectl logs --tail=20 on any restarting pods. Give me a one-line summary if everything is healthy, or a detailed breakdown if anything is wrong.
Het cruciale detail hier is de "one-line summary if healthy"-instructie. Zonder dat genereert elke check-in een antwoord van meerdere alinea's dat je sessie vervuilt. Je wilt dat Loop stil is als alles goed gaat en luid als dat niet zo is.
De PR Review Watcher
Wanneer ik pull requests heb die wachten op review, bespaart deze loop me het dwangmatig checken van GitHub:
/loop every 30 minutes check the status of my open pull requests on GitHub. Report any new comments, review requests, or CI status changes since the last check. Only report if something changed — stay silent if nothing is new.
Die "stay silent if nothing is new"-instructie is cruciaal. Ik leerde dit nadat een loop me trouw elke dertig minuten "geen wijzigingen" meldde gedurende een hele middag. Behulpzaam in theorie, afleidend in de praktijk.
De Sprint Pulse Check
Tijdens een driedaagse sprint geeft deze loop me een lopend overzicht van de voortgang zonder Jira of Linear te openen:
/loop every 3 hours summarize the git log for the last 3 hours across all branches. Group commits by author and branch. Flag any force pushes or reverts. Keep it under 10 lines.
Deze is verrassend krachtig voor teamleads. In plaats van standups te houden om erachter te komen wat er is gebeurd, krijg je een rollende samenvatting. Het interval van drie uur houdt het rustig terwijl het toch het ritme van een werkdag oppikt.
De Slimme Pauzetimer
Dit klinkt triviaal, maar het is mijn meest consistent gebruikte loop:
/loop every 90 minutes remind me to take a break. Include a random interesting fact about software engineering history. Make it fun.
Het "random interesting fact"-deel zorgt ervoor dat ik de notificatie daadwerkelijk lees in plaats van weg te klikken. Vorige week vertelde het me over de Morris Worm uit 1988. De week daarvoor deelde het het verhaal van Margaret Hamilton's Apollo-navigatiecode. Klein detail, groot verschil in naleving.
Stap-voor-stap setup voor beginners
Als je Loop nog nooit hebt gebruikt, hier is het pad van nul naar nuttig:
Stap 1: Controleer of je Loop-toegang hebt.
Open Claude Code (terminal, VS Code of desktopapp) en typ:
cron list
Als je een lege lijst of een opgemaakt antwoord terugkrijgt, zit je goed. Als je een foutmelding krijgt, update dan naar de nieuwste versie van Claude Code.
Stap 2: Begin met een eenmalige herinnering om vertrouwen op te bouwen.
/loop in 5 minutes remind me that Loop is working
Wacht vijf minuten. Wanneer de herinnering afgaat en zichzelf automatisch verwijdert, weet je dat het systeem correct functioneert.
Stap 3: Maak je eerste terugkerende loop.
Begin simpel. Probeer niet op dag één je hele infrastructuur te monitoren.
/loop every 30 minutes tell me how many uncommitted changes I have and whether my current branch is behind origin
Stap 4: Controleer je actieve loops.
cron list
Je ziet output met je job-ID, schema, volgende uitvoertijd en het bijbehorende commando. Bewaar het job-ID — je hebt het nodig als je de loop wilt stoppen.
Stap 5: Leer opruimen.
cron delete <job-id>
Ruim altijd loops op die je niet meer nodig hebt. Ze verbruiken tokens, zelfs als hun output niet meer nuttig voor je is.
Protip: Als je je zorgen maakt over tokenkosten, stel je eerste loops dan in op intervallen van een uur. Je kunt de frequentie altijd verhogen zodra je het verbruikspatroon ziet. Ik houd het bij door aan het eind van elke dag mijn gebruiksdashboard te checken gedurende de eerste week.
Eén ding dat de meeste tutorials volledig overslaan: je kunt Loop op omgevingsniveau uitschakelen als je in een team werkt en onbedoeld tokenverbruik wilt voorkomen.
# Schakel loop/cron volledig uit voor een sessie
export CLAUDE_CODE_DISABLE_CRON=1
Dit is handig voor gedeelde omgevingen of CI-pipelines waar je absoluut niet wilt dat iemands loop de rekening opjaagt. Nu is er een vergelijking die belangrijk wordt zodra je voor echt werk op Loop vertrouwt.
Loop vs. Scheduled Tasks: het juiste gereedschap kiezen
Anthropic bouwt twee aparte schedulingsystemen, en de naamverwarring heeft bijna iedereen die ik heb gesproken op het verkeerde been gezet. Hier is de helderste uitleg die ik kan geven.
Loop is je assistent binnen de sessie. Zie het als een post-it op je beeldscherm die toevallig ook commando's kan uitvoeren en resultaten kan analyseren. Het bestaat alleen terwijl je werkt, het verdwijnt wanneer je weggaat, en het heeft een maximum van drie dagen. De superkracht is het gemak zonder setup — natuurlijke taal, directe activering, direct geïntegreerd in je codeerflow.
Scheduled Tasks is de persistente automatiseringslaag. Het overleeft herstarts, draait onbeperkt door, haalt gemiste intervallen in en werkt meer als een traditionele cron-daemon met AI-mogelijkheden. Op dit moment is het alleen beschikbaar in de desktopapp, hoewel Anthropic de platformondersteuning aan het uitbreiden is.
Hier is wanneer elk zijn sterke punt heeft:
Gebruik Loop wanneer:
- Je actief aan het werk bent en achtergrondmonitoring wilt
- De taak alleen relevant is tijdens deze specifieke werksessie
- Je iets in 5 seconden draaiend nodig hebt zonder configuratie
- Je in VS Code of de terminal werkt (waar Scheduled Tasks nog niet beschikbaar is)
- De monitoringperiode uren is, geen weken
Gebruik Scheduled Tasks wanneer:
- De automatisering machine-herstarts moet overleven
- Je inhaalgedrag nodig hebt (gemiste taken uitvoeren na downtime)
- De taak onbeperkt draait — dagelijkse rapporten, wekelijkse samenvattingen, doorlopende monitoring
- Betrouwbaarheid belangrijker is dan gemak
- Je workflowautomatisering bouwt waar anderen van afhankelijk zijn
De fout die ik ontwikkelaars zie maken is Loop proberen te gebruiken voor dingen die persistentie nodig hebben. Een deploymentmonitor tijdens een twee uur durende rollout? Perfect Loop-terrein. Een dagelijks codekwaliteitsrapport dat elke ochtend om 9 uur draait? Dat is een Scheduled Task, en Loop ervoor gebruiken betekent dat je het handmatig opnieuw moet aanmaken elke keer dat je je machine herstart.
Ik heb beide systemen een week lang parallel gedraaid om de grenzen te testen. Loop handelde mijn monitoring-tijdens-het-werk prachtig af. Scheduled Tasks draaide mijn ochtendsamenvatting en eindedagrapport zonder dat ik eraan hoefde te denken. De combinatie is oprecht krachtig — maar alleen als je de grens tussen tijdelijk en persistent respecteert.
Er is nog één ding aan deze vergelijking dat volgens mij onthult waar Anthropic strategisch naartoe gaat. Het feit dat ze twee aparte systemen hebben gebouwd in plaats van simpelweg persistentie aan Loop toe te voegen, vertelt me dat ze in-sessie AI-assistentie en achtergrondautomatisering als fundamenteel verschillende producten zien. Loop gaat over het slimmer maken van je huidige sessie. Scheduled Tasks gaat over het slimmer maken van je workflow, zelfs als je niet achter je toetsenbord zit. Beide zijn belangrijk. Ze bedienen verschillende behoeften.
Met die context helder, laat me het eerlijke deel delen — de dingen die misgingen en wat ik oprecht anders zou willen.
De eerlijke beoordeling: wat ik wou dat iemand me had verteld
Ik heb tot nu toe een vrij optimistisch beeld geschetst, en het meeste daarvan is verdiend. Loop heeft mijn dagelijkse workflow oprecht verbeterd. Maar ik zou je een slechte dienst bewijzen als ik niet over de ruwe randjes zou praten, want sommige zijn scherp genoeg om te snijden.
Tokenverbruik is reëel en loopt snel op. Ik noemde dit eerder, maar laat me er echte cijfers op zetten. Tijdens een intensieve Loop-week — drie gelijktijdige loops gedurende werkdagen van acht uur — steeg mijn tokenverbruik met ruwweg 40% vergeleken met mijn baseline zonder Loop. Voor individuele ontwikkelaars op verbruiksgebaseerde prijzen is dat een betekenisvolle kostenstijging. Voor teams kan het significant zijn. Ik denk niet dat dit een dealbreaker is, maar je moet er budget voor reserveren. De productiviteitswinst rechtvaardigt de kosten ruimschoots in mijn geval, maar jouw rekensom kan anders uitvallen.
Het "geen inhaal"-gedrag is vervelender dan je zou verwachten. Als je machine twintig minuten slaapt en een loop op minuut tien had moeten afgaan, is die uitvoering simpelweg verloren. Hij draait niet alsnog wanneer je weer wakker wordt. Hij slaat gewoon over naar het volgende geplande interval. Voor monitoringtaken betekent dit dat je events kunt missen tijdens slaapperioden. Ik ben mijn machine op "nooit slapen" gaan zetten tijdens actieve deployment-monitoring, wat een absurde workaround is voor wat een ingebouwde functie zou moeten zijn.
Sessie-isolatie betekent geen globaal beheer. Als je Loop draait in een VS Code-venster en je opent een terminalsessie, kun je de VS Code-loops niet zien of beheren vanuit de terminal. Elke sessie is een eigen eiland. Ik heb per ongeluk dubbele loops gehad draaien omdat ik was vergeten dat ik er een had ingesteld in een ander venster. Er is geen cron list --all-sessions-commando, en ik wou dat het er was.
Foutafhandeling is minimaal. Wanneer het commando van een loop faalt — misschien is de kubectl-context verlopen, of heeft de GitHub-API je rate-gelimiteerd — rapporteert de loop gewoon de fout en blijft op schema afgaan. Het vertraagt niet, het probeert niet opnieuw met andere parameters, het waarschuwt je niet dat het de laatste zes cycli heeft gefaald. Je moet actief je monitors monitoren, wat ironisch is.
De driedagenlimiet voelt willekeurig voor sommige use cases. Ik had een oprechte reden om een loop vijf dagen te draaien tijdens een langdurige migratie. Dat kon niet. De loop verliep op dag drie, en ik moest onthouden om hem op dag vier handmatig opnieuw aan te maken. Alsjeblieft, laat me mijn eigen vervaldatum instellen.
Hier is mijn controversiële mening: ik denk dat Loop ongeveer zes maanden te vroeg is uitgebracht. Het kernidee is briljant — AI-assistenten tijdsbesef geven is de voor de hand liggende volgende stap in de evolutie van codeertools. Maar de implementatie heeft genoeg hiaten dat je workarounds nodig hebt voor basisscenario's. Sessiepersistentie, inhaaluitvoering, cross-sessiebeheer en slimmere foutafhandeling hadden in v1 moeten zitten.
Dat gezegd hebbende — en ik wil hier duidelijk over zijn — ik gebruik Loop nog steeds elke dag. De hiaten zijn vervelend, niet diskwalificerend. De productiviteitswinst van alleen al de basis deployment-monitoring loop is genoeg om te rechtvaardigen dat je met de ruwe randjes leeft. Ik wil alleen dat de randjes bijgeschaafd worden, en ik denk dat Anthropic dat ook weet.
Ik dacht eerst dat mijn frustratie betekende dat de functie niet klaar was. Nu denk ik dat het betekent dat de functie belangrijk genoeg is om frustrerend te zijn wanneer hij tekortschiet. Er is een verschil.
Met al die eerlijkheid op tafel, laat me je de daadwerkelijke resultaten tonen van twee weken gestructureerd Loop-gebruik.
Twee weken Loop: de cijfers
Ik heb mijn workflowmetrics twee weken lang bijgehouden met Loop actief versus twee weken zonder. De vergelijking is niet perfect wetenschappelijk — verschillende projecten, verschillende deadlines — maar de trends zijn duidelijk genoeg om betekenisvol te zijn.
Contextwissel-reductie: 60% omlaag. Dit is de grootste winst en het is niet eens close. Vóór Loop checkte ik handmatig deploymentstatus, CI-pipelines en GitHub-notificaties gemiddeld 22 keer per dag. Met Loop die die checks afhandelt, daalde ik naar ongeveer 9 handmatige checks — en de meeste daarvan waren om Loop's rapporten te verifiëren, niet omdat ik onafhankelijk moest controleren.
Flow-state duur: ruwweg 35% omhoog. Mijn langste ononderbroken codeersessies gingen van gemiddeld ongeveer 45 minuten naar meer dan een uur. Dit klopt met de contextwissel-reductie — minder onderbrekingen betekent langere focusperioden. Ik heb dit losjes gemeten met de activiteitsregistratie van mijn IDE, dus neem het exacte percentage met een korreltje zout. De richting van de verbetering is echter echt.
Deploymentvertrouwen: merkbaar hoger. Dit is kwalitatief, niet kwantitatief, maar het doet ertoe. Weten dat Loop elke tien minuten mijn deploy in de gaten houdt, laat me daadwerkelijk focussen op ander werk tijdens rollouts in plaats van boven dashboards te hangen. Ik heb twee features geshipt tijdens deployment-vensters die ik normaal had laten liggen tot na de rollout.
Tokenkostenstijging: ongeveer 40% op intensieve Loop-dagen. Zoals hierboven vermeld. Op dagen dat ik slechts één of twee loops draaide met intervallen van een uur lag de stijging dichter bij 15%. De kosten schalen lineair met het aantal loops en de frequentie, wat het in elk geval voorspelbaar maakt.
Tijd besteed aan loop-beheer: ongeveer 5 minuten per dag. Loops aanmaken bij sessiestart, af en toe stoppen en opnieuw aanmaken voor het context-vervalprobleem, en opruimen aan het einde van de dag. Verwaarloosbare overhead voor de geleverde waarde.
De metric die mij het meest interesseert — en de moeilijkst meetbare — is cognitieve belasting. Twee weken lang verdween een significant deel van mijn mentale achtergrondgeruis ("is de deploy klaar?", "heeft iemand op mijn PR gereageerd?", "draait CI al te lang?") simpelweg. Loop handelde die gedachten voor me af. De mentale ruimte die dat vrijmaakte is meer waard dan welke kwantitatieve metric dan ook.
Hier is wat ik de snelle overwinningen versus de langetermijnwaarde zou noemen:
Snelle overwinningen (dag één): Pauzeherinneringen, deployment-monitoring tijdens actieve rollouts, eenmalige herinneringen voor vergaderingen en deadlines. Deze vereisen nul leercurve en verminderen onmiddellijk frictie.
Langetermijnwaarde (week twee en verder): Aangepaste loopbibliotheken opgeslagen in je project, teamspecifieke monitoringpatronen, integratie met je specifieke toolchain (kubectl, gh cli, custom scripts). Dit vereist experimenteren en itereren, maar het samengestelde rendement is significant.
Als je je afvraagt of Loop het proberen waard is — stop met afvragen. Stel morgenochtend één loop in. De deployment-monitor als je backendwerk doet, de PR-watcher als je in review-intensieve cycli zit, of de pauzetimer als je gewoon wilt voelen hoe de functie aanvoelt. Vijf minuten setup. Je weet binnen twee uur of het in je workflow past.
De vraag die me 's nachts wakker houdt
Twee maanden geleden was ik de cron-job. Handmatig deploys checken, handmatig scannen op PR-reviews, handmatig elke operationele zorg bijhouden terwijl ik probeerde code te schrijven. Loop veranderde dat — niet volledig, niet perfect, maar op een betekenisvolle manier.
Wat me het meest treft aan deze functie is niet wat het vandaag doet. Het is wat het signaleert over morgen. Wanneer je AI-assistent een klok krijgt, stopt het met een tool zijn die je gebruikt en begint het een collega te worden die oplet. Loop is een eerste versie van dat idee. Scheduled Tasks is de tweede versie. De derde versie — waarin je AI-assistent proactief dingen opmerkt waar je niet eens om hebt gevraagd — is waarschijnlijk dichterbij dan wie van ons ook denkt.
Ik kom steeds terug bij die deploynacht om 1:47 uur. Vier uur lang een menselijke cron-job zijn. Met Loop comprimeert die hele nacht tot één commando en een goede nachtrust. De AI kijkt. De AI rapporteert. Jij rust.
De functie is niet perfect. Het sessie-persistentiegat is echt. Het context-verval moet opgelost worden. De driedagenlimiet heeft flexibiliteit nodig. Maar het kernidee — AI tijdsbesef en terugkerende autonomie geven binnen je ontwikkelworkflow — is zo overduidelijk juist dat de beperkingen tijdelijk aanvoelen.
Dus hier is mijn uitdaging: kies één ding dat je meer dan drie keer per dag handmatig controleert. Eentje maar. Stel er morgen een loop voor in. Draai het een week. Probeer dan terug te gaan naar handmatig controleren.
Dat ga je niet willen.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
