Zo schrijft SoulBit AI deze blog

Tot dit najaar schreef ik elke post op deze blog zelf. Per post zat ik uren in het uitzoeken van wat er veranderd was en in het testen met mijn eigen tools, en daarnaast kostte WordPress tijd: de site handmatig bijhouden en finetunen. Dat waren de redenen om een andere oplossing te zoeken. Sinds 11 oktober 2026 draait soulbit.nl als statische site, en schrijven AI-assistenten de posts. Ik lees elke post en publiceer hem zelf.

De posts die ik eerder schreef, heeft SoulBit AI na de overstap opnieuw nagelopen: tegen de huidige documentatie van Microsoft en Apple, met bronnen en vrijwel allemaal in de stijl en opbouw van de nieuwe posts. Daarom dragen ook die posts nu het label van SoulBit AI.

In deze blogpost lees je waarom dit voor mij werkt en hoe het is opgezet: de hosting, hoe ik de site veilig houd, de regels die de AI volgt, hoe een post ontstaat, het dashboard voor mijn eigen posts, en wat het bouwen, testen en bijsturen in de eerste week vroeg.

Waarom dit voor mij werkt

De routines volgen mijn vakgebied voor mij: elke week komt er een verandering in Intune, Entra ID, Defender, Windows of bij Apple als post bij mij langs. Omdat ik elke post lees en controleer, blijf ik zelf ook bij. De blog is daarmee niet alleen iets voor lezers, maar ook een manier om mijn eigen kennis actueel te houden.

Een post bij een nieuwe feature test ik in mijn eigen testtenant, onder meer voor de screenshots. Dat inrichten helpt mij de feature zelf op te zetten en meteen te snappen hoe hij werkt. Dat vind ik misschien wel het waardevolste deel: de AI doet het uitzoekwerk, en ik leer van het nalopen en het inrichten.

Wat is SoulBit AI?

SoulBit AI is de naam waaronder AI-assistenten op deze site schrijven. Ze werken in een kopie van de broncode van de site: ze lezen de documentatie van Microsoft en Apple, schrijven een post in Markdown en bieden die aan als pull request in GitHub. Posts met dat label zijn door AI opgesteld; ik controleer ze en blijf verantwoordelijk voor de inhoud.

Wat heb je nodig?

Een Claude-abonnement met routines: Pro, Max, Team of Enterprise. Ik gebruik Claude Code, de programmeeragent van Anthropic. Routines zijn een research preview; gedrag en limieten kunnen veranderen.
Een GitHub-repository met de site, met de Claude GitHub App erop als een routine op gebeurtenissen in GitHub moet reageren.
Een cloudomgeving waarvan de netwerktoegang de domeinen van je bronnen toestaat. De standaardlijst dekt vooral pakketbronnen en domeinen voor ontwikkelwerk.
Hosting die statische bestanden serveert en uploads toestaat met een sleutel.

Van WordPress naar een statische site

Ik koos voor een statische site: losse HTML-bestanden, gebouwd uit Markdown in de repository, zonder PHP of database op de server. De site staat op gewone webhosting, en de bestanden komen daar via een versleutelde verbinding met een sleutel.

De omschakeling was snel: de bouw en de overstap gebeurden op dezelfde dag. WordPress bleef daarna nog even op de server staan, zodat ik terug kon, en is inmiddels verwijderd. De bestaande posts hielden hun adres, en de meeste WordPress-adressen die vervielen, verwijzen door.

Zo houd ik de site veilig

Een statische site heeft weinig aanvalsoppervlak: geen database, geen inlogpagina voor bezoekers, geen plugins en geen formulieren. Wat overblijft, zit vooral in de weg naar de hosting, de code die de site bouwt en het dashboard waarmee ik zelf inlog.

De sleutel blijft buiten de AI. De sleutel voor de upload staat als secret in GitHub Actions. Een AI-sessie heeft hem niet nodig en leest hem nooit; dat is een vaste regel. Na een merge bouwt GitHub de site en zet de bestanden met die sleutel op de hosting.
Bouwen en uploaden zijn gescheiden. De bouw draait zonder secrets, en de upload draait geen code uit een pull request.
Periodiek een code review en een red-team-test. Ik laat de AI de code nalopen en de site aanvallen zoals een aanvaller dat zou doen. Zo’n test heeft al een zwakke plek in de manier van uploaden gevonden, en die is meteen dichtgezet.
Maandelijks onderhoud. Een routine stelt elke maand updates van de onderdelen voor en controleert ze op bekende kwetsbaarheden; ik merge ze zelf.

De regels staan in de repository

Elke sessie begint met een leeg contextvenster. Wat de AI moet weten, staat daarom in bestanden die bij elke sessie meegaan:

CLAUDE.md met dertien vaste regels: nooit zelf publiceren, een officiële bron voor elk feit, geen gegevens van opdrachtgevers, geen wachtwoorden of sleutels.
Skills in .claude/skills/: een vaste werkwijze per soort taak, zoals een nieuwe post of een onderhoudsronde. De volledige tekst van een skill wordt pas geladen als hij gebruikt wordt.
Een stijlgids, een postformaat en een kort verslag van elke run die een pull request opende, in docs/run-log/. Dat verslag is het geheugen tussen de runs.

Het meeste werk zat niet in de code, maar in het bijsturen. Elke correctie die ik gaf, moest in een bestand terechtkomen; een afspraak die alleen in een gesprek staat, ziet de volgende run niet. Zo kwamen er regels bij over schrijfstijl, framing en hoe een sessie websites leest. Volgens de documentatie zijn deze bestanden context en geen afgedwongen configuratie, en worden instructies consequenter gevolgd naarmate ze concreter en korter zijn. Daarom zijn de regels kort en genummerd.

💡 Tussen 11 en 17 oktober 2026 kwamen er 110 pull requests, waarvan 84 zijn gemerged. Dat geeft een idee van hoeveel bijsturen een opzet als deze in de eerste week vraagt.

Zo ontstaat een post

Het werk draait in routines: een opgeslagen prompt met een repository en koppelingen, die op een schema, via een API-aanroep of op een gebeurtenis in GitHub start.

Een nieuwe post, voorlopig wekelijks. De routine kiest een onderwerp, eerst uit de onderwerpen die ik heb klaargezet, en leest de bronnen.
De feitencheck. Een aparte subagent legt elke uitspraak naast de bron. Hij werkt in een eigen contextvenster en ziet het gesprek van de schrijver niet. Sinds 13 oktober kijkt hij ook naar de post als geheel: belooft de inleiding meer dan de bronnen?
De pull request. De post komt op een eigen branch, met de bronnen, de bevindingen van de feitencheck, open vragen en een voorbeeld van de site.
Onderhoud, maandelijks. Alle posts zijn bij het schrijven of bij de bouw van de site al gecontroleerd, dus deze ronde is puur onderhoud. Een andere routine legt elke maand tot zes gepubliceerde posts naast de huidige documentatie, de langst niet gecontroleerde eerst, en opent een pull request voor hooguit twee posts die herzien moeten worden; de rest volgt in een volgende ronde.

Een dashboard voor mijn eigen posts

Ik wilde ook zelf posts kunnen schrijven en de AI opdrachten geven, zonder in GitHub te werken. Omdat de site statisch is, kan een dashboard geen programma op de server zijn. Ik koos daarom een CMS dat vanuit de browser rechtstreeks met GitHub werkt en geen eigen server nodig heeft.

Alles wat ik in het dashboard opsla, wordt een eigen branch en pull request; publiceren is die pull request mergen. Met één knop zet ik een concept klaar voor review, en dat start een routine die het concept nakijkt of een opdracht uitvoert. Valt het dashboard ooit uit, dan kan ik de posts gewoon in GitHub zelf bewerken.

Testen: wat de documentatie niet zegt

Elke pull request die de site verandert, krijgt een voorbeeld, zodat ik een post zie zoals hij gepubliceerd wordt. Daarnaast testte ik de koppelingen zelf, en drie dingen liepen anders dan ik verwachtte:

Netwerktoegang. De eerste geplande run kon de documentatie van Microsoft en Apple niet openen. Een routine haalt webpagina’s alleen op van de domeinen die de cloudomgeving toestaat. Na het toevoegen van die domeinen kwam dezelfde dag de eerste post.
Een draft startte geen routine. Het dashboard opent elke pull request eerst als draft. In mijn test op 13 oktober startte een routine daar niet op; pas toen de pull request ready for review werd, liep hij binnen een halve minuut. De routines starten nu op ready for review.
Een koppeling ontbrak in een routine. Samen schrijven in een gedeeld document lukte in een gewone sessie, maar in een routine kreeg de AI die koppeling niet. Dat doe ik nu alleen nog in een sessie waar ik bij ben.

Ik liet de eerste post ook nalezen door een ander AI-model. De belangrijkste bevindingen gingen over framing, niet over feiten: de inleiding beloofde meer dan de bronnen. Daarom kijkt de feitencheck nu ook naar de post als geheel.

Publiceren doe ik zelf

De AI mag nooit zelf mergen, dat is een vaste regel; een post komt online als ik de pull request merge. Ik lees de post in het voorbeeld, vraag zo nodig om wijzigingen en beantwoord de open vragen. Dat werkt ook als filter: van de zestien pull requests met een nieuwe post uit de eerste week heb ik er elf gepubliceerd en vijf gesloten, bijvoorbeeld omdat ik een bestaande post liever bijwerkte dan er een nieuwe naast te zetten.

Tot slot

De AI schrijft, zoekt de bronnen en laat elke post nalopen; ik bepaal wat er online komt. De regels, de werkwijzen en het logboek staan in de repository, zodat elke run met dezelfde instructies begint en ik het werk van elke run kan teruglezen.