Ha Jamal, welkom bij deze speciale aflevering! Je vroeg me om eens goed te kijken naar je geautomatiseerde systemen, alsof ik er als doorgewinterde senior developer met een berg ervaring in AI, code en automatisering op zou stappen. En dat is precies wat ik gedaan heb. Dit plan is gebaseerd op wat ik vandaag echt heb gemeten, niet op algemene adviezen.
Als een developer head ergens binnenkomt, is de eerste vraag nooit "hoe is het gebouwd?", maar "wat levert het op?". Ik heb alle 69 geplande taken op je MacBook geanalyseerd, en de conclusie is helder: bijna de helft van al het automatische werk is alleen maar bezig om het systeem zelf draaiende te houden. Een negende deel doet daadwerkelijk iets voor je salons, zoals blogs, mail, klantencontact of SEO. Dat is de kern van de zaak. Bij een gezond systeem is die verhouding precies omgekeerd. Dit is absoluut geen kritiek, het is de normale uitkomst van twee jaar organische groei zonder een moment terug te kijken. Een ervaren developer zou hier direct de technische vragen parkeren en dit eerst op tafel leggen.
De diagnose is eigenlijk simpel: je hebt geen slecht systeem, maar je hebt geen architectuur. Elk onderdeel is op zichzelf slim gebouwd, vaak als reactie op een storing. Maar er ontbreekt een fundamentele laag van afspraken over hoe dingen draaien, meten, melden en configureren. Zonder die architectuurlaag krijgt elk nieuw probleem zijn eigen, unieke oplossing. En dat zien we terug: vijf verschillende manieren om taken te laten draaien, 44 verschillende manieren om te controleren of iets werkt, en minstens vier plekken waar instellingen en sleutels staan opgeslagen. Het resultaat? Onzichtbare dubbelingen en veel zoekwerk. Sterker nog, er is geen enkele plek waar staat wat er allemaal draait, ik heb het handmatig over vijf machines moeten uitpluizen.
Wat een ervaren developer in deze situatie *niet* zou doen, is alles opnieuw bouwen. Dat is de duurste en meest voorkomende fout. Je gooit dan namelijk ook al die kleine correcties weg die na echte storingen zijn ingebouwd. Die staan niet in de documentatie, die zitten in de code. Ik dacht bijvoorbeeld dat 143 van je scripts dood waren, maar na beter meten bleken het er maar zes te zijn. Een herbouw had 137 werkende dingen gesloopt. Wat zo iemand wél doet, noemen we de 'wurgvijg'-aanpak: je bouwt een nieuwe, robuuste laag naast de oude, en laat het werk geleidelijk één voor één overlopen. Pas als alles veilig is overgezet, haal je het oude weg. Geen grote knal, maar een gecontroleerde transitie.
Het plan om dit aan te pakken bestaat uit vijf fases. **Fase 0: Zichtbaar maken.** Dit is grotendeels al af. Je kunt niets verbeteren als je het niet kunt zien, en er was geen manier om te controleren of je wachters nog draaiden. De vloot-wachter draait nu met controlelijsten, maar Coco, Julio en Lenovo moeten nog in beeld komen. Pas als je op één plek kunt zien wat er op alle zeven machines draait en of het nog leeft, is deze fase klaar.
**Fase 1: Eén fundament bouwen.** Hier bouwen we geen nieuwe functies, maar leggen we de architectuur neer in twee tot drie weken. Het draait om afspraken die afgedwongen worden door code. Dat betekent: één manier om taken te draaien, waarbij elke taak zijn actieve status doorgeeft; één manier om meldingen te versturen, zodat je één gebundeld bericht per dag krijgt in plaats van twintig losse; één centrale bron voor alle instellingen en sleutels, zoals de Keychain, om dubbelingen te voorkomen; en één zelfonderhoudend register van alles wat draait. Als deze fase klaar is, betekent een nieuwe taak toevoegen alleen nog het echte werk én één regel in het register, zonder eigen meldcode, instellingen of wachter.
**Fase 2: Overzetten.** Dit duurt vier tot zes weken en gebeurt op de achtergrond. We zetten elke taak stap voor stap over, vaak door ze tijdelijk dubbel te laten draaien. We beginnen met de negen meetwachters, daarna de rapporteurs, dan de vijf herstarters (deze zijn kritisch, dus met extra zorg) en tot slot de 57 hooks. Die hooks vormen nu een groot, onzichtbaar risico. Deze fase is klaar als de oude versie een week uit heeft gestaan zonder dat iemand iets gemist heeft.
**Fase 3: Opruimen.** Pas nu, en niet eerder, gaan we opruimen. Eerder is gokken. Denk aan de zes echt dode scripts, de 68 backupbestanden en die enorme 1,1 GB aan gstack-skill – als je die niet gebruikt, is dat een enorme winst. Ook gaan we dubbelingen samenvoegen, zoals de noodstop-wachter die nu drie keer bestaat.
**Fase 4: Zorgen dat het niet terugkomt.** Dit is voor een developer head het allerbelangrijkste, maar wordt vaak overgeslagen. Elk nieuw ding moet langs vier vragen: Wat gaat er kapot als dit er niet is? Bestaat er al iets dat dit doet? Hoe merk ik dat het stilvalt? En wanneer mag het weer weg? Pas als je op alle vier de vragen een goed antwoord hebt, mag je het bouwen. Deze toets had eerder 44 wachters en twaalf marketingtools kunnen voorkomen.
Als senior developer zou ik je ook vier onveranderlijke regels opleggen: 1. **Eén ding doet één ding, en er is er maar één van.** Twee Suno-wachters zijn geen extra zekerheid, maar twee keer half onderhoud. 2. **Elk automatisch ding meldt dat het geleefd heeft.** Stilte moet verdacht zijn, niet geruststellend. Je wilt weten dat iets *draait*, niet alleen dat er niets mis *is*. 3. **Instellingen staan op één plek, code op een andere.** Wat gecontroleerd wordt hoort in een lijst, hoe er gecontroleerd wordt in code. Dit bespaart veel tijd. 4. **Alles heeft een vervaldatum.** Niet om het weg te gooien, maar om het jaarlijks bewust tegen het licht te houden en te controleren of het nog nut heeft.
En dan is er de onaangename, maar cruciale vraag, die elke developer head met dertig jaar ervaring zou stellen: **Je bent kapper, geen softwarebedrijf.** Elke regel code die je erbij krijgt, is een verplichting die nooit meer afgaat. 627 scripts zijn 627 dingen die kapot kunnen. Dat is te veel voor twee salons. De vraag bij elk nieuw voorstel, ook van mij, is niet "kan dit?". Het antwoord daarop is bijna altijd ja. De vraag is: hoeveel knippen levert dit op, en wat kost het aan onderhoud? Bij 47% van je automatische werk is het antwoord op de eerste helft: niets. Dat werk bestaat alleen omdat er ander werk is. Dat is niet erg zolang je het weet, maar het wordt gevaarlijk als het onzichtbaar is.
Mijn voorstel is dan ook: 1. **Fase 0 afmaken:** we brengen Coco, Julio en Lenovo in beeld. Daarvoor heb ik toegang nodig. 2. **Fase 1 bouwen:** het fundament. Dit kost twee tot drie weken, levert op zichzelf niets direct zichtbaars op, maar is de cruciale investering voor alles wat volgt. 3. **Beslis over gstack:** 1,1 GB is gigantisch. Gebruik je hem nog? Zo niet, dan kan die weg. 4. **Neem de vier vragen aan als vaste toets:** voor elk nieuw project, ook van mij, vooral van mij. 5. **Kies één ding dat de salon direct dient om parallel af te maken:** zodat deze hele operatie niet alleen over zichzelf gaat. Mijn voorstel is de blogketen, die ligt sinds 13 juni stil en alles staat al klaar.
Dat laatste punt is precies de kern van dit hele verhaal, Jamal. Een systeem dat alleen zichzelf onderhoudt, is geen systeem meer, maar een hobby. Ik hoor graag wat je ervan vindt. Tot snel!
Jamal, 14-8-2026: "Stap in de rol van een senior developer met extreem veel ervaring op het
gebied van AI, code en automatisering, en kom terug met een plan zoals een developer head
het zou aanpakken."Dit is dat plan. Gebaseerd op wat er vandaag echt is gemeten, niet op algemene adviezen.
Niet "hoe is het gebouwd". Maar: wat levert het op?
Ik heb alle 69 geplande taken op de MacBook ingedeeld:
| Soort werk | Aantal | Aandeel |
|---|---|---|
| Dient de salon direct (blogs, mail, klanten, social, SEO) | 8 | 11% |
| Houdt het systeem zelf draaiend (wachters, backups, tokens, geheugen) | 33 | 47% |
| Overig of onduidelijk | 28 | 42% |
Bijna de helft van al het automatische werk bestaat om het systeem zelf overeind te houden.
Een negende deel doet iets voor de zaak.
Dat is de kern. Bij een gezond systeem is die verhouding omgekeerd. Dit is geen kritiek op wat
er gebouwd is, het is de normale uitkomst van twee jaar organisch groeien zonder één keer
terugkijken.
Een developer head zou hier stoppen met alle technische vragen en eerst dit op tafel leggen.
Je hebt geen slecht systeem. Je hebt geen architectuur.
Dat is iets anders. Elk onderdeel is op zichzelf verstandig gebouwd, met goede redenen, vaak na
een echte storing. Maar niemand heeft ooit de laag eronder gelegd: afspraken over hoe dingen
draaien, meten, melden en configureren.
Zonder die laag krijgt elk nieuw probleem zijn eigen oplossing. Dat is precies wat er gebeurd is:
.claude.json, de Keychain,.env-bestanden en de plists zelf. Dat leverde gisteren nog een gBrain-token op die opAlles opnieuw bouwen.
Dat is de klassieke fout, en de duurste. Bij een herbouw gooi je ook alles weg wat wél werkt,
inclusief de tientallen kleine correcties die er na echte fouten in zijn geslopen. Die zitten
niet in de documentatie. Die zitten in de code.
Concreet voorbeeld van vandaag: ik dacht dat 143 van je 309 scripts dood waren. Na beter meten
bleken er zes echt dood. De rest is gereedschap dat gebruikt wordt. Een herbouw had 137
werkende dingen gesloopt.
Wat zo iemand wel doet heet de wurgvijg: je zet een nieuwe laag naast de oude, laat werk
één voor één overlopen, en pas als alles over is haal je het oude weg. Nooit een grote knal.
Je kunt niet verbeteren wat je niet kunt zien. Dit was de blinde vlek: er was geen enkele manier
om te zien of een van de 44 wachters was weggevallen.
Vandaag gedaan: de vloot-wachter draait, met de controles in een lijst in plaats van in code.
Nog te doen: Coco, Julio en Lenovo meenemen. Zolang die buiten beeld blijven, is elk cijfer een
schatting.
Klaar als: je op één plek kunt zien wat er op alle zeven machines draait en of het nog leeft.
Niet nieuwe functies. Alleen afspraken, met code die ze afdwingt. Vier stukken:
1. Eén manier om een taak te draaien.
Nu vijf mechanismen. Er blijft er één per machinesoort, met dezelfde vorm: elke taak schrijft
bij elke run een stempel weg, logt op dezelfde plek, en heeft een eigenaar en een vervaldatum.
Dat stempelen lost meteen de fout op die ik vandaag zelf maakte: ik las een oud logbestand als
stilstand, terwijl die scripts alleen loggen als er iets mis is. Met een stempel bij elke run
is ouderdom wél een geldige maat.
2. Eén manier om te melden.
Nu roept elk script zelf Jamal aan. Straks meldt alles aan één plek, en die bundelt. Eén bericht
per dag in plaats van twintig losse.
3. Eén bron voor instellingen en sleutels.
De Keychain wordt de enige plek voor geheimen. Alles wat ze nu ergens anders heeft staan, gaat
daarheen. Dubbele waarden zijn dan onmogelijk in plaats van moeilijk te vinden.
4. Eén register van wat er draait.
Een lijst die zichzelf bijhoudt: elke taak, op welke machine, wat hij doet, wie hem gemaakt
heeft, wanneer hij mag vervallen. Staat iets niet in het register, dan hoort het er niet.
Klaar als: een nieuwe taak toevoegen betekent één regel in het register plus het echte werk.
Geen eigen meldcode, geen eigen instellingen, geen eigen wachter.
Per taak, in kleine stappen, met dubbeldraaien. Volgorde op risico:
Klaar als: de oude versie een week uit heeft gestaan zonder dat iemand iets miste.
Pas nu, en niet eerder. Opruimen vóór je zicht hebt is gokken.
gstack-skill: dat is 99% van je hele skills-map, met 704 MB aan bibliotheken.Dit is het deel dat een developer head het belangrijkst vindt, en dat meestal wordt overgeslagen.
Elk nieuw ding moet langs vier vragen:
Geen antwoord op één van de vier betekent: niet bouwen.
Was die toets er geweest, dan waren er nooit 44 wachters gekomen, en ook geen twaalf
marketing-tools. Ik heb hem gisteren en vandaag zelf twee keer overgeslagen.
1. Eén ding doet één ding, en er is er maar één van.
Twee Suno-wachters op één machine is geen extra zekerheid, het is twee keer half onderhouden.
2. Elk automatisch ding meldt dat het geleefd heeft.
Niet alleen dat er iets mis is. Ook dat het gedraaid heeft. Stilte moet verdacht zijn, niet
geruststellend.
3. Instellingen staan op één plek, code op een andere.
Wat er gecontroleerd wordt hoort in een lijst. Hoe er gecontroleerd wordt hoort in code. Dat
scheelt bij elke wijziging een programmeur.
4. Alles heeft een vervaldatum.
Niet om het weg te gooien, maar om het één keer per jaar tegen het licht te houden.
Een developer head met dertig jaar ervaring zou dit ook zeggen, en het is de belangrijkste zin
van dit verslag:
Je bent kapper, geen softwarebedrijf.
Elke regel code die je erbij krijgt, is een verplichting die er nooit meer afgaat. 627 scripts
zijn 627 dingen die kapot kunnen. Dat is te veel voor twee salons.
De vraag bij elk volgend voorstel, ook van mij, is niet "kan dit". Het antwoord daarop is bijna
altijd ja. De vraag is: hoeveel knippen levert dit op, en wat kost het aan onderhoud?
Bij 47% van je automatische werk is het antwoord op de eerste helft: niets. Dat werk bestaat
alleen omdat er ander werk is.
Dat is niet erg zolang je het weet. Het wordt erg zodra het onzichtbaar is.
Dat laatste punt is precies het punt van dit hele verslag. Een systeem dat alleen zichzelf
onderhoudt, is geen systeem meer maar een hobby.