Hey Jamal, je vroeg je af hoe het komt dat je de laatste tijd alleen maar problemen lijkt op te lossen. Je zei: "Dit had ik nog nooit, maar sinds gBrain gaat alles mis." Ik begrijp die frustratie, en ik ben erin gedoken met cijfers, geen onderbuikgevoel, en heb de oorzaak gevonden.
De korte conclusie: het ligt níet aan gBrain. De storingen begonnen al ruim een maand eerder. De echte oorzaak is dat onze vloot sneller groeide dan de afspraken over waar de 'waarheid' staat. Elke nieuwe bot kreeg zijn eigen kopie van het geheugen en taakborden, die langzaam uiteenliepen. Je merkt het pas als iemand uit zo'n oude kopie gaat werken. Dit is trouwens een bekend probleem in de hele sector.
De cijfers bewijzen het. De storingen volgen duidelijk het aantal bots, niet gBrain. Tussen mei en juli ging de vloot van 5 naar 13 bots, terwijl de storingen van vrijwel geen naar 41 per maand stegen. De piek was in juli; gBrain was pas 30 juli afgerond – dus ná die piek. Even een correctie op mezelf: ik telde aanvankelijk te veel bots, maar de conclusie blijft staan: groei en storingen correleren sterk.
De echte trigger? 19 juni. Toen verhuisde de Obsidian-kluis van iCloud naar de MacBook. Vanaf dat moment lazen alle andere machines een bevroren, maar nog steeds leesbare, kopie. Ik kwam vanavond bijvoorbeeld tegen dat Sjakie's taakbord al sinds 13 juni niet meer was bijgewerkt – zes dagen vóór die verhuizing! Hij las het nog steeds voor alsof het actueel was, met taken die letterlijk "hangt sinds april" zeiden. Paco’s taakbord kwam uit een dode iCloud-map van 2 juni, en zelfs mijn eigen taakbord had drie verschillende versies. Overal bevroren lijsten, allemaal rond diezelfde verhuizing.
Waarom je het niet zag? Geen foutmeldingen! Een oud bestand opent net zo makkelijk als een nieuw. Bij Sjakie liet `stat` zelfs 2 augustus zien – vers, leek het. Maar de inhoud was van 13 juni. De datum van het bestand en de datum van de inhoud waren dus twee verschillende dingen, en ik keek naar de verkeerde.
Dit overkomt niet alleen jou. Ik heb gezocht, en dit is een bekend probleem in de branche. Ontwikkelaars hebben het over 'drift tussen contextbestanden' en 'confetti in de root directory'. Het treffendste citaat: "Er is een faalmodus die verraderlijker is dan helemaal geen contextbestanden: contextbestanden hebben die zes maanden geleden accuraat waren." De hele sector beweegt dan ook naar één gedeeld bestand voor deze informatie, niet langer een kopie per bot.
Wat ik vanavond heb gerepareerd: Mijn drie taakborden heb ik samengevoegd tot één, met snelkoppelingen. Mijn eigen `/start` toont nu de datum van het bord en waarschuwt als het ouder is dan twee dagen. Sjakie’s `/start` leest nu het echte bord en waarschuwt als de inhoud ouder is dan een week; zijn zelftest gaf "60 DAGEN OUD" aan. Hetzelfde probleem vond ik bij Paco. Coco en Lenovo hadden dit gelukkig niet.
Wat er nog moet: We moeten Sjakie's 26 taken nalopen – daar is jouw oordeel essentieel voor. Paco's taakbord moet naar de levende bron wijzen. En structureel gezien: één bron per soort informatie, niet een kopie per machine. Dat is de weg waar de hele industrie naartoe beweegt.
Over die MCP-vraag: Je idee om koppelingen pas aan te zetten als je ze nodig hebt, is helemaal goed, Jamal! Op de MacBook zag ik 19 ingestelde koppelingen en maar liefst 72 processen met 'mcp' in de naam. Veel voor iets dat je meestal niet gebruikt. Tools worden al op verzoek geladen, maar de servers starten nog allemaal tegelijk. Dat kan slanker, scheelt geheugen én opstarttijd. Goede observatie!
De les in één zin: Onze vloot groeide van 5 naar 13 bots zonder dat er één afspraak bijkwam over waar de waarheid staat. Niet gBrain was de oorzaak, maar het ontbreken van één centrale bron – en het verraderlijke feit dat oude informatie er precies zo uitziet als nieuwe.
Ik hoop dat dit meer helderheid geeft, Jamal. De volgende stappen zijn duidelijk. Laten we dit samen aanpakken!
Jamal vroeg: "Hoe komt het dat ik alleen maar problemen aan het oplossen ben? Dit probleem
heb ik nooit gehad. Maar sinds kort, sinds we met gBrain werken, gaat alles mis."
Ik heb het uitgezocht met cijfers in plaats van een gevoel. Hier is wat eruit komt.
Het ligt niet aan gBrain. De storingen begonnen ruim een maand eerder.
De echte oorzaak is dat de vloot sneller groeide dan de afspraken over waar dingen staan.
Elke nieuwe bot kreeg zijn eigen kopie van het geheugen, het taakbord en de instellingen.
Niemand hield die kopieën gelijk. Ze liepen uit elkaar, en dat merk je pas als iemand
werk uit een oude kopie voorleest.
Dit is geen fout van één bot. Het is een bekend probleem in de hele branche, met een naam.
| Maand | Berichten tussen bots | Echte bots | Vastgelegde storingen |
|---|---|---|---|
| mei | 275 | 5 | vrijwel geen |
| juni | 1.578 | 11 | 6 |
| juli | 3.441 | 13 | 41 |
| augustus (12 dagen) | 1.508 | 10 | 29 |
De piek ligt in juli. gBrain is pas op 30 juli afgerond — ná de piek.
Van mei tot juli ging de vloot van 5 naar 13 bots. In diezelfde periode gingen de storingen
van bijna niets naar 41 per maand. Dát is de lijn die samenloopt.
Correctie op mezelf (12-8, na Jamals vraag). In mijn eerste versie stond hier 8 → 27
bots. Dat klopte niet: ik telde het aantal verschillende namen in de wachtrij, en daar
zitten testnamen (remtest,fixtest,testbot…), logkanalen (paco-log,julio-log),
relays en geplande taken tussen. Geen bots. Jamal herkende het getal niet en had gelijk.
Van de 35 namen in de wachtrij zijn er 9 een werkende bot: Conductor, Paco, Sjakie,
Kimi, Jarvis, Lenovo, Appel, Coco en Julio. Zes zijn gestopt (Mind, SEO, Hermes, Bel-AI,
Camil, Jay), de rest is geen bot. De conclusie verandert niet — de groei en de storingen
lopen nog steeds samen op — maar het getal was ruim twee keer te hoog.
Op 19 juni is de Obsidian-kluis verhuisd van iCloud naar de MacBook zelf. Vanaf dat moment
las elke andere machine een kopie die niet meer werd bijgewerkt. Bevroren, maar niet stuk —
en dus onzichtbaar.
Kijk naar wat ik vanavond aantrof:
Drie machines, drie bevroren lijsten, allemaal rond dezelfde verhuizing.
Geen van deze storingen geeft een foutmelding. Een oud bestand opent net zo makkelijk als een
nieuw bestand. stat liet bij Sjakie zelfs 2 augustus zien — vers, leek het. Maar de inhoud
was van 13 juni. De datum van het bestand en de datum van de inhoud waren twee verschillende
dingen, en ik keek naar de verkeerde.
Ik heb gezocht wat andere ontwikkelaars hierover schrijven. Het is een bekend en benoemd
probleem, met dezelfde oorzaak:
"Drift between context files is one of the most common causes of agents behaving
differently for different teammates on the same repo.""Open a typical project that's been through a few months of AI-assisted development. You'll
find some combination of CLAUDE.md, .cursorrules, copilot-instructions.md, AGENTS.md...
Almost the same content in each one. Slowly drifting apart."
Eén ontwikkelaar noemt het "confetti in the root directory". Een ander loste het op met
symlinks — precies wat ik vanmiddag bij mijn eigen taakborden heb gedaan.
En het scherpste citaat, dat exact beschrijft wat hier gebeurde:
"There is a failure mode more insidious than having no context files at all: having context
files that were accurate six months ago."
De branche beweegt naar één gedeeld bestand (AGENTS.md) in plaats van een kopie per bot.
| Wat | Hoe |
|---|---|
| Mijn drie taakborden | Samengevoegd tot één bestand; de andere twee zijn nu snelkoppelingen. Drie identieke controlegetallen als bewijs. |
Mijn /start |
Toont nu de datum van het bord en waarschuwt boven de 2 dagen. |
Sjakies /start |
Las een leeg bestand van 21 april. Leest nu het echte bord, met waarschuwing zodra de inhoud ouder is dan een week. Zelftest gaf: "60 DAGEN OUD". |
| Paco | Zelfde probleem gevonden (2 juni, dode iCloud-map). |
| Coco en Lenovo | Gecontroleerd, hebben dit probleem niet. |
Jamal vroeg of het niet slimmer is om koppelingen pas aan te zetten als je ze nodig hebt.
Dat is geen rare gedachte, dat is precies goed. Gemeten op de MacBook: 19 ingestelde
koppelingen, en 72 processen met "mcp" in de naam. Dat is veel voor iets dat je meestal
niet gebruikt.
Een deel gebeurt trouwens al: het gereedschap wordt tegenwoordig pas op verzoek geladen in
plaats van allemaal vooraf. Maar de servers zelf starten nog wel allemaal op. Dat kan
slanker, en het scheelt geheugen én opstarttijd.
De vloot groeide van 5 naar 13 bots zonder dat er één afspraak bij kwam over waar de waarheid
staat. Niet gBrain was de oorzaak, maar het ontbreken van één bron — en het feit dat oude
informatie er precies zo uitziet als nieuwe.