Mijn AI-workflow: kleine opdrachten, duidelijke grenzen

Een AI-assistent kan in korte tijd veel code voorstellen. Daarna moet iemand kunnen beoordelen of die code het juiste probleem oplost. Zodra een opdracht tegelijk over schermen, rechten, gegevens en externe diensten gaat, wordt dat lastig. In mijn AI-workflow begint de verbetering daarom vóór de uitvoering: de opdracht moet kleiner en het gewenste resultaat duidelijker.

Als developer en ondernemer wil ik vooruitgang kunnen beoordelen aan bruikbaar gedrag. Een overtuigende demonstratie zegt nog weinig over onderhoud, uitzonderingen of bestaande gebruikersgegevens. Mijn recente ontwikkelwerk draait daarom om relevante context, afgebakende bevoegdheden en controles die bij dezelfde opdracht horen. Dat vraagt voorbereiding, maar maakt zichtbaar wat af is en welke beslissingen nog openstaan.

Een AI-workflow begint met een afgebakende opdracht

“Bouw een koppeling” laat veel ruimte voor aannames. Welke gegevens mogen worden opgehaald? Moet er iets worden gewijzigd? Zijn accounts en toestemming al geregeld? Een concretere opdracht is een alleen-lezen overzicht bouwen met vooraf gekozen velden, gevoed door voorbeeldgegevens. Daarvan is te beoordelen of het scherm en de gegevensstructuur passen bij de productvraag.

In recente ontwikkelprojecten is die verdeling expliciet vastgelegd. Tests, gegevenscontracten en beperkte overzichten kunnen als zelfstandige onderdelen worden uitgevoerd. Werk dat toegangsrechten verruimt, beschermde informatie vrijgeeft of een externe actie veroorzaakt, vraagt een eigen beoordeling. Een kleine wijziging kan grote gevolgen hebben; het aantal regels code helpt weinig bij die afweging.

Relevante context voorkomt verborgen aannames

Een assistent heeft de bestaande projectafspraken nodig. Hoe zijn vergelijkbare functies opgebouwd? Welk onderdeel kan worden hergebruikt? Welke controle beschermt de gegevens die worden aangepast? Die context komt uit de directe omgeving van de wijziging: bestaande code, relevante tests en de afspraken die voor dat domein gelden.

Alles meesturen verschuift de selectie naar het model. Daarom helpt het om vooraf te bepalen welke informatie beslissend is. Een opdracht voor een publiek overzicht heeft bijvoorbeeld de toegestane velden nodig en voorbeelden van wat privé moet blijven. De complete administratie voegt daar weinig aan toe. Context selecteren blijft ontwikkelwerk: als de opdracht verandert, moet ook de selectie opnieuw worden bekeken.

Een kleine eerste stap maakt het plan toetsbaar

Een eerste stap hoeft nog geen complete functie op te leveren. Een gegevensstructuur, een test voor het gewenste gedrag of een scherm met vaste voorbeelden kan een ontwerpvraag concreet maken. Dat helpt wanneer een externe partij nog niet is aangesloten of een productkeuze nog aandacht vraagt. De afhankelijkheid wordt zichtbaar zonder alvast op de uitkomst vooruit te lopen.

De beperking is dat zo'n deelresultaat gemakkelijk groter lijkt dan het is. Een overzicht met voorbeeldgegevens toont hoe informatie kan worden gepresenteerd; het bewijst niets over een werkende leverancierkoppeling. Daarom moet ook worden beschreven wat buiten de opdracht blijft. Het vervolgwerk krijgt daarmee een duidelijke ingang, in plaats van een verzameling aannames die later moeten worden ontrafeld.

Van productvraag naar controleerbaar werk

Voor een volgende ontwikkelstap helpt deze volgorde om de opdracht concreet te maken:

1. Beschrijf het gebruikersprobleem en het gedrag dat moet veranderen.
2. Selecteer de bestaande code, gegevens en afspraken die daarvoor nodig zijn.
3. Leg vast welke handelingen en bevoegdheden buiten de opdracht blijven.
4. Bepaal vooraf welke controles aantonen dat het onderdeel af is.

Afmaken betekent ook fouten en onderbrekingen behandelen

De normale route is maar een deel van de functie. Wat gebeurt er wanneer een antwoord halverwege stopt? Wat als iemand intussen zelf iets verandert? In recent werk aan het genereren van voertuigteksten is dat concreet gemaakt: een antwoord wordt eerst volledig verzameld en gecontroleerd voordat het de bestaande tekst vervangt.

Heeft de gebruiker ondertussen zelf geschreven of zijn de voertuiggegevens veranderd, dan mag het oude generatieverzoek dat werk niet alsnog overschrijven. Een onderbroken of leeg antwoord wordt evenmin overgenomen. De afweging is zichtbaar in de interface: de gebruiker wacht op het complete resultaat, terwijl bestaande tekst behouden blijft wanneer de generatie mislukt.

Bij zo'n wijziging horen tests voor onvolledige antwoorden, foutmeldingen en gewijzigde invoer. Daarmee wordt de foutafhandeling onderdeel van het opgeleverde werk. Dat is belangrijk bij AI-ondersteund ontwikkelen, omdat een assistent anders vooral de verwachte route kan uitwerken. Juist de minder aantrekkelijke randgevallen bepalen wat gebruikers ervaren wanneer de omstandigheden afwijken.

Lokale controles en review hebben ieder een functie

Reproduceerbare controles maken het mogelijk om een wijziging opnieuw te onderzoeken. In recente projecten gebeurt dat onder meer met tijdelijke lokale databases voor migraties en grensgevallen. Elders past een geïsoleerde omgeving in de automatische controles. De keuze hangt af van het project; productiegegevens en echte externe acties zijn daarvoor vaak onnodig.

Review blijft daarnaast nodig. Een test kan laten zien dat vastgelegd gedrag wordt uitgevoerd. Een reviewer kijkt ook naar samenhang, begrijpelijkheid en onderhoud. Zijn er bestaande onderdelen overgeslagen? Is de opdracht onbedoeld groter geworden? Een geslaagde test is bruikbaar bewijs voor een specifieke controle, terwijl de kwaliteit van de oplossing breder beoordeeld moet worden.

Publiceren blijft een afzonderlijke beslissing

Ook na controle kunnen configuratie, samenhang met ander werk en openstaande productvragen aandacht vragen. Daarom houd ik opleveren en publiceren als afzonderlijke stappen herkenbaar. De kans van AI zit voor mij in afgebakende uitvoering met zichtbare verantwoordelijkheid: kleinere opdrachten, afgemaakt gedrag en bewijs dat past bij de wijziging.

Wil je deze AI-workflow toepassen op een bestaand product of ontwikkelteam? Mail me over een concrete ontwikkelopgave. Dan kan de eerste vraag zijn welk klein onderdeel bruikbaar is, waar de beslisruimte ligt en hoe het resultaat gecontroleerd kan worden.