Week 18: De-skillen om controle terug te pakken

Ik schreef deze week een zin in mijn journal die bleef hangen: ik ben begonnen met het de-skillen van mijn dagelijkse taken.

Dat klinkt alsof ik vaardigheden aan het afleren ben. Alsof ik mezelf minder capabel maak. Maar het tegenovergestelde is waar. Ik merkte juist dat sommige taken te belangrijk, te herhaalbaar en te foutgevoelig waren geworden om ze alleen als Claude Code Skill te blijven beschrijven. De routine werkte vaak goed, maar ik moest de uitkomst te vaak bijsturen.

Vorige week ging het over afhankelijkheid van tools. Claude Code lag eruit door identiteitsverificatie, en ineens werd zichtbaar hoeveel van mijn dagelijkse werk in een specifieke interface zat. Deze week kwam daar een tweede inzicht bovenop: zelfs als je workflow model-onafhankelijk is, betekent dat nog niet dat hij onderhoudbaar genoeg is.

Van skill naar programma

Mijn /run-daily skill is een goed voorbeeld. Die routine doet vaste dingen: een dagelijkse samenvatting genereren, podcaststatistieken bijwerken, soms een LinkedIn-draft maken, soms een topic scout draaien, soms een blogpost publiceren. Het leek ideaal om dat als skill te beheren. Een taak erbij? Gewoon een stap toevoegen.

In de praktijk werd het subtiel rommeliger.

Skills zijn sterk als ze intentie overbrengen: dit is het doel, dit zijn de randvoorwaarden, zo wil ik dat je werkt. Maar vaste productieprocessen vragen meer dan intentie. Ze vragen voorspelbaarheid, checks en minder ruimte voor interpretatie.

Daarom ben ik begonnen met het uitprogrammeren van die vaste stappen. Niet alles hoeft uit de skill te verdwijnen. De skill blijft goed als orchestratie-laag: bepaal wat vandaag moet gebeuren, voer de juiste stappen uit, rapporteer netjes terug. Maar de herhaalbare kern wil ik steeds vaker in code hebben. Code is saaier, maar dat is hier juist de bedoeling.

De verleiding van snel toevoegen

Wat me opviel: het is verslavend makkelijk om een skill uit te breiden.

Je bedenkt een nieuwe routine, schrijft er een paar regels bij en klaar. Geen abstrahering, geen module, geen tests, geen deploymentstrategie. Dat voelt in het begin als snelheid. Je bent niet aan het programmeren, je bent je werk aan het beschrijven.

Maar na een paar weken verandert die snelheid in een andere vorm van onderhoud. Je controleert of de agent de juiste map gebruikt. Je herhaalt dat stats via de SQLite-variant moeten lopen. Je ziet dat een deploy lokaal goed lijkt, maar live nog oude output toont. Je voegt een verificatiepass toe, daarna uitzonderingen op die verificatiepass, daarna een skip-conditie, daarna een fallback.

Op dat moment is de vraag niet meer: kan dit in een skill? De betere vraag is: hoort dit nog in een skill?

Die vraag stelde ik mezelf meerdere keren deze week. Bij podcaststatistieken wil ik geen creatieve interpretatie. Ik wil snapshots in de database, dashboarddata opnieuw genereren, bestanden syncen, deployen en controleren of de beschermde stats-pagina reageert zoals verwacht. Bij episodepagina’s wil ik geen globale instructie als “maak goede slugs”. Ik wil een slug-generator die getest kan worden.

Testen als tegenkracht

Daar paste ook het werk aan mutation testing bij. In een van de sessies werd het episode generator script onder mutmut gelegd. Niet alleen een paar helper-functies, maar ook RSS parsing, JSON-LD generatie en episode generatie. Dat klinkt technisch, maar voor mij zat de les ergens anders.

Mutation testing dwingt je om te bewijzen dat je tests echt iets zeggen. Niet alleen dat de code uitgevoerd wordt, maar dat fout gedrag ook opvalt. Dat is precies de tegenkracht die ik nodig heb bij agent-gegenereerde software.

Een agent kan snel code schrijven. Soms te snel. De verleiding is dan om te denken: het werkt, dus door. Mutation testing vertraagt dat bewust. Het stelt een ongemakkelijke vraag: als ik deze regel net verkeerd maak, merkt je test het dan?

Die vraag past goed bij mijn verschuiving van skills naar programma’s. Een skill kun je aanscherpen met tekst. Een programma kun je aanscherpen met tests. Beide zijn waardevol, maar ze lossen verschillende problemen op.

Website-debugging in de echte wereld

Een ander thema deze week was live websitegedrag. De AIToday Live website was verplaatst naar een andere projectstructuur, en daarna volgde een reeks fixes: oude paden opruimen, een Content Security Policy-probleem oplossen, externe assets vervangen door lokale bestanden en slug-generatie verbeteren.

Wat me daarin vooral bezighield was het verschil tussen lokaal gelijk hebben en live gelijk krijgen. Lokaal kan de HTML kloppen, terwijl de browser niets toont door een CSP-header, caching of een externe asset. Dan moet agentic development volwassen worden: niet alleen code genereren, maar ook productiegedrag controleren met curl, deployment-output en selectieve commits.

Wat het met mij deed

Het de-skillen voelde eerst als een stap terug. Alsof ik iets wat elegant was, weer ouderwets aan het maken was. Een Markdown skill heeft iets lichts. Een Python script met tests en foutafhandeling voelt zwaarder.

Maar gaandeweg merkte ik vooral opluchting.

Niet alles hoeft door een taalmodel bedacht te worden op het moment dat ik het uitvoer. Sommige dingen wil ik juist niet elke keer opnieuw laten interpreteren. Ik wil dat ze saai zijn. Betrouwbaar. Controleerbaar.

Dat inzicht maakt mijn experiment met AI-code niet kleiner. Het maakt het scherper. AI-agents zijn goed in verkennen, schrijven, analyseren en verbinden. Maar zodra een taak vaak terugkomt en weinig creativiteit vraagt, wil ik die taak steeds meer vastzetten in gewone software.

Misschien is dat de volwassen fase van werken met agents: niet alles agentic maken, maar beter kiezen wat agentic moet blijven.

Bijsturen

Mijn aansturing veranderde deze week subtiel. Ik vroeg minder vaak om “doe deze workflow” en vaker om “maak dit controleerbaar”. Bij scriptwerk vroeg ik om vloeiende tekst in plaats van bullet points, omdat het eindresultaat uitgesproken moet kunnen worden. Bij websitewerk vroeg ik om verificatie op productie, niet alleen lokale checks.

Dat zijn kleine verschillen in opdrachtformulering, maar ze sturen het werk anders. Een agent die alleen de taak uitvoert, komt snel tot een resultaat. Een agent die moet verifieren, moet bewijzen dat het resultaat klopt.

En dat is precies waar ik naartoe wil. Minder magie. Meer bewijs.

Het patroon

De rode draad van deze week is niet dat skills slecht zijn. Integendeel: zonder skills had ik veel minder snel zo’n rijke workflow kunnen opbouwen. Ze waren de perfecte manier om intentie vast te leggen en routines te laten ontstaan.

Maar routines die blijven, verdienen op een gegeven moment een stevigere vorm.

Eerst beschrijf je wat je wilt. Dan ontdek je welke stappen steeds terugkomen. Daarna programmeer je die stappen uit, test je ze, en laat je de agent erbovenop orchestreren. Dat voelt als een logisch groeipad: van intentie naar routine, van routine naar betrouwbare samenwerking.

Deze week ging dus niet over minder met AI doen. Het ging over beter kiezen waar AI in de keten hoort.