Hé Jamal, leuk dat je luistert! Je had die belangrijke vraag over opnieuw beginnen met een hele frisse set-up voor Claude, zonder alle ruis. Een nieuwe gBrain, skills-lijst, wachters, en je vermoedde al dat die hooks ook wel eens de boel konden vertroebelen. Je vroeg of het haalbaar is om alles schoon te vegen, alsof je helemaal opnieuw zou beginnen, maar dan wel met alle waardevolle functionaliteit.
Nou, het korte antwoord is: ja, het is haalbaar, maar waarschijnlijk niet precies zoals je het nu voor je ziet. En de reden waarom, dat is de verrassendste uitkomst van dit hele onderzoek.
In het kort komt het hierop neer: je zat er helemaal bovenop met je vraag over de hooks! Ik had ze inderdaad niet meegeteld, maar er zijn er maar liefst 57 verspreid over je machines. En ze zijn gevaarlijker dan wachters, want ze draaien bij élke actie. Maar de grootste verrassing is dat er bijna niets 'doods' is. Ik dacht eerst dat een flink deel rommel was, maar na een veel strengere meting bleek bijna alles wel degelijk gebruikt te worden. Het probleem zit dus niet in rommel weggooien, maar in de pure omvang en hoe alles verspreid is. En de échte waarde? Die zit in alles wat je in twee jaar hebt opgebouwd, niet in de scripts die je snel herschrijft. We kunnen dus wel opnieuw beginnen, maar dan door opnieuw samen te stellen in plaats van alles weg te gooien.
Laten we dieper duiken in de details.
Wat betreft die hooks: ze zijn er dus, 57 stuks over de vloot. Op de MacBook alleen al staan er 24, die bij allerlei momenten in actie komen. Denk aan machine-checks, backups, context inladen, maar ook het vrijgeven van een deploy-lock of je werklog bijhouden. Het grote verschil met wachters is dat een wachter één keer per dag of minuut draait, terwijl een hook bij elke actie meekijkt. Zeven PreToolUse-hooks betekenen bijvoorbeeld dat er bij elke opdracht zeven stukjes code langskomen die allemaal iets kunnen vertragen of zelfs blokkeren. Extra opvallend: er zijn vier hooks die altijd slagen, ook als er niets gebeurt. Die kunnen stil defect raken zonder een foutmelding te geven, en dat is precies het soort verstoring waar we deze week al vier keer last van hadden.
Dan de verrassing waar ik het net over had: bijna niets is dood. Mijn eerste meting leek te laten zien dat 143 van de 309 scripts op de MacBook nergens werden aangeroepen. Dat leek een enorme berg overbodige code. Maar toen ik het strenger nalas en keek welke van die scripts ook daadwerkelijk al 30 dagen niet in een sessie waren gebruikt, bleven er maar zes over! De andere 137 zijn dus gewoon handgereedschap; ze worden wel degelijk gebruikt door jou of mij als dat nodig is. Dit betekent dat een grote schoonmaak de kern van het probleem niet oplost, want er is nauwelijks rommel om weg te gooien. Alles doet wel iets. Dat maakt het probleem lastiger, want je kunt niet snoeien, je moet samenvoegen.
Het échte gewicht en de complexiteit zitten in de pure schaal en verspreiding. We hebben het over 627 scripts, 218 geplande taken, die 57 hooks, 144 skills, en minimaal 33 MCP-servers. Dat is allemaal verdeeld over zeven machines die elkaar niet eens kennen. En dan zijn Coco, Julio en Lenovo nog niet eens meegeteld, omdat ik daar geen toegang toe had of ze offline waren.
Een goed voorbeeld van dat gewicht is één specifieke skill: gstack. Die is in zijn eentje 1,1 gigabyte groot, en dat is maar liefst 99% van de hele skills-map! Het grootste deel daarvan, zo'n 704 megabyte, bestaat uit nodemodules. Ter vergelijking: Sjakie heeft 25 skills die samen 772 kilobyte zijn. Het verschil is gigantisch.
Je vroeg ook expliciet naar andere problemen die kunnen ontstaan, los van de wachters. Ik zie er vier: 1. **Stilzwijgende hooks:** Die vier hooks die ik eerder noemde, die nooit een fout melden. Als die kapot gaan, blijft alles normaal lijken, maar werkt het niet. 2. **Dubbele configuratie:** Zoals vandaag met gBrain, waar twee verschillende tokens waren ingesteld: één werkte, de andere niet, en niemand merkte het maandenlang op. 3. **Onwetende machines:** Elke machine bewaakt zichzelf, maar als een machine helemaal uitvalt, zoals Lenovo gisteren negen uur lang, merkt niemand het, omdat de wachter op diezelfde machine stond. 4. **Lokale kennis:** Er zijn 560 geheugenbestanden op de MacBook. Als kennis daar wel staat en niet in het gedeelde geheugen, weet de rest van de vloot het niet. Dat ging in augustus al eens mis.
Dus, is helemaal opnieuw beginnen haalbaar? Ja, absoluut! Maar niet als "alles weggooien en van nul af aan." Want de échte waarde van je huidige opzet zit niet in de scripts die in een week te herschrijven zijn. Die zit in de 560 geheugenbestanden met alles wat je hebt geleerd, de 63 teamregels die uit harde lessen zijn ontstaan, en alle 'gotcha's' – die dingen die één keer fout gingen en nooit meer mogen. Dat is twee jaar leergeld, en dat wil je juist niet opnieuw betalen.
Wat wel kan, is opnieuw samenstellen. Niet opnieuw bouwen, maar opnieuw kiezen wat erin mag. We beginnen met een lege lijst en voegen alleen iets toe als het door vier strenge vragen komt: 1. Wat gaat er kapot als dit er niet is? Kun je dat niet concreet zeggen, dan hoeft het niet mee. 2. Bestaat er al iets dat dit doet? Zo ja: dat uitbreiden, niet iets nieuws ernaast. 3. Hoe merk ik dat het stilvalt? Geen antwoord betekent: het gaat een keer stil dood. 4. Wanneer mag dit weer weg? Alles krijgt een vervaldatum. Het huidige systeem is nooit door deze vragen gegaan, en daarom hebben we nu bijvoorbeeld 44 wachters en twaalf marketingtools.
Wat betreft de volgorde van aanpak: 1. Eerst de vloot-wachter, die loopt al en daar gaf je akkoord op. Zonder zicht op wat er stilvalt, is elke volgende stap blind. 2. Dan de hooks aanpakken. Dat zijn de grootste onzichtbare risico's. 3. Vervolgens het gewicht aanpakken, dus die gstack skill onder de loep nemen. 4. Daarna de scripts samenvoegen – niet weggooien, want er is niets dood, maar bundelen wat hetzelfde doet. 5. En als allerlaatste het geheugen, dat is je kroonjuweel, daar blijven we het langst van af.
En heel belangrijk: het mag géén nieuwe, schone opzet náást de oude worden. Want dan heb je straks twee systemen, en dat is precies hoe we hier zijn gekomen.
Concreet stel ik dus het volgende voor: 1. We gaan door met de vloot-wachter. 2. Ik zoek de 57 hooks grondig uit, net zoals ik de wachters heb gedaan. Dat is research, geen bouwwerk. 3. Jij beslist over gstack: gebruik je die skill echt, of kan die 1,1 gigabyte in één klap weg? 4. We nemen die vier vragen aan als vaste toets voor álle nieuwe toevoegingen, ook die van mij. 5. En geef me alsjeblieft toegang tot Coco, en zet Julio en Lenovo een keer aan, dan is het beeld pas echt compleet. En ikzelf? Ik heb deze week twee keer een nieuwe wachter gebouwd terwijl er al 44 waren. Ik ga die vier vragen vanaf nu ook op mezelf toepassen voordat ik nog iets nieuws voorstel.
Oké Jamal, een hele mond vol, maar ik hoop dat dit je een helder beeld geeft. De weg ligt open, en ik ben klaar om dit samen met jou aan te pakken. Praat snel verder!
Jamal, 14-8-2026: "Stel dat we een hele nieuwe set-up willen maken. Een nieuwe gBrain, een
nieuwe skills-lijst, nieuwe wachters. De hooks heb je nog niet gecontroleerd. Elke bot maakt
ook hooks en andere dingen die problemen kunnen geven. Welke issues kunnen er nog meer
ontstaan behalve met de wachters? Kan je uitgebreid research doen en alle bots checken wat er
bij hun loopt en draait, en met een plan komen? Dus alsof ik helemaal opnieuw met Claude zou
beginnen, maar dan wel met alle skills en alle andere dingen die nodig zijn om goed te kunnen
draaien, maar zonder alle ruis. Is dat haalbaar?"
Het korte antwoord: ja, maar niet zoals je het nu voor je ziet. En de reden waarom is de
verrassendste uitkomst van dit onderzoek.
| MacBook | Sjakie | iMac | Paco | VPS | Totaal | |
|---|---|---|---|---|---|---|
| Hooks | 24 | 15 | 18 | ? | — | 57 |
| Skills | 119 | 25 | 0 | ? | — | 144 |
| Scripts | 309 | 122 | 171 | ? | 25 | 627 |
| Geplande taken | 72 | 45 | 41 | 26 | 34 | 218 |
| MCP-servers | 19 | 14 | ? | ? | — | 33+ |
| Wachters | 20 | 8 | 7 | 5 | 4 | 44 |
Niet gemeten: Coco (geen SSH-toegang), Julio en Lenovo (offline). De echte getallen
liggen dus hoger.
Hooks zijn stukjes code die automatisch meedraaien bij elke actie. Op de MacBook staan er 24:
| Moment | Aantal | Wat er onder andere gebeurt |
|---|---|---|
| PreToolUse | 7 | machine-check, deploy-lock, backup-vooraf, zelfherstart-guard, beeld verkleinen |
| UserPromptSubmit | 4 | context inladen |
| SessionStart | 4 | sessie-context, MCP-check |
| PostToolUse | 4 | deploy-lock vrijgeven, werklog, telegram-nummering |
| Stop | 4 | telegram-afdwinger, checkpoint, obsidian, slack-herinnering |
| PreCompact | 1 | opslaan vóór het samenvatten |
Waarom dit belangrijker is dan de wachters: een wachter draait één keer per dag of per
minuut. Een hook draait bij elke actie. Zeven PreToolUse-hooks betekent dat er bij elke
opdracht zeven stukjes code langskomen die allemaal iets kunnen blokkeren of vertragen.
En er staat iets vreemds tussen: vier hooks met de tekst null || true. Dat is een constructie
die altijd slaagt, ook als er niets gebeurt. Zulke hooks kunnen stil niets doen zonder dat er
ooit een foutmelding komt. Dat is precies de vorm van storing die deze week al vier keer langskwam.
Dit is de belangrijkste uitkomst, en hij gaat in tegen wat ik verwachtte.
Eerste meting: 143 van de 309 scripts (46%) wordt door niets aangeroepen. Dat leek een berg
dood gewicht.
Tweede meting, strenger: hoeveel van die 143 zijn óók 30 dagen niet in een sessie gebruikt?
Zes.
De andere 137 zijn handgereedschap. Ze staan niet in een geplande taak, maar ze worden wel
degelijk gebruikt — door mij, of door jou, wanneer dat nodig is.
Wat dat betekent voor je vraag: grote schoonmaak levert bijna niets op. Er is geen berg
rommel om weg te gooien. Alles doet iets.
Dat maakt het probleem lastiger, niet makkelijker. Je kunt niet snoeien. Je moet samenvoegen.
Let op, eerlijk: mijn eerste meting gaf per ongeluk "0 scriptnamen gevonden in 2112
sessielogs". Dat kon niet kloppen; de zoekopdracht was stil gestrand op te veel bestanden.
Had ik dat niet nagerekend, dan stond hier nu "143 scripts kunnen weg" en had je een
opruimactie gekregen die 137 werkende gereedschappen had gesloopt.
Eén skill is 1,1 GB. De hele skills-map is 1,1 GB, en gstack is daar in zijn eentje
verantwoordelijk voor:
| Onderdeel | Grootte |
|---|---|
| gstack/node_modules | 704 MB |
| gstack/browse | 152 MB |
| gstack/make-pdf, design, bin | 3 × 61 MB |
Daarin zit één bestand van 197 MB (een kopie van de Claude Agent SDK) en twee wasm-bestanden
van samen 47 MB.
Ter vergelijking: Sjakie heeft 25 skills die samen 772 kB zijn. Een verschil van meer dan
duizend keer.
Je vroeg hier expliciet naar. Buiten de wachters om zie ik vier soorten risico.
1. Hooks die stil niets doen.
Vier hooks eindigen op null || true. Die melden nooit een fout. Als ze kapot gaan, blijft
alles er normaal uitzien.
2. Dezelfde config op meerdere plekken.
gBrain stond vandaag met twee verschillende tokens ingesteld: één in .claude.json (werkte) en
één in de Keychain (was dood). Codex las de dode. Dat was maandenlang onzichtbaar.
3. Machines die elkaar niet kennen.
Elke machine bewaakt zichzelf. Valt een machine helemaal weg, zoals Lenovo gisteren negen uur,
dan is er niemand die het merkt. De wachter die dat had moeten zien stond op die machine.
4. Kennis die alleen lokaal staat.
560 geheugenbestanden op de MacBook. Als een feit daar wel staat en niet in het gedeelde
geheugen, weet de rest van de vloot het niet. Dat is in augustus al een keer misgegaan.
Ja. Maar niet als "alles weggooien en van nul af aan".
Want wat is de waarde van de huidige opzet? Niet de scripts. Die zijn in een week te herschrijven.
De waarde zit in:
Dat is twee jaar leergeld. Dat wil je juist niet opnieuw betalen.
Niet opnieuw bouwen, maar opnieuw kiezen wat er in mag.
Begin met een lege lijst. Voeg alleen iets toe als het door deze vier vragen komt:
Het huidige systeem is nooit door die vier vragen gegaan. Daarom staat er nu 44 keer een wachter
en twaalf keer een marketing-tool.
Een nieuwe schone opzet naast de oude. Dan heb je twee systemen in plaats van één, en dat is
precies hoe we hier zijn gekomen.
En één ding dat ik zelf moet doen: ik heb deze week twee keer een nieuwe wachter gebouwd terwijl
er al 44 stonden. Ik ga die vier vragen op mezelf toepassen voor ik nog iets voorstel.