Ollama Geplande Prompts in Claude Code Hebben Mijn Ochtenden Veranderd
Ik werd gisteren wakker met een terminal die al dertig minuten werk voor me had gedaan.
Niet op een griezelige, Skynet-achtige manier. Meer zoals — ik opende mijn laptop, schakelde naar mijn Claude Code-sessie, en daar was het: een overzichtelijke samenvatting van CI-fouten die 's nachts waren opgetreden in drie projecten, een digest van AI-nieuws van de afgelopen 24 uur, en een herinnering dat ik een klant voor de middag een implementatieschatting had beloofd. Alles stond er keurig, te wachten, gegenereerd terwijl ik sliep.
Ik had geen cron-job geschreven. Ik had geen uitgebreide n8n-workflow opgezet. Ik had geen drie SaaS-tools met webhooks aan elkaar geplakt. Ik had de avond ervoor één regel getypt — /loop Give me the latest AI news every morning — en Ollama draaiend in Claude Code had het gewoon... gedaan.
Dit is een van die functies die klein klinkt als je het beschrijft en enorm aanvoelt als je het gebruikt. Ollama kan nu geplande prompts direct in Claude Code uitvoeren, en na een week van het bouwen van mijn complete ochtendroutine eromheen, ben ik ervan overtuigd dat dit de manier is waarop ontwikkelomgevingen voortaan gaan werken. Niet als tools die je oppakt en neerlegt, maar als omgevingssystemen die naast je werken — soms je voor.
Hier is alles wat ik heb geleerd bij het opzetten hiervan, wat écht werkt, wat nog ruw is, en waarom ik denk dat dit veel belangrijker is dan het er op het eerste gezicht uitziet.
Hoe Ik Hierop Stuitte (en Waarom Ik Het Bijna Miste)
Ik had Ollama al maanden lokaal draaien. Voornamelijk voor snelle lokale inferentie — prompts offline testen, kleinere modellen draaien als ik geen API-credits wilde verbranden, dat soort dingen. Nuttig, maar niets dat mijn workflow fundamenteel veranderde.
Toen noemde een collega, bijna terloops, dat Ollama was geïntegreerd met Claude Code's planningssysteem. Mijn eerste reactie was scepsis. Prompts plannen klonk als een gimmick — iets wat je op een conferentie zou demonstreren maar dagelijks nooit echt zou gebruiken.
Ik had het mis. Spectaculair mis.
De integratie werkt als volgt: je start Ollama via Claude Code met ollama launch claude, waarmee een Ollama-instantie wordt opgestart die zich bewust is van je Claude Code-omgeving — je projectcontext, je bestandssysteem, je draaiende processen. Vervolgens gebruik je het /loop-commando om terugkerende prompts te plannen die op door jou gedefinieerde intervallen worden uitgevoerd.
Dat zijn de mechanismen. De magie zit in wat je ermee doet.
Want zodra je ontwikkelomgeving prompts op een schema kan uitvoeren — ongevraagd, op de achtergrond, terwijl je andere dingen doet of niet eens aan je bureau zit — verschuift de hele relatie tussen jou en je tools. Je stopt met AI te zien als iets wat je ondervraagt en begint het te zien als iets dat observeert, controleert en rapporteert. Een omgevingslaag van intelligentie die bovenop je workflow ligt.
Maar ik loop op de zaken vooruit. Laat me je door de daadwerkelijke installatie leiden, want de details zijn belangrijker dan het concept.
Ollama Aan de Praat Krijgen Binnen Claude Code
De vereiste is eenvoudig: je hebt Ollama lokaal geïnstalleerd nodig en Claude Code draaiend in je terminal. Als je beide hebt, ben je negentig procent van de weg al.
Stap 1: Start Ollama via Claude Code.
Open je Claude Code-sessie en voer uit:
ollama launch claude
Dit is niet hetzelfde als ollama serve in een apart terminalvenster uitvoeren. Het commando ollama launch claude creëert een brug tussen Ollama's lokale modelrunner en het agentframework van Claude Code. Je Ollama-instantie erft contextbewustzijn — het weet in welk project je zit, welke bestanden er bestaan, op welke git-branch je bent. Deze context is wat geplande prompts daadwerkelijk nuttig maakt in plaats van slechts generiek.
Stap 2: Verifieer de verbinding.
Je zou een bevestiging moeten zien dat Ollama actief is binnen je Claude Code-omgeving. Probeer een snelle testprompt om er zeker van te zijn dat alles correct is verbonden:
/loop What time is it? every 5 minutes
Als je een reactie ziet die bevestigt dat de loop is gepland, zit je goed. Verwijder die testloop voordat hij je sessie volkladdert — we gaan nu echte loops instellen.
Stap 3: Begrijp de /loop-syntaxis.
Het /loop-commando volgt een patroon in natuurlijke taal:
/loop [jouw prompt] every [interval]
Intervallen kunnen worden opgegeven in minuten, uren of tijdsankers. Hier zijn voorbeelden die daadwerkelijk werken:
/loop Summarize my git diff every 2 hours
/loop Check for failing tests every 30 minutes
/loop Give me a standup summary every morning at 9am
/loop Review open PRs and flag stale ones every day at 3pm
De verwerking van natuurlijke taal is verrassend flexibel. Ik heb er wat ongebruikelijk geformuleerde schema's aan gevoed en het begrijpt over het algemeen wat ik bedoel. "Every weekday morning" werkt. "Twice a day" werkt. "Every Monday" werkt.
Dit is wat het onderscheidt van het simpelweg instellen van een cron-job met een curl-commando naar een API. De prompts worden uitgevoerd binnen je Claude Code-context. Ze kunnen je projectbestanden zien. Ze kunnen je git-geschiedenis lezen. Ze kunnen je draaiende processen controleren. Ze kunnen verwijzen naar eerdere loop-uitvoer. Een cron-job is toestandsloos en blind. Een /loop-prompt is contextueel en bewust.
Dat onderscheid is alles, en dat begreep ik pas toen ik echte automatiseringen eromheen begon te bouwen.
De Zeven Loops Die Mijn Workflow Echt Veranderden
Ik experimenteerde afgelopen week met tientallen geplande prompts. De meeste waren nutteloos — noviteitsexperimenten die dag twee niet overleefden. Maar zeven ervan bleven hangen, en ze hebben oprecht geherstructureerd hoe ik mijn werkdag begin, doorloop en afsluit. Laat me je door elk ervan leiden, want de specifieke prompts zijn belangrijk.
Loop 1: Het Ochtendbriefing
/loop Give me a morning briefing: summarize overnight git commits across all projects in this workspace, list any CI/CD failures, and flag PRs that have been open more than 48 hours. every morning at 8:30am
Dit is degene die me heeft gegrepen. Voordat ik Slack open, voordat ik e-mail check, heb ik een helder beeld van wat er 's nachts is gebeurd. Voor iemand die meerdere projecten beheert — wat, als je een freelance-ontwikkelaar of teamleider van een klein team bent, waarschijnlijk het geval is — elimineert dit de eerste twintig minuten van context-switching elke ochtend.
De uitvoer is niet slechts een onbewerkte git log-dump. Omdat de prompt binnen Claude Code met volledige context wordt uitgevoerd, vat het daadwerkelijk samen wat er is veranderd in voor mensen leesbare termen. "De auth-module kreeg drie commits van de feature-branch — het lijkt erop dat de sessieafhandeling is gerefactord" is oneindig nuttiger dan een lijst met commit-hashes.
Loop 2: De Testwachthond
/loop Run the test suite and report only failures with a brief diagnosis of what might be wrong. every 2 hours
Ik voerde tests vroeger handmatig uit of vertrouwde op CI om fouten te onderscheppen nadat ik al had gepusht. Nu voert mijn lokale omgeving de suite elke twee uur uit en geeft me een waarschuwing voordat slechte code mijn machine verlaat. Het "brief diagnosis"-deel is cruciaal — het zegt niet alleen "test_user_auth mislukt," het zegt "test_user_auth mislukt omdat de mock-database niet het verwachte sessietoken-formaat retourneert. Het lijkt erop dat de schemawijziging in migratie 047 lokaal misschien niet is toegepast."
Is de diagnose altijd correct? Nee. Misschien 70% van de tijd klopt het precies, 20% zit het in de goede richting, en 10% klopt het totaal niet. Maar zelfs een verkeerde diagnose geeft me een startpunt, wat beter is dan staren naar een stacktrace zonder context.
Loop 3: De Afhankelijkheidsauditor
/loop Check package.json and requirements.txt for any dependencies with known vulnerabilities or major version updates available. every day at noon
Beveiligingshygiëne is een van die dingen waarover iedereen het eens is dat het belangrijk is en niemand consistent doet. Deze loop handelt het passief af. Eén keer per dag krijg ik een beknopt rapport: "lodash heeft een patch beschikbaar, geen beveiligingsproblemen. Het jsonwebtoken-pakket is twee grote versies achter en heeft een matige CVE." Ik kan ernaar handelen of het voor later noteren, maar in elk geval ben ik op de hoogte.
Loop 4: De PR-aanmaner
/loop Check all open pull requests in this repo. For any PR older than 24 hours without a review, remind me and suggest what to prioritize reviewing first based on the diff size and files changed. every day at 2pm
Deze is verrassend effectief voor teamdynamiek. Ik ben slecht in het onthouden om PRs tijdig te reviewen — ik ga diep in mijn eigen werk en vergeet het. Nu krijg ik elke middag een herinnering met echte context over welke review het belangrijkst is. Kleine diff die een kritiek bestand raakt? Dat wordt gemarkeerd als hoge prioriteit. Grote refactor zonder testwijzigingen? Dat wordt gemarkeerd als "vereist zorgvuldige review."
Loop 5: De Documentatie-driftdetector
/loop Compare the current API routes in the codebase with the API documentation file. Flag any endpoints that exist in code but aren't documented, or documented but no longer exist in code. every 3 days
Documentatieveroudering is een echt probleem in elk project waar ik aan heb gewerkt. Deze loop vangt het voordat het ernstig wordt. Elke drie dagen kom ik erachter of de documenten nog overeenkomen met de werkelijkheid. Het interval is lang genoeg om niet storend te zijn, kort genoeg zodat drift niet wekenlang oploopt.
Loop 6: De Einde-van-de-dag-samenvatting
/loop Summarize what I worked on today based on git commits, file changes, and terminal history. Format it as bullet points I could paste into a standup message. every weekday at 5:30pm
Dit is pure luiheidsoptimalisatie, en ik hou ervan. Ik haat het schrijven van standup-updates. Verfoeijk het. Deze loop genereert een eerste versie die voor 80% klopt, en ik besteed dertig seconden aan het aanpassen ervan in plaats van vijf minuten proberen te herinneren wat ik zeven uur geleden heb gedaan.
Loop 7: Het AI-nieuwsdigest
/loop Give me the latest AI news and notable releases from the last 24 hours, focused on developer tools, LLM updates, and open-source AI projects. every morning at 8am
Dit was eigenlijk de eerste loop die ik instelde — degene uit het begin van dit bericht. Actueel blijven in AI is oprecht moeilijk als het veld zo snel beweegt. Een dagelijks digest dat op me wacht voordat ik aan het werk ga, betekent dat ik nooit meer dan 24 uur achterloop op iets belangrijks.
De kwaliteit van deze digests hangt af van de kennisgrens van het model en wat het kan raadplegen, wat een beperking is waar ik eerlijk over zal zijn in een paar secties. Maar zelfs onvolmaakte nieuwssamenvattingen zijn beter dan het alternatief: dertig minuten doomscrolling op Twitter om te begrijpen wat er gisteren is gebeurd.
Nu wordt het echt interessant — want deze zeven loops zijn slechts de voor de hand liggende gebruiksgevallen. De architecturale implicaties gaan veel dieper.
De Echte Verschuiving: Van Reactieve Tools naar Omgevingsintelligentie
Ik wil even uitzoomen, want ik denk dat de meeste berichtgeving over dergelijke functies het grotere geheel mist.
Gedurende de hele geschiedenis van softwareontwikkeling waren onze tools reactief. Je opent je editor — het wacht. Je typt een commando — het wordt uitgevoerd. Je stelt een vraag — het antwoordt. Het tool doet niets totdat jij het initiatief neemt. Elke interactie begint bij jou.
Geplande prompts doorbreken dat patroon fundamenteel.
Je ontwikkelomgeving doet nu dingen zonder dat ernaar gevraagd wordt. Het monitort, analyseert, vat samen en geeft waarschuwingen op zijn eigen schema. Niet op een "set it and forget it"-automatiseringsmanier — dit is geen bash-script dat op cron draait. De prompts zijn contextueel, adaptief en intelligent. Ze begrijpen je codebase. Ze kunnen redeneren over wat ze vinden.
Dit is wat omgevingsintelligentie er in de praktijk uitziet. Niet een sci-fi holografische assistent die naast je bureau zweeft. Gewoon een terminal die rustig nuttig werk op de achtergrond uitvoert terwijl jij je focust op de moeilijke problemen.
Denk eens na over wat dit betekent voor een typische werkdag. Vroeger begon je je ochtend met het handmatig controleren van de CI-status, het bekijken van nachtelijke commits, het scannen op open PRs en het bijhouden van wat er was veranderd. Dat is 30-45 minuten context-laden voordat je een enkele regel code schrijft.
Met geplande loops is die context vooraf geladen. Je gaat zitten, kijkt even naar de samenvattingen, en je bent al georiënteerd. Je begint meteen te coderen, op volle snelheid, met volledig bewustzijn.
Over een week is dat 2-4 uur bespaard. Over een maand is het een volledige dag of meer. En dat zijn alleen de tijdbesparingen — de cognitieve besparingen zijn moeilijker te kwantificeren maar aantoonbaar waardevoller. Elke contextwisseling die je elimineert, is mentale energie bewaard voor daadwerkelijk probleemoplossen.
Ik heb hierover nagedacht in termen van wat ik "ontwikkelaarsaandachtsschuld" noem. Elke handmatige controle, elke statusreview, elke "laat me eens kijken wat er met de build aan de hand is" is een kleine onttrekking uit je dagelijkse aandachtsbudget. Individueel triviaal. Collectief verwoestend. Geplande prompts betalen die schuld automatisch af.
Maar — en hier wordt mijn enthousiasme getemperd door eerlijkheid — de huidige implementatie heeft echte beperkingen die je moet kennen voordat je je complete workflow hieromheen herbouwt.
Wat Nog Niet Werkt (Eerlijke Beoordeling)
Ik zou je een slechte dienst bewijzen als ik dit als makeloos afschilderde. Na een week intensief gebruik, dit is wat ruw is.
De planning is niet perfect betrouwbaar. Loops slaan af en toe een cyclus over, vooral als je machine in slaapstand gaat of als de Claude Code-sessie wordt onderbroken. Mijn ochtendbriefing heeft niet gefired omdat mijn laptoplid gesloten was om 8:30 uur 's ochtends. Dit is een lokaal uitvoeringsmodel — er is geen cloudplanner die het opvangt. Als het proces niet draait, wordt de loop niet uitgevoerd. Je kunt het niet behandelen als een server-side cron-job die altijd afgaat.
Lange prompts produceren soms inconsistente uitvoer. Mijn complexere loops — degenen met meerdelige instructies zoals de ochtendbriefing — focussen af en toe op één onderdeel en slaan een ander over. De PR-controle kan grondig zijn terwijl de CI-foutsamenvatting een enkele zin krijgt. Kortere, meer gerichte prompts zijn betrouwbaarder dan alles-in-één-prompts. Ik ben complexe briefings gaan splitsen in twee of drie aparte loops in plaats van één megaprompt.
Contextvensterdruk is reëel. Elke loop-uitvoering verbruikt context. Als je zes loops gedurende de dag uitvoert en ook actief ontwikkelwerk doet in dezelfde Claude Code-sessie, kun je contextlimieten sneller bereiken dan verwacht. Ik heb sessies gehad waar mijn middagloops merkbaar slechtere uitvoer produceerden omdat het contextvenster verzadigd was met ochtendloopresultaten plus mijn daadwerkelijke werk. De oplossing is je sessie actief beheren — context wissen als het zwaar wordt, of loops uitvoeren in een speciale sessie gescheiden van je ontwikkelwerk.
Modelkennisgrenzen gelden. De AI-nieuwsdigestloop is nuttig maar inherent beperkt door wat het model weet. Het kan niet in realtime op het internet browsen (tenzij je tools voor webtoegang hebt ingesteld). Dus "latest AI news" betekent eigenlijk "wat ik kan afleiden of herinneren tot mijn trainingsgrens, plus alles in je lokale bestanden." Voor echt actueel nieuws zou je de loop moeten koppelen aan een web-fetchtool of RSS-integratie. Ik werk hier nog aan, maar het is nog niet naadloos.
Geen ingebouwde loop-beheersinterface. Er is geen dashboard dat je actieve loops toont, hun laatste uitvoeringstijd of hun uitvoergeschiedenis. Het staat allemaal in je terminalscrolfuffer. Als je wilt bekijken wat een loop drie dagen geleden rapporteerde, zoek je in de terminalgeschiedenis. Ik ben loop-uitvoer als workaround naar bestanden gaan loggen:
/loop Check for failing tests and append results to ./logs/test-watchdog.log every 2 hours
Dit werkt maar voelt als een noodoplossing. Een goede loop-beheersinterface — actieve loops weergeven, ze pauzeren/hervatten, uitvoergeschiedenis bekijken — zou deze functie aanzienlijk nuttiger maken.
Resourceverbruik telt op. Elke loop-uitvoering verbruikt rekenkracht. Ollama lokaal draaien betekent dat je CPU en RAM inferentie afhandelen. Zes loops die gedurende de dag op een laptop afgaan, kunnen de ventilatoren laten draaien en de batterij merkbaar verbruiken. Ik heb geleerd selectief te zijn over loop-frequentie. Niet alles hoeft elke 30 minuten te worden uitgevoerd. De meeste dingen zijn prima met 2-uurs of dagelijkse intervallen.
Dit zijn geen dealbreakers. Elk van deze beperkingen is oplosbaar, en ik durf te wedden dat de meeste ervan in komende updates worden aangepakt. Maar er vooraf van weten bespaart je de frustratie van ze middenin je workflow te ontdekken, wat precies de frustratie is die ik doormaakte zodat jij dat niet hoeft te doen.
De beperkingen zijn reëel, maar ze veranderen de fundamentele waardepropositie niet. Wat me brengt bij het deel waar ik het meest enthousiast over ben.
Een Complete Omgevingsworkflow Bouwen: Mijn Huidige Setup
Na een week van iteratie, dit is mijn complete loopconfiguratie. Ik deel de exacte prompts omdat de specifieke bewoording uitmaakt — vage prompts produceren vage resultaten.
Sessie 1: Ontwikkelomgeving (primaire Claude Code-sessie)
/loop Run the test suite for the current project, report failures only with one-line explanations. every 2 hours
/loop Scan the current git diff and warn me if I'm about to commit any hardcoded secrets, API keys, or credentials. every 30 minutes
Ik houd de ontwikkelsessie lean — slechts twee loops die direct relevant zijn voor wat ik actief aan het bouwen ben. De geheimenscanner alleen al heeft me tweemaal gered van het committen van een .env-waarde die in een configuratiebestand was terechtgekomen.
Sessie 2: Projectoperaties (aparte Claude Code-sessie, draait in een achtergrondterminaltabblad)
/loop Morning briefing: overnight commits summary, CI status, stale PRs. every weekday at 8:30am
/loop Scan dependencies for known CVEs and available security patches. every day at noon
/loop End-of-day summary: what changed today in bullet point format. every weekday at 5:30pm
Deze sessie handelt de operationele overhead af. Ik kijk er een paar keer per dag naar, maar het concurreert niet om context met mijn daadwerkelijke coderingswerk.
Sessie 3: Leren en Bewustzijn (derde sessie, lichtgewicht)
/loop AI development news and tool releases from the last 24 hours. every morning at 8am
Één loop, één doel. De leersessie gescheiden houden betekent dat het nooit de werkcontext verdringt.
Drie sessies, zes loops totaal. Mijn CPU handelt het prima af op een M-serie MacBook, al merk ik de ventilatoren als alle drie sessies actief zijn en ik ook Docker draai. De resourcevoetafdruk is beheersbaar maar niet verwaarloosbaar.
Zo speelt dit af op een typische dinsdag:
8:00 uur — AI-nieuwsdigest staat te wachten. Ik scan het terwijl de koffie zet. Twee minuten.
8:30 uur — Ochtendbriefing verschijnt. Ik weet dat CI groen is, er zijn twee open PRs (één van gisteren, één van vannacht), en de auth-refactorbranch kreeg drie commits van een medewerker. Vijf minuten lezen, en ik ben volledig georiënteerd.
9:00 uur — Ik begin met coderen met volledig projectbewustzijn. Geen aanlooptijd. Geen "wacht, waar was ik gisteren mee bezig?" Geen handmatig CI controleren. Ik begin gewoon.
10:30 uur — De geheimenscanner draait. Niets gemarkeerd. Goed. Ik verbreek de flow niet eens.
11:00 uur — Testwachthond vuurt. Twee tests falen — beide gerelateerd aan een mock die ik vergat bij te werken na de schemawijziging van gisteren. De diagnose is nauwkeurig. Ik los beide op in tien minuten.
12:00 uur — Afhankelijkheidsaudit verschijnt in de operationele sessie. Eén laag-ernstige CVE in een transitieve afhankelijkheid. Ik noteer het voor de wekelijkse updatecyclus.
13:00 uur — Testwachthond vuurt opnieuw. Nu allemaal groen. Vertrouwen dat mijn ochtendoplossingen stand hebben gehouden.
14:00 uur — PR-aanmaner (dit heb ik na dag drie aan de operationele sessie toegevoegd). Eén PR van een medewerker staat 36 uur open — het is een kleine diff die de betalingsmodule raakt. Ik review het meteen. Vijftien minuten goed besteed.
15:00 uur — Testwachthond. Allemaal groen. Geheimenscanner. Schoon.
17:30 uur — Einde-van-de-dag-samenvatting wordt gegenereerd. Ik kopieer het, pas twee bulletpoints aan, plak het in het team-Slack. Klaar in minder dan een minuut.
Totale tijd besteed aan operationele overhead: ongeveer 35 minuten, verspreid over de dag in kleine, laagdrempelige interacties. Vergelijk dat met mijn pre-looproutine waarbij ik alleen al 30+ minuten aan de ochtendcontextlading besteedde, plus nog eens 20-30 minuten over de dag aan handmatige controles en statusreviews.
De besparingen vermenigvuldigen zich. En wat nog belangrijker is: de cognitieve belasting daalde dramatisch. Ik draag niet meer "heb ik de CI gecontroleerd?" of "zijn er PRs die ik negeer?" in het achterhoofd. Het systeem regelt dat.
Dat is de echte ontgrendeling — niet tijdbesparingen, hoewel die reëel zijn, maar aandachtsbesparingen. Mijn brein heeft minder open tabbladen.
Geavanceerde Patronen Die Ik Verken
De basisloops dekken de voor de hand liggende gebruiksgevallen. Maar ik ben meer geavanceerde patronen gaan verkennen die hinten op waar dit naartoe gaat.
Geketende loops. De uitvoer van één loop gebruiken als invoer voor een andere. Bijvoorbeeld, de testwachthond detecteert een fout en schrijft die naar een logbestand. Een tweede loop monitort dat logbestand en, wanneer het een nieuwe invoer detecteert, probeert een automatische oplossing en voert de tests opnieuw uit. Ik heb dit werkend gekregen voor eenvoudige gevallen — ontbrekende imports, niet-gesloten accolades, vergeten mock-updates. Het succespercentage op automatische oplossingen is misschien 40%, maar wanneer het werkt, wordt een falende test opgelost zonder dat ik het toetsenbord aanraak.
/loop If ./logs/test-watchdog.log has new failures in the last 2 hours, attempt to fix them and re-run the affected tests. Report what you tried and whether it worked. every 2 hours offset by 15 minutes
De "offset by 15 minutes" geeft de testwachthond tijd om zijn resultaten te schrijven voordat de automatische fixer ze leest. Ruwe coördinatie, maar het werkt.
Voorwaardelijke loops. Prompts die alleen uitvoer produceren wanneer er iets interessants gebeurt. Mijn geheimenscanner is technisch gezien een voorwaardelijke loop — het waarschuwt me alleen wanneer het iets vindt. Maar je kunt dit patroon breed toepassen:
/loop Check if any new issues have been opened in this repo. Only tell me if there are new ones since the last check. every 4 hours
Stilte betekent dat alles in orde is. Uitvoer betekent dat iets aandacht nodig heeft. Dit keert het standaard om — in plaats van dat jij controleert op updates, kondigen updates zichzelf aan.
Reflectieve loops. Deze is experimenteel en eerlijk gezegd een beetje vreemd, maar ik ben er gefascineerd door. Een loop die je recente code beoordeelt en ongevraagde architectuursuggesties doet:
/loop Review the last 3 hours of git commits in this project. If you notice any patterns that suggest emerging technical debt, architectural drift, or inconsistency with the existing codebase patterns, flag them. Be specific and give suggestions. every day at 4pm
De uitvoer varieert van oprecht inzichtelijk ("Je hebt vier verschillende foutafhandelingspatronen toegevoegd in deze commits — overweeg het standaardiseren op het Result-type patroon dat je in de auth-module gebruikte") tot volledig nutteloos ("Je code ziet er goed uit, geen problemen gedetecteerd"). Ongeveer één op drie runs produceert iets waar ik daadwerkelijk naar handel. Dat trefferpercentage is laag, maar de inzichten zijn waardevol genoeg dat het de moeite waard is om te houden.
Deze patronen zijn ruw. Ze hebben betere tooling nodig, betere ketenmechanismen, beter toestandsbeheer tussen loops. Maar ze schetsen een toekomst waarin je ontwikkelomgeving niet alleen passief behulpzaam is — maar actief deelneemt aan codekwaliteit, projectbeheer en architecturale coherentie.
Wat Dit Betekent voor Ontwikkelaarsproductiviteit (Het Grotere Argument)
Ik wil een bewering doen die hyperbolisch kan klinken, dus laat me er zorgvuldig naartoe werken.
De meest productieve ontwikkelaars die ik ken, zijn niet de snelste codeurs. Het zijn degenen met de beste systemen. Ze hebben dashboards die problemen vroeg aan de oppervlakte brengen, gewoonten die contextwisseling voorkomen, routines die bewustzijn vooraf laden. Ze besteden minder tijd aan het afvragen "waar moet ik aan werken?" en meer tijd aan daadwerkelijk werken.
Geplande prompts zijn een systeemniveau-upgrade voor ontwikkelaarsproductiviteit. Niet omdat een enkele loop transformatief is, maar omdat het geaggregeerde effect van zes of zeven goed ontworpen loops een volledige categorie wrijving uit je werkdag elimineert. De categorie die ik "operationeel bewustzijn" zou noemen — weten wat er gaande is in je projecten, je team, je afhankelijkheden, je pipeline.
De meeste ontwikkelaars gaan om met operationeel bewustzijn via een combinatie van handmatige controles, Slack-meldingen, e-mailwaarschuwingen en dashboard-hoppen. Het is verspreid, reactief en onderbrekend. Geplande loops consolideren het in een enkele, stille, contextuele stroom die op je wacht wanneer je het wilt en je niet onderbreekt wanneer je dat niet wilt.
Hier is mijn grotere bewering: we zien hoe de ontwikkelomgeving evolueert van een tool naar een teamgenoot. Niet een teamgenoot die code voor je schrijft — dat is het huidige AI-gesprek, en het is belangrijk, maar het is slechts de helft van het verhaal. Een teamgenoot die de operationele periferie afhandelt. Die de dingen in de gaten houdt die je zou vergeten te controleren. Die patronen opmerkt die je zou missen omdat je te diep in implementatiedetails zit.
Het /loop-commando is een kleine functie. Het paradigma dat het mogelijk maakt, is enorm.
Denk na over waar dit naartoe gaat in twaalf maanden. Loops die coördineren tussen teamleden' omgevingen. Loops die je patronen leren en hun frequentie aanpassen. Loops die escaleren op basis van ernst — een kleine afhankelijkheidsupdate wordt rustig gelogd, een kritieke CVE triggert onmiddellijk een waarschuwing. Loops die interfaces hebben met externe diensten — je projectbeheertool, je monitoringstack, je communicatiekanalen.
Je terminal wordt een commandocentrum, niet een commandoregel.
Dat is geen voorspelling. Het is een extrapolatie van wat vandaag al werkt, maar dan met ruwere kanten. En als je de gewoonte nu begint op te bouwen — begin met het instellen van loops, begin met denken over je workflow als iets dat gedeeltelijk geautomatiseerd en continu gemonitord kan worden — zul je gepositioneerd zijn om voordeel te halen uit elke verbetering naarmate die wordt uitgeleverd.
De Een-Uur-Uitdaging
Als je tot hier hebt gelezen, begrijp je de waarde al. Dus dit is wat ik zou doen als ik jou was, vandaag, in het volgende uur.
Open Claude Code. Voer ollama launch claude uit. Stel precies twee loops in:
/loop Summarize my git activity for the day in bullet points. every weekday at 5pm
/loop Check for any failing tests and explain what's wrong. every 3 hours
Twee loops. Eenvoudig. Lage verplichting. Voer ze een week uit.
Ik durf te wedden dat je op dag drie al begint te denken aan nieuwe loops. Op dag vijf vraag je je af hoe je het zonder deed. Aan het einde van de week bouw je de soort omgevingsworkflow die ik beschreef — niet omdat ik het je zei te doen, maar omdat zodra je een ontwikkelomgeving ervaart die voor je werkt op de achtergrond, terugkeren naar een puur reactieve setup aanvoelt als rijden zonder spiegels.
Je terminal staat al open. Je AI draait al. De enige vraag is of het werkt terwijl jij dat ook doet — of alleen wanneer jij eraan denkt om het te vragen.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (bedrijfsoplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
