Je app is met AI gebouwd. Wat staat er eigenlijk onder de motorkap?

Ik gebruik AI-tools elke dag. Grote delen van Altrady en Coinray zijn zo begonnen: een idee, een paar prompts, en binnen een dag iets dat draait. Dat is niet niks, en ik ga er ook niet cynisch over doen. Maar ik weet uit eigen ervaring wat er daarna gebeurt, want ik heb die code vervolgens flink moeten opruimen om hem leesbaar, snel en onderhoudbaar te houden.

Dat is het stuk dat je in demo’s nooit ziet. De app werkt. De knoppen doen wat ze moeten doen. En toch zit er onder die oppervlakte iets dat over een half jaar bepaalt of je nog vooruit kunt.

Werkend en gezond zijn niet hetzelfde

Als je geen ontwikkelaar bent, is werkende software je enige meetlat. Logisch. Je klikt erdoorheen, het doet wat je had bedacht, klaar.

Alleen zegt dat weinig over hoe het gebouwd is. Software die werkt kan intern bestaan uit één bestand van tweeduizend regels waarin alles door elkaar loopt. Dat draait prima. Tot je iets wilt veranderen. Dan moet iemand dat hele bestand begrijpen voordat hij één regel durft aan te raken, en dat is precies het moment waarop kleine wijzigingen ineens dagen gaan kosten.

Ik bouw het liefst als Lego. Losse blokjes die je kunt hergebruiken, elk met een duidelijke taak. Een knop is een blokje. Een formulier is een blokje. Het ophalen van gegevens is een blokje. Als je later iets wilt aanpassen, pak je één blokje en laat je de rest met rust. AI-tools kiezen die structuur niet uit zichzelf. Ze schrijven wat op dat moment het snelst tot een werkend resultaat leidt, en dat is bijna altijd één lang stuk code.

Waar ik naar kijk als ik zulke code openmaak

Leesbaarheid komt eerst. Kan ik zonder uitleg volgen wat er gebeurt? Niet omdat mooie code een doel op zich is, maar omdat elke ontwikkelaar die er na jou instapt dezelfde vraag stelt, en jij betaalt voor de tijd die hij nodig heeft om het antwoord te vinden.

Daarna kijk ik naar variabelen. Hoe dingen genoemd worden, verraadt of iemand nagedacht heeft over wat ze betekenen. Vervolgens naar hulpfuncties: staan die er wel, maar worden ze nergens gebruikt? Dat gebeurt vaker dan je denkt. Er wordt een nette oplossing neergezet en tien regels verderop staat diezelfde logica alsnog met de hand uitgeschreven.

En dan duplicatie. Dezelfde berekening op vier plekken betekent dat je bij elke wijziging vier plekken moet vinden. Vind je er drie, dan heb je een bug die pas weken later boven water komt.

Dat is geen esoterisch vakmanschap. Het zijn de vier dingen die bepalen hoeveel je volgende aanpassing kost.

Wat een check-up inhoudt

Ik neem een dag om de code te lezen. Ik klik door de applicatie heen zoals een gebruiker dat doet, zodat ik weet wat er achter elk scherm zou moeten zitten. En ik zet mijn eigen AI-gereedschap in om snel de plekken te vinden waar het schuurt, want een machine vindt duplicatie en te lange bestanden nu eenmaal sneller dan ik.

Die eerste verificatie begint bij 500 euro. Daarna krijg je een uitgewerkt plan: wat er goed zit, wat er misgaat, wat het kost om verder te kunnen, en in welke volgorde.

Ik heb tot nu toe apps van anderen niet gerepareerd. Wat ik wel heb gedaan, is mijn eigen met AI gebouwde code productieklaar maken, en dat is precies dezelfde oefening.

Repareren of opnieuw bouwen

Dit is de vraag die iedereen als eerste stelt, en het eerlijke antwoord is: dat hangt ervan af.

Je gooit niet weg wat technisch te repareren is. Maar technisch repareerbaar is ook geen argument op zichzelf. De enige meetlat die telt is wat goedkoper uitpakt. Is een herbouw van dat onderdeel minder werk dan het uit elkaar halen en opnieuw in elkaar zetten van wat er staat, dan bouw je opnieuw. Valt het andersom uit, dan refactor je.

Ik ben daar nuchter in. Er is veel code die niet het mooiste is wat ik ooit heb gezien en waar je prima mee verder kunt. Die laat ik staan. Elk uur dat je besteedt aan het opschonen van iets dat gewoon werkt, is een uur dat je niet aan je klanten besteedt.

Wat AI wel en niet voor je doet

AI-tools zijn tools. Niet meer en niet minder. Als niet-ontwikkelaar kun je er redelijk goed een eerste prototype mee maken, en dat is echt waardevol. Je kunt een idee laten zien in plaats van het uitleggen.

Waar het misgaat, is de aanname dat een werkend prototype hetzelfde is als een product. Om te beoordelen wat er daadwerkelijk gebouwd is, heb je jaren code-review-ervaring nodig. Ik heb teams op de ouderwetse manier geleid: junioren en senioren die hun code voorlegden, en die code was soms goed en soms slecht. Dat oordeel bouw je op door het honderden keren te doen.

Weten wanneer iets goed genoeg is, wat je overslaat en wat je er wel in stopt, dat is waar de echte waarde van AI zit. De tool schrijft de regels. Jij, of iemand die je daarvoor inhuurt, bepaalt welke regels blijven staan.

Tot slot

Als je een app hebt laten bouwen en je merkt dat aanpassingen langer duren dan je had verwacht, is dat geen teken dat je iets doms hebt gedaan. Het is het normale verloop van software die snel tot stand is gekomen. De vraag is alleen of je nu weet wat er staat, of dat je daar over een jaar achter komt als het duurder is geworden.

Een dag lezen kost 500 euro en geeft je een plan. Wil je weten waar je aan toe bent, stuur me dan een bericht en dan kijken we er samen naar.