Analyse, plan, code, controles: ons ritme voor ontwikkelen met AI 🤖

We hebben nooit verborgen dat we veel AI gebruiken voor Blocks Beyond The Stars — zonder zou een spel van deze omvang als project na het werk simpelweg niet haalbaar zijn. Maar “ontwikkelen met AI” betekent voor ons niet: een wens typen, het resultaat nemen, hopen. In de loop van de maanden is er een vast patroon ontstaan dat verrassend ouderwets klinkt — en juist daardoor werkt. Vandaag leggen we het helemaal uit.

Het begint altijd met een mens en een idee. Voordat een AI iets doet, wilde of merkte iemand iets: een speler die met de feedbacktoets meldt dat dieren in zijn muren verschijnen — of wijzelf, als Justus midden in het spel zegt wat hij mist. De AI verzint hier geen taken. Ze krijgt ze.

Dan werkt de AI in fases. Vier, altijd in dezelfde volgorde: analyse, planning, implementatie, verificatie. (De vijfde stap, handmatig testen, komt daarna — maar dat is weer werk voor een mens, daarover zo meer.) De belangrijkste truc is wat de AI niet mag doen: meteen code schrijven. Een AI die meteen begint te typen, lost het verkeerde probleem op met indrukwekkende snelheid. Dus elke grotere taak begint met een analyse — wat is er al, waar ligt de oorzaak echt, wat hangt er nog meer aan vast? Het resultaat is tekst, geen code.

Dan komt het plan — en het wordt gelezen. Na de analyse volgt de planning: welke bestanden worden aangeraakt, in welke volgorde, welke valkuilen zijn bekend, welke beslissingen staan nog open? Juist hier komen de vragen boven die je beter vóór het programmeren kunt beantwoorden (“Moet dit ook in de browser werken?”, “Wat gebeurt er met oude savegames?”). Pas als het plan staat, volgt de implementatie — en dat is vaak het saaiste deel van het geheel. Precies zoals het hoort.

Verwante dingen gaan in één batch. Een tweede regel die ons veel tijd bespaart: als meerdere problemen op elkaar lijken of met elkaar samenhangen — vijf gamepadmenu’s met hetzelfde focusprobleem, of vijftien bevindingen uit dezelfde testronde — krijgt de AI ze gebundeld als één opdracht, niet als vijftien aparte. Ze hoeft de betreffende code dan maar één keer door te werken, de oplossingen passen bij elkaar in plaats van elkaar tegen te spreken, en er valt niets tussen twee opdrachten door.

Vóór elke release: twee aparte inspectierondes. Na elke grotere werkstap — en altijd voordat een nieuwe versie naar jullie gaat — zetten we de AI nog eens op het resultaat. Maar met twee bewust gescheiden onderzoeken. Eerst: zijn de beoogde functies en bugfixes echt helemaal af — of zit er ergens nog een half overblijfsel, een vergeten randgeval, een ontbrekende vertaling? Daarna, in een eigen ronde: hebben de wijzigingen nieuwe problemen elders veroorzaakt? Beide in één vraag mengen werkt niet — wie tegelijk naar gaten en naar nevenschade zoekt, vindt van allebei de helft. Apart gesteld besparen deze twee vragen ons enorm veel herwerk; een flink deel van wat in de release notes staat als “onderweg opgelost” komt precies uit deze inspectierondes.

En helemaal aan het eind test een mens opnieuw. De vijfde stap is geen AI-fase maar de onze: handmatig testen betekent echt spelen. Een vers gebouwde versie, een echte gamepad, een echt kind dat speelt. Heel veel dingen die elke analyse overleven, sneuvelen in de eerste vijf minuten op de bank. Want of iets goed aanvoelt, is een vraag die geen enkele analyse ter wereld kan beantwoorden.

Kijk goed en je vindt in dit patroon geen AI-magie, alleen eeuwenoud ingenieursvakwerk: eerst begrijpen, dan plannen, dan bouwen, dan controleren. En voor ons is het kader eromheen altijd hetzelfde: een mens heeft het idee, een mens doet de eindtest — de AI werkt daartussen. Het enige nieuwe is hoe snel die lus is geworden. 🔍