Week 10: No-code spaghetti
Wanneer je code vervangt door instructies, verdwijnt de complexiteit niet. Die verandert van vorm. Over verstrooide skills, onzichtbaar onderhoud en de ironie van een AI-burnout script.
Vorige week schreef ik enthousiast over een website bouwen zonder code. Skills die beschrijven wat er moet gebeuren, Claude Code dat uitvoert. “Geen code, geen problemen?” was de grap. Deze week kwam het antwoord: nee, andere problemen.
Het begon met een simpele vraag die ik mezelf stelde: waar pas ik ook alweer het vinden van onderwerpen voor de podcast aan? Ik kon het niet vinden. Niet omdat het weg was, maar omdat mijn instructies verspreid staan over mappen, projecten en configuratiebestanden. Net als die ouderwetse spaghetti code waar we in de softwareontwikkeling juist vanaf willen.
Instructies als spaghetti
De afgelopen weken heb ik steeds meer processen geautomatiseerd met skills en agents. Een topic scout die wekelijks trending AI-onderwerpen vindt. Een dagelijkse routine die podcast statistieken bijwerkt, LinkedIn drafts maakt en de website publiceert. Geen van deze automatiseringen bevat traditionele code. Het zijn instructies in Markdown die Claude Code interpreteert en uitvoert.
Het probleem is dat deze instructies dezelfde structuurproblemen krijgen als code. Sommige bestanden staan in ~/.claude omdat ze hergebruikt worden. Andere staan in een projectfolder. Weer andere verwijzen naar bestanden in nóg een project. Terwijl ik bezig was met het toevoegen van episode-specifieke deeplinks aan de podcastwebsite, moest ik door drie projecten navigeren om te begrijpen hoe de onderdelen samenhangen.
Het voelt als een bekend patroon. Je bouwt snel, alles werkt, en op een dag kijk je achterom en zie je een web van afhankelijkheden. Het verschil is dat dit web niet bestaat uit imports en functies, maar uit SKILL.md bestanden en contextverwijzingen. De les is dezelfde: structuur is geen luxe, het is een voorwaarde.
Het onzichtbare onderhoud
Wat deze week ook duidelijk maakte: geautomatiseerde systemen vereisen onderhoud dat je niet ziet aankomen. Een JavaScript parse error op de gastenpagina bleek veroorzaakt door een niet-geëscapete aanhalingsteken in een episodetitel. Een database constraint faalde omdat het ene systeem “multi-guests” gebruikt en het andere “multi-guest”. De statistiekenpagina die ik handmatig had aangepast werd overschreven door een script dat de index regenereert.
Elk van deze problemen was klein en snel opgelost. Maar samen vertellen ze een verhaal over de verborgen kosten van automatisering. Je bouwt een pipeline die dagelijks draait, en op een dag werkt een onderdeel niet meer omdat data net anders is dan verwacht. De fix kost vijf minuten, maar het vinden van de oorzaak kan een uur duren als je niet precies weet hoe de onderdelen samenhangen.
Het cross-project probleem viel het meest op. Een sync script in het ene project genereert bestanden voor een ander project. Wie is eigenaar? Waar hoort de logica thuis? Het zijn dezelfde vragen die je stelt bij microservices, maar dan met AI-instructies in plaats van API’s.
Burnout schrijven terwijl je scope creep ervaart
Het meest ironische moment van de week: ik schreef een podcastscript over AI-burnout terwijl ik zelf midden in een scope creep patroon zat. De topic scout had AI-burnout als trending onderwerp geïdentificeerd. Vervolgens analyseerde ik mijn eigen daily summaries van de afgelopen tien dagen en ontdekte precies het patroon waar het script over gaat. Features die uitgroeien tot iets groters. Kleine aanpassingen die nieuwe aanpassingen triggeren.
Het script werd persoonlijker dan gepland. In plaats van alleen onderzoek te citeren, kon ik eerlijk schrijven over hoe ik zelf in die valkuil trap. De journals van de afgelopen weken leverden concrete voorbeelden: deeplinks die uitgroeiden tot volledige episode-pagina’s, een simpele zoekfunctie die een complete zoekmachine werd. Niet omdat iemand erom vroeg, maar omdat het kón.
Dat is misschien de kern van AI-burnout bij developers. De drempel om “nog even iets extra’s” te bouwen is zo laag geworden dat je niet merkt wanneer je over de grens gaat. Niet de grens van wat technisch kan, maar de grens van wat zinvol is.
Cookie-vrije analytics
Tussendoor ontwierp ik een GDPR-compliant tracking systeem voor de podcastwebsite. Geen cookies, geen externe services, geen IP-opslag. Een simpel PHP-endpoint dat pagina, tijdstip en referrer registreert in een flat file. Het ontwerp paste bij het thema van de week: minimaal, zelf gehost, onder eigen beheer.
De keuze voor een self-hosted oplossing was bewust. Na de ervaring met publieke SearXNG instances die mijn verzoeken blokkeerden, wil ik zo min mogelijk afhankelijk zijn van externe diensten. Eigen infrastructuur betekent eigen controle, ook al kost het meer opzettijd.
Wat het met mij deed
De ontdekking dat mijn instructies spaghetti waren geworden, raakte me meer dan ik verwachtte. Niet omdat het een groot probleem is - het is oplosbaar. Maar omdat het laat zien dat de uitdagingen van softwareontwikkeling niet verdwijnen als je de programmeertaal verandert. Of die taal nu Python is of Nederlands.
Ik merk dat ik steeds bewuster nadenk over architectuur van instructies. Niet de architectuur van code, maar van beschrijvingen. Waar hoort een skill thuis? Hoe verwijs je vanuit de ene instructie naar de andere? Hoe voorkom je dat twee bestanden hetzelfde beschrijven met net andere woorden? Het zijn dezelfde vragen, in een ander jasje.
De week eindigde met een mix van frustratie en herkenning. Frustratie over de rommeligheid. Herkenning omdat dit precies is wat er gebeurt als je snel bouwt zonder terug te kijken. Het experiment leert me niet alleen over AI, maar ook over mezelf als bouwer. De neiging om door te gaan, nog iets toe te voegen, nog een feature. De discipline om te stoppen en op te ruimen is dezelfde als altijd. Die verandert niet mee met de technologie.