AI code schrijven: checklist om AI-code na te kijken

Bij AI code schrijven neemt de AI het typwerk over, maar jij blijft verantwoordelijk voor wat live gaat. Je hebt geen programmeerdiploma nodig om dat goed te doen. Je hebt een vaste werkwijze nodig: een duidelijke opdracht, kleine stappen, testen buiten je live site en uitleg bij elk onderdeel.

Hierboven staat de checklist. Hieronder leg ik uit waarom ze werkt, hoe je ze toepast en waar het meestal misloopt.

Waarom AI-code nakijken belangrijker is dan AI-code schrijven

Vroeger typte ik elke letter code zelf. Nu doet AI dat, en dat scheelt uren. Maar het typwerk was nooit het moeilijkste deel van programmeren.

Het moeilijkste is beslissen wat er gebouwd wordt, en nakijken of het ook klopt. De AI doet dat niet voor jou. Ze geeft je een antwoord dat er overtuigend uitziet, ook als het niet klopt.

Ik zie vooral vier fouten:

1. een vage opdracht geven
2. blind plakken wat eruit komt
3. alles in één keer laten bouwen
4. code laten staan die niemand begrijpt

De checklist is gebouwd rond die vier fouten.

Hoe schrijf je een opdracht die geen gok oplevert?

Een opdracht als "maak me een klantenportaal" laat de AI zelf de gaten invullen. Die invulling klopt meestal niet met wat jij in gedachten had.

Schrijf voor je begint drie dingen op:

• Wat moet het doen? Bijvoorbeeld: klanten loggen in en zien hun openstaande facturen.
• Voor wie? Klanten, medewerkers, enkel jijzelf?
• Wat moet het niet doen? Bijvoorbeeld: klanten mogen nooit facturen van een andere klant zien en niets kunnen aanpassen.

Het laatste punt wordt het vaakst vergeten, en het is net het punt dat je later gebruikt om te testen. Heb je opgeschreven wat niet mag, dan weet je wat je moet proberen te breken.

Waarom blind plakken fout gaat

Code die op je scherm werkt, kan nog steeds crashen, lekken of data wissen zodra er echte klanten op zitten. Dat komt doordat je zelf het "gelukkige pad" test: je vult alles correct in, in de juiste volgorde.

Echte gebruikers doen dat niet. Ze laten velden leeg, vernieuwen de pagina halverwege een betaling, plakken een e-mailadres met een spatie erbij en proberen soms met opzet dingen die niet mogen.

Daarom staan in de checklist punten over foute invoer, toegangsrechten en foutgevallen. Test die altijd in een aparte omgeving, met nepdata. Dan kost een fout je een paar minuten in plaats van een klant of een databank.

Welke punten laat je het best door iemand anders nalezen?

Drie soorten code laat je niet zonder tweede paar ogen live gaan:

• code die betalingen verwerkt
• code die persoonsgegevens van klanten opslaat of verstuurt
• code die iets verwijdert of overschrijft

Kan je zelf niet lezen wat de code doet, vraag dan een programmeur om ze na te kijken. Dat kost een uur of twee. Een lek of een gewiste databank kost veel meer.

Waarom kleine stappen beter werken dan één grote opdracht

Een heel systeem in één opdracht levert een kluwen op. Zit er een fout in, dan weet niemand waar.

Werk daarom in stappen die je in een paar minuten kan testen. Voor een klantenportaal kan dat zo:

1. Inloggen, en niets anders.
2. Een lijst met facturen tonen, met nepdata.
3. Een factuur openen als PDF.
4. Toegangsrechten: een klant mag enkel zijn eigen facturen zien.

Test na elke stap. Werkt het, bewaar het dan in versiebeheer zoals Git. Gaat de volgende stap mis, dan draai je terug naar de vorige werkende versie. Zonder die tussenstappen zoek je in een kluwen.

Wat doe je met code die je niet begrijpt?

Als enkel de AI weet hoe het in elkaar zit, zit jij vast bij de eerste fout of de volgende aanpassing. Dat gebeurt sneller dan je denkt. Je wil over een half jaar iets wijzigen en je weet niet meer waarom iets zo gebouwd is.

Er zijn twee oplossingen, en je gebruikt ze best allebei:

• Vraag de AI om bij elk onderdeel op te schrijven wat het doet en waarom.
• Bewaar die uitleg bij de code, bijvoorbeeld in een bestand in hetzelfde project.

Begrijp je de uitleg zelf niet, dan is dat een signaal. Vraag een eenvoudigere aanpak, of laat die code niet live gaan.

Voorbeeld: een offerteformulier laten bouwen

Stel dat je een bakkerij hebt en je laat AI een formulier maken voor taartbestellingen op je website. Het toont mooi op je scherm en de bevestigingsmail komt aan. Klaar?

Loop dan de checklist af:

• Invoer: wat als iemand 5.000 taarten invult, of een datum in het verleden kiest?
• Sleutels: staat het wachtwoord van je mailaccount in de code?
• Foutgeval: wat ziet de klant als het versturen van de mail mislukt? Gaat de bestelling dan verloren zonder dat iemand het merkt?
• Terugdraaien: kan je de oude versie van je pagina snel terugzetten?

Dat zijn vier controles van enkele minuten. Je hebt er geen code voor nodig, enkel testen en vragen stellen.

Wanneer bouw je zelf, en wanneer laat je het doen?

AI-programmeren is ideaal voor kleine hulpmiddelen, prototypes en automatisaties die je zelf beheert. Het wordt risicovoller bij systemen waar klantdata, betalingen of je dagelijkse werking aan hangen.

Wil je een volledige website laten maken of een CRM op maat dat je team elke dag gebruikt, dan loont het om dat met een team te bouwen dat de code ook onderhoudt. Zoek je een automatisatie die taken in je bedrijf overneemt, bekijk dan hoe AI automations in de praktijk werken.

Twijfel je tussen zelf bouwen en uitbesteden? Stuur me gerust een bericht via contact. Dan bekijken we samen wat zelf kan en wat beter door een ontwikkelaar wordt gedaan.

Zo gebruik je de checklist in de praktijk

Print ze niet uit om ze in een lade te laten liggen. Kopieer ze in het bestand van je project en vink ze af bij elke wijziging die live moet.

Drie gewoonten maken het verschil:

• Neem het nakijken mee in je planning. Reken op een kwart van de tijd die het bouwen kostte.
• Ga niet live op vrijdagnamiddag. Als er iets misloopt, wil je tijd hebben om het te herstellen.
• Volg de eerste uren na het live gaan op, zodat je een fout vindt voor je klanten dat doen.

AI typt je code. Jij beslist of ze live mag.