Week W26 · 22-28 juni 2026
Build AI. Run AI. Own AI.
Ik bouw dit niet in een lab, maar middenin mijn eigen leven als zzp'er en vader — en toch ontwerp ik elke keuze alsof er een enterprise-klant op leunt: multi-tenant vanaf dag 1, secrets die nooit een mens ziet, migraties die nooit terug kunnen. Dit is het logboek van die combinatie: zelf bouwen, zelf draaiend houden, zelf eigenaar blijven — inclusief de aanname, de misser en de prijs van elke keuze.
Met meerdere checkouts en afzonderlijke agent-omgevingen wordt Git-coördinatie ineens dagelijks werk. Welke checkout is bijgewerkt? Op welke branch zit die? Is een wijziging al gecommit, of staat ze nog lokaal in een andere map? Als ik dat steeds uit mijn hoofd moet reconstrueren, verdampt de tijdwinst van parallel werken razendsnel.
Het probleem dat opdook
De agents leveren sneller wijzigingen op dan ik ze rustig kan integreren. Het knelpunt verschuift van code schrijven naar overdracht, sync en review: wie werkt waaraan, welke branch hoort bij welk experiment, en hoe voorkom ik dat twee agents elkaars werk doorkruisen voordat het op `main` landt? Zonder vaste afspraken loop je voortdurend achter branchconflicten en zwevende commits aan.
De makkelijke weg die ik had kunnen nemen
Ik had kunnen vertrouwen op losse geheugensteuntjes en handmatige `git checkout`- en `git merge`-commando's per werkplek. Zolang alles goed gaat lijkt dat snel genoeg — tot het moment dat een branch half gemerged blijft hangen of een agent op een verouderde commit verder bouwt.
De keuze die ik maakte en de strategie erachter
In plaats daarvan scherp ik het Git-protocol en de tooling eromheen aan. Scripts zoals `pa.sh` krijgen vaste stappen voor synchronisatie met `main`, het veiligstellen van onderhanden werk en het netjes afronden van feature-branches. Automatisering neemt niet de reviewbeslissing over — ik moet nog steeds zelf zien wat er verandert —, maar haalt wel de routine en de vergeetachtigheid uit het proces.
Wat het kostte
Het vraagt discipline om je aan een protocol te houden als je even snel iets wilt uitproberen. En hulpscripts bouwen kost tijd die op dat moment niet naar productfeatures gaat. Bovendien lost een strakker Git-ritme de onderliggende repository-complexiteit met submodules nog niet op; het maakt vooral scherper zichtbaar waar die constructie schuurt.
Wat het nu oplevert en wat ik ervan leerde
Meer parallelle capaciteit heeft pas zin als de overdracht voorspelbaar is. Door het synchroniseren en afronden van branches te formaliseren, hoef ik niet meer te raden waar werk is gebleven en kan ik sneller ingrijpen wanneer twee ontwikkelpaden elkaar raken. Het fundament staat klaar voor de volgende stap: de repositorystructuur zelf grondig herzien.