---
title: "AI laten programmeren zonder je codebase te slopen: de zes checkpoints"
date: 2026-06-27
author: "Sam"
featured_image: "https://promptcoaching.nl/wp-content/uploads/2026/06/promptcoaching-nl-202-hero.png"
categories:
  - name: "AI en strategie"
    url: "/category/ai-en-strategie.md"
---

# AI laten programmeren zonder je codebase te slopen: de zes checkpoints

## Liever kijken dan lezen?

Deze korte video zet de workflow in minder dan een minuut scherp.

Je browser ondersteunt geen video.

**AI kan prima helpen met programmeren, maar alleen als jij de volgorde en de controlepunten bepaalt.** Laat een model niet meteen “de feature bouwen”. Dwing het eerst langs data, interfaces, todo’s, een proefimplementatie, invarianten en pas daarna de echte wijziging. Dat is trager in de eerste vijf minuten, maar voorkomt dat je een halve dag code zit terug te draaien.

## AI-assisted software development in de praktijk

Hoe werkt dat concreet? Je geeft een AI-agent niet één grote opdracht maar een reeks kleine, gecontroleerde stappen: eerst laat je hem het datamodel en de interfaces voorstellen, dan een proefimplementatie met tests, en pas daarna de echte wijziging in je codebase. Na elke stap controleer jij het resultaat met de checkpoints uit dit artikel. Zo blijft AI-assisted software development een cyclus van opdracht, bewijs en controle, in plaats van een hoopvol “bouw maar” waar je daarna uren tegenaan praat.

De nieuwe workflow uit de Primeagen-video is interessant omdat hij niet verkoopt dat AI de programmeur vervangt. Het punt is scherper: als je onderweg bent, op je telefoon zit of even geen diepe focus hebt, kun je nog steeds vooruitgang boeken zolang de agent niet vrij door je codebase mag rennen.

**Update 16 juli 2026:** Moonshot AI noemt bij Kimi K3 precies de twee risico’s waarvoor deze checkpointworkflow bedoeld is. Als eerdere denkgeschiedenis niet volledig wordt teruggegeven, kan de kwaliteit instabiel worden. En als je grenzen vaag laat, kan het model te proactief worden en onverwachte beslissingen namens jou nemen.

## Wat Kimi K3 aan deze workflow toevoegt

Een groot contextvenster lost geen onduidelijke opdracht op. K3 kan 1 miljoen tokens meenemen, maar de agent moet nog steeds weten welke context bindend is, welk bewijs telt en wanneer hij stopt. Voeg daarom vóór de bestaande zes checkpoints een history-gate toe.

1. **Taak:** staat de oorspronkelijke opdracht nog volledig in de sessie?
2. **Besluiten:** zijn alle menselijke akkoorden en afwijzingen bewaard?
3. **Bewijs:** staan relevante testresultaten, diffs en screenshots in de geschiedenis?
4. **Modelcontinuïteit:** is deze run met K3 begonnen, of probeer je midden in een andere modelsessie over te stappen?

Pas als dat klopt, ga je naar structs, interfaces en de andere checkpoints hieronder.

## Bekijk de uitleg in 22 seconden

De kern van dit artikel, met een eigen Nederlandse voice-over en captions.

Je browser ondersteunt geen video.

## Promptblok voor context, bewijs en stopgrenzen

```
Behoud binnen deze run de volledige taakgeschiedenis:
opdracht, besluiten, tooloutput, testbewijs en open risico's.

Ga niet verder als vereiste geschiedenis ontbreekt.
Wissel niet halverwege van model zonder een nieuwe intake.

Werk per fase:
1. doel en non-goals;
2. kleinste veilige actie;
3. objectief bewijs;
4. rapportage;
5. wacht op akkoord als de volgende stap extern, publiek,
   financieel, destructief of lastig terug te draaien is.

Bij ambiguïteit: stel één gerichte vraag.
Neem geen onverwachte beslissing namens mij.
```

Het belangrijke verschil zit in de laatste twee regels. “Wees proactief” is geen bruikbare toestemming. Zeg waar initiatief gewenst is en waar de agent moet stoppen. Een model mag zelf relevante bestanden zoeken; het mag niet zelf besluiten een productieomgeving te wijzigen of iets te publiceren.

## Gebruik vision als bewijs, niet als vervanging van tests

K3 heeft native vision. Bij web- en appwerk kan de agent daardoor een render of screenshot bekijken en daarna de code aanpassen. Dat is nuttig voor layout, visuele regressies en interfaces.

Combineer die visuele check met een echte test. Een pagina kan er goed uitzien terwijl de knop niet werkt. Een test kan slagen terwijl de mobiele tekst buiten beeld valt. Vraag daarom per fase om beide soorten bewijs wanneer de wijziging een interface raakt.

Moonshots eigen advies is opvallend direct: zet expliciete gedragsgrenzen in je system prompt of `AGENTS.md`. Dat maakt K3 geen speciaal geval. Het bevestigt een algemene regel voor AI-coding: meer autonomie vraagt om betere context, kleinere bewijsstappen en een hardere stop.

Bron: [Moonshot AI, Kimi K3 Tech Blog — Limitations](https://www.kimi.com/blog/kimi-k3#limitations), 16 juli 2026.

## De zes checkpoints

De bruikbare vorm is simpel genoeg om morgen te gebruiken:

1. **Structs:** welke data verandert of komt erbij?
2. **Interfaces:** welke functies of API’s moeten bestaan?
3. **Todo’s:** waar in de code moet straks iets gebeuren?
4. **Proefimplementatie:** implementeer, test, draai terug en rapporteer waar het plan niet klopte.
5. **Invarianten:** welke regels mogen na de wijziging nooit breken?
6. **Implementatie:** pas nu mag de echte diff blijven staan.

Het slimme zit vooral in stap vier. Een model dat eerst moet implementeren en daarna uitleggen waar het buiten het plan moest treden, geeft je informatie terug. Je ziet niet alleen de code, maar ook waar je ontwerp nog gaten heeft.

## Waarom dit beter werkt dan “bouw deze feature”

Een algemene opdracht dwingt het model om te gokken. Het maakt dan zelf keuzes over data, naamgeving, locatie, teststrategie en randgevallen. Soms gaat dat goed. Vaak krijg je code die werkt in de demo, maar vreemd voelt in de codebase.

Met checkpoints houd je eigenaarschap. Je keurt eerst het datamodel. Daarna pas de interface. Daarna pas de lijst met plekken waar code verandert. Als één stap niet klopt, ga je niet door. Dat klinkt streng, maar het is precies hoe je voorkomt dat AI “bijna goede” code overal verspreidt.

## Een goede AI-coding prompt

Gebruik niet één grote opdracht. Gebruik een fasering zoals deze:

```
We werken in checkpoints. Ga pas naar de volgende fase als ik akkoord geef.

Fase 1: beschrijf alleen de benodigde data structures.
Geen implementatie.

Fase 2: beschrijf alleen de functies/interfaces die moeten veranderen.
Geen implementatie.

Fase 3: zet per bestand concrete todo's neer.
Leg uit waarom elke todo nodig is.

Fase 4: maak een proefimplementatie, run de kleinste nuttige check,
draai de wijziging terug en rapporteer waar je buiten de todo's moest werken.

Fase 5: formuleer invarianten die na de wijziging waar moeten blijven.

Fase 6: implementeer pas na akkoord.
```

Dat is niet spectaculair. Dat is juist de waarde. Je haalt de agent uit de demo-stand en zet hem in een werkritme dat reviewbaar blijft.

## De testlaag: laat AI iets echts controleren

In de video zit een goed detail: de game heeft een JSON-modus waarmee acties kunnen worden afgespeeld zonder de normale renderlaag. Dat is voor AI-coding belangrijker dan het klinkt. Een agent kan pas zinnig doorwerken als hij een snelle, objectieve feedbacklus heeft.

Voor een webapp kan dat een Playwright-check zijn. Voor een CLI een command met vaste output. Voor een game een headless simulatie. Voor een contentworkflow een publicatiegate. De vorm maakt minder uit dan de eigenschap: het resultaat moet controleerbaar zijn zonder dat jij elke regel handmatig hoeft te bekijken.

## Wanneer je juist zelf moet typen

Niet elk programmeerprobleem is goed in taal te vangen. Sommige wijzigingen zijn voor een ontwikkelaar in tien minuten duidelijker te typen dan in vijf prompts uit te leggen. Herken dat moment. AI is slecht in problemen waar de nuance in lokale codevorm, laagverdeling of interactievolgorde zit.

Een goede workflow laat je dus niet minder programmeren. Hij laat je beter kiezen wanneer je programmeert, wanneer je laat voorbereiden en wanneer je een agent terugstuurt naar de vorige fase.

## Praktische regel voor Promptcoaching

Als je AI inzet voor code of automatisering, vraag dan nooit alleen om output. Vraag om een route, een controlepunt en een stopregel. Dat sluit aan op de stap van losse prompts naar [gedelegeerde AI-taken](https://promptcoaching.nl/van-prompts-naar-gedelegeerde-taken/): het model krijgt werk, maar jij houdt de beslissing wanneer het goed genoeg is.

Wil je je eigen opdracht aanscherpen voordat je hem aan Cursor, Codex of Claude geeft? Gebruik dan de [gratis Prompt Coach](https://promptcoaching.nl/prompt-coach/) en laat vooral controleren of je prompt een duidelijke fase, bewijs en stopregel bevat.

## Verder lezen

Bij AI-coding is de prompt maar de helft. De andere helft is checkpointen: kleine taken, diff lezen, testen en pas daarna doorbouwen. Lees daarna ook [bekijk Codex use cases](/codex-use-cases/) of [check je AI-code voor publicatie](/ai-site-controleren-voor-publicatie/).