AI geassisteerde software ontwikkeling: Sneller werken zonder controle te verliezen

AI-geassisteerde software ontwikkeling als tegenhanger voor ‘vibe coding’

AI verandert de manier waarop software wordt ontwikkeld. Programmeurs kunnen code laten aanvullen, functies laten uitwerken, foutmeldingen laten analyseren en zelfs complete onderdelen van een applicatie laten genereren. Wat enkele jaren geleden nog toekomstmuziek leek, is inmiddels onderdeel van de dagelijkse praktijk.

Enkele weken geleden heb ik een artikel geschreven over de gevaren van ‘vibe coding’, je software te laten bouwen door een chatbot.

Wie alleen een globale opdracht invoert en vervolgens accepteert wat er verschijnt, kan inderdaad snel veel code produceren. Dat betekent echter nog niet dat er goede software ontstaat. De code moet begrijpelijk, onderhoudbaar, veilig, testbaar en uitbreidbaar zijn. Bovendien moet de applicatie daadwerkelijk doen wat de opdrachtgever of gebruiker nodig heeft.

Navigatie- en parkeerondersteuning, of een zelfrijdende auto?

Zou jij in een zelfrijdende auto stappen? Ik in ieder geval niet. Daartegenover staat, dat ik bepaalde technologische ontwikkelingen zoals bijvoorbeeld een inmiddels totaal geaccepteerde ‘GPS-navigatie’ en een wat nieuwere ‘parkeerondersteuning’ zondermeer acceptabel vind.

Wanneer we spreken over AI-ondersteunde software ontwikkeling tegenover vibe coding, dan hebben we het eigenlijk over eenzelfde vergelijking. Als professioneel softwareontwikkelaar, heb ik geen vertrouwen in een systeem wat compleet de controle overneemt en op basis van een vage beschrijving van wat de klant wil zien.

Sterker nog, als ervaren softwareontwikkelaar weet ik hoe moeilijk het is voor een klant om duidelijk te definiëren, wat er precies wordt verwacht. Omdat de klant weet wat hij wil -of althans dit denkt te weten, soms blijkt bij doorvragen, dat de klant er ook nog verder over na moet denken- maar ik geen kennis heb van de klant zijn specialisatie, zal ik allereerst door moeten vragen over het uiteindelijke product.

En dat liefst voor ik ook maar een regel code heb geschreven. Want iedere aanpassing kost tijd, en tijd is geld.

Zoals ook te lezen is in mijn reeds genoemde artikel over vibe coding, wanneer je AI laat beslissen over het complete bouwtraject, dan is het eindproduct vaak niet-onderhoudbare code. En door een gebrek aan duidelijke en gedetailleerde specificaties, ook vaak code die niet aan de verwachtingen voldoet.

Van zelf-schrijven, naar zelf-sturen

Coderen is voor 80% routinewerk. Ik heb in een grijs verleden een aantal jaren bij de Gasunie gewerkt, en op de ICT-afdeling daar hadden we daar een gezegde: ‘Een goede programmeur, is een luie programmeur’. Niet om aan te geven, dat een goede programmeur niets doet, maar een goede programmeur richt zijn programma’s zo in, dat er zo min mogelijk herhalingen in zitten.

Om eens een voorbeeld te geven. Wanneer ik in Laravel, of binnen de WordPress API een formulier met een tiental velden heb, die gegevens in moeten lezen en weg moeten schrijven naar een database, dan moet een aantal herhalende handelingen doen: Ik moet die tien velden in een formulier plaatsen. Daarnaast moet ik een functie hebben die vanuit de database de waarden ophaalt, laat zien in het formulier en als er op ‘Opslaan’ geklikt wordt de nieuwe waarden met de oude waarden vergelijkt, controles uitvoert met betrekking tot de juistheid van deze waarden en tenslotte de waarden in het formulier weer opslaat in de database.

Dat is in principe een super-routinematige handeling. Maar om dit te bereiken, moet je behoorlijk wat code schrijven. Wanneer je echter weet wat de velden in de database zijn die in het formulier komen te staan, dan zal vrijwel iedere ervaren programmeur uitkomen op vergelijkbare code om dit op te slaan. Kortom, het resultaat van de te verwachten code, is op basis van kennis van de structuur van de database compleet voorspelbaar.

Een taak die prima te delegeren is aan een AI functie. En al voor Generatieve AI opgang deed, waren er al editors als PHPStorm en Visual Studio Code, die op basis van zo’n database structuur regel-voor-regel suggesties deden, wat de volgende regel zou kunnen zijn, om de code te voltooien.

Generatieve AI (zoals ChatGPT en Claude Code) gaat hier nog een stap verder in. Maar dan moet je wel begrijpen hoe je taal of framework gestructureerd is, en een goed idee hebben van het door jou gewenste eindresultaat. Niet alleen ‘visueel’, maar ook met betrekking tot de technische keuzes.

Om terug te komen op ons voorbeeld van de auto: Een auto met alle mogelijke en denkbare technische voorzieningen om het rijden zo makkelijk mogelijk te maken, zal nog steeds een chauffeur nodig hebben, om mensen veilig van A naar B te brengen. Tenzij je natuurlijk het risico wilt wagen, om op een zelfrijdende auto te vertrouwen.

AI is geen programmeertaal

Een veelgemaakte fout is om AI te benaderen alsof het een nieuwe programmeertaal is. Alsof je alleen de juiste prompts hoeft te leren en vervolgens geen kennis meer nodig hebt van PHP, JavaScript, Python, Java, C# of een andere taal.

Maar AI vervangt de programmeertaal niet.

De applicatie wordt nog steeds gebouwd met een programmeertaal, een framework, databases, API’s en andere technische componenten. De coding agent helpt alleen bij het werken met die onderdelen.

Een ontwikkelaar die Laravel gebruikt, moet nog steeds begrijpen wat routes, controllers, models, middleware, queues en dependency injection zijn. Een WordPress-ontwikkelaar moet nog steeds kennis hebben van hooks, templates, database-interactie, gebruikersrechten en beveiliging. Hetzelfde geldt voor ontwikkelaars die werken met bijvoorbeeld Symfony, .NET, Django, Spring of Node.js.

AI kan code genereren die op het eerste gezicht overtuigend oogt, maar technisch toch onjuist is. Een methode kan niet bestaan, een configuratie kan verouderd zijn of een voorgestelde oplossing kan botsen met de architectuur van het project.

Wie onvoldoende kennis heeft van de gebruikte technologie, ziet zulke fouten niet altijd.

Laat AI je specificaties controleren!

Een coding agent kan pas goed werk leveren wanneer duidelijk is wat er gebouwd moet worden. Dat klinkt vanzelfsprekend, maar juist hier gaat het vaak mis.

Een opdracht als:

Bouw een applicatie waarmee gebruikers cursussen kunnen volgen.

is veel te algemeen.

Wat is een gebruiker? Welke soorten gebruikers bestaan er? Kan een cursus meerdere docenten hebben? Hoe worden lessen opgebouwd? Kunnen cursisten hun voortgang bewaren? Zijn cursussen gratis of betaald? Wat gebeurt er wanneer een cursus later wordt aangepast? Blijft een bestaande cursist dan gekoppeld aan de oude versie of krijgt hij automatisch de nieuwe versie?

Elke vraag heeft gevolgen voor de technische architectuur.

Ik heb zelf inmiddels ontdekt, dat de beste manier om goede en duidelijke specificaties te schrijven voor AI-ondersteunde software ontwikkeling het vragen om ondersteuning aan je favoriete AI code agent is. De eerste stap is in zoveel mogelijk detail te beschrijven, wat je functioneel wilt en wat de technische requirements zijn.

Zelf geef ik er een voorkeur aan dit document (omdat het iets is, wat je niet in één keer zal schrijven, is het goed om hier een apart document van te maken, in plaats van alles in één prompt te willen schrijven) in het MD (MarkDown) formaat te schrijven. Ben je niet bekend met het MD formaat, dan voldoet ieder ander formaat ook, maar door MD te gebruiken, kan je bepaalde zaken makkelijker structureren en benadrukken.

Ben ik klaar met mijn specificaties, dan eindig ik met :

Stel vragen om een goed advies om [de app / het package / de plugin] samen te kunnen stellen. Het uiteindelijke document moet een MD document zijn en geformatteerd voor een willekeurige Code Agent om te kunnen begrijpen.

Afhankelijk van wat ik wil maak ik mijn keuze voor ‘app’ (een complete applicatie), ‘package’ (een ‘plugin’ voor Laravel) of ‘plugin’ (voor WordPress).

Vervolgens krijg je een lange lijst met genummerde vragen om de specificaties verder te verdiepen. Dit is omdat ik nadrukkelijk heb aangegeven om vragen te stellen. En hoe minder je hebt gespecificeerd, hoe meer en hoe meer gedetailleerde vragen er gesteld zullen worden. Op dit moment gebruik ik hiervoor het liefst het model 5.6 sol met een ‘hoog’ redeneringsniveau. Dat is een relatief ‘dure’ oplossing, maar je krijgt hierdoor sterke specificaties, die het werk tijdens het coderen, wat meer tijd kost, makkelijker zal maken, en daarmee goedkoper. Door een ‘duur’ model te gebruiken in de voorbereidingen van het project, bespaar je uiteindelijk veel geld.

En hier zie je direct al het grote verschil met vibe coding. Want de vragen die gesteld worden gaan onder meer diep de techniek in. Tijdens vibe coding wordt er veel aangenomen door de AI agent zelf. En in die aannames ontstaan de fouten.

Intermezzo: Claude vs Claude… je resultaat is zo goed als je specificaties…

Ik heb enkele weken terug als experiment een eenvoudige ‘todo-lijst’ (zo’n beetje de eerste taak in iedere moderne cursus programmeren) applicatie als ‘vibe’ project in PHP laten bouwen door Claude Code. In een zestal prompts had ik een applicatie, waar iemand bij in kon loggen, zijn eigen to-do items in kon voeren, en de to-do items van andere ingelogde gebruikers kon bekijken, maar niet aanpassen. Precies de door mij gewenste functionaliteit.

Vervolgens in een compleet nieuwe context opnieuw door Claude Code de app laten evalueren op veiligheid, platformonafhankelijkheid snelheid en onderhoudbaarheid. Voor allebei hetzelfde model gebruikt. Het ‘eindrapport’ van Claude Code was vernietigend.

Toen ik ‘Claude de Auditor’ toestemming gaf alles aan te passen, werkte de hele app niet meer.

Begrijpen wat je leest

Zowel Codex (ChatGPT) als Claude Code kunnen gebruikt worden om een complete app te genereren. Maar het resultaat is sterk afhankelijk van de specificaties. Ben je niet in staat -omdat je de vragen die de AI-agent je stelt niet begrijpt- de juiste specificaties te geven, dan bouwt je agent een product wat uiteindelijk niet onderhoudbaar is.

Ontdekken wat je mist

Mijn eigen ervaring is dat het opstellen van een goed definitie document voor een software toepassing een behoorlijke klus is. En zelfs wanneer je een na enkele intensieve sessies met de klant tot een document komt, je in de praktijk altijd ontdekt, dat er iets mist en in de ontwikkelfase nog zaken aan moet passen.

Door de AI-Agent te instrueren vragen te stellen, zal dit ook gebeuren. Hierdoor kom je, ook wanneer je heel ervaren bent, toch achter, dat je zaken in de specificaties hebt gemist. Maar door de vragen te beantwoorden die je AI-agent je stelt, krijgt deze agent meer informatie, wat weer tot nieuwe vragen gaan leiden.

Om je een idee te geven, mijn ‘ingangsdocument’ in MD formaat was 250 regels. Na drie vragenrondes, waarin iets meer dan 100 vragen werden gesteld, kreeg ik een eindresultaat van bijna 2400 regels ‘projectspecificatie’.

Het hele proces heeft mij ongeveer 4 uur gekost, waarvan ik de meeste tijd bezig was met het produceren van mijn 250 regels ‘input’. Zou ik zelf een dergelijk gedetailleerd document moeten schrijven als mijn AI-agent deed, dan zou ik er een dag of twee mee bezig zijn geweest.

En behalve de zaken waar ik niet gelijk aan dacht, veel tijd is ook bespaard, omdat wanneer ik in de specs het had over bepaalde tabellen, de agent kwam met een voorstel voor de structuur van die tabellen, over procedures met betrekking tot de flow van die procedures.

Wanneer de specs klaar zijn

Mijn project was voornamelijk een ‘eigen’ project, het was niet voor een opdrachtgever bedoeld (maar binnenkort hoor je er meer over, want het wordt wel een nieuw product van WordXPression). Ik had nu dus een document in MD formaat, wat begrepen wordt door andere agents. Het mooie van MD formaat is overigens ook, dat je het in bijna iedere tekstverwerker kan importeren.

Maar een technisch document van tientallen pagina’s is niet iets wat je voor wilt leggen aan een klant.

Dus mijn vervolgstap was -puur als test- om een ‘Executive Excerpt’ van het document te maken. Dus een soort ‘samenvatting voor niet-technische mensen’. Na een aantal inleidende vragen, kreeg ik een keurig document van drie pagina’s, wat prima geschikt is om aan een klant voor te leggen als een ‘begrijpbaar communicatiedocument’.

Je project aanmaken

Het is nu tijd om serieus te worden. Wanneer je gebruik maakt van een moderne IDE (Integrated Development Environment), dan heb je de mogelijkheid om een project aan te maken. En wanneer je ook nog eens werkt met een framework als Laravel, NodeJS, NEXT, Rails, Django of React, of een CMS als WordPress met een duidelijke API, dan beschik je ook over een referentie raamwerk met betrekking tot code standaarden.

Even als aparte tip voor WordPress: Ontwikkel je een thema voor WordPress, dan is je project directory niet de WordPress document root directory (vooral belangrijk, wanneer je met Bedrock werkt) maar de directory waarin de plugin geplaatst zal worden. Dus wanneer de plugin ‘mijn-superkoele-plugin’ gaat heten, is je project directory ‘mijn-superkoele-plugin’ onder de geconfigureerde wp-content/plugins directory.

Instructies met betrekking tot de te gebruiken standaarden

Een AI agent gaat op zoek naar bronnen op het Internet, wanneer je vraagt iets te doen. En hoewel de AI-modellen inmiddels goed getraind zijn, en minder ‘rubbish’ bronnen gebruiken dan voorheen, kan het nog steeds voorkomen, dat er uit verouderde bronnen of compleet onzinnige bronnen wordt geput.

Dit kan je voorkomen, door expliciet te vertellen binnen je project context, welke bronnen gebruikt moeten worden.

Maar hoe weet jij welke bronnen dat zijn? Gelukkig hebben de makers van de verschillende Generatieve AI systemen over nagedacht en zijn gekomen met een standaard: Het MCP, ‘Model-Context Protocol‘.

Natuurlijk kun je ook verwijzen naar de officiële documentatie van je programmeertaal, het gebruikte framework en eventuele packages of plugins. Maar het voordeel van een MCP server, is dat deze altijd de meest recente standaard zal gebruiken. En nog veel belangrijker: In officiële documentatie wordt vaak veel uitgelegd. Een MCP server zal de informatie op een meer compacte en meer gestructureerde wijze aanbieden. Per slot van rekening is de informatie die een AI-Agent gelijktijdig kan verwerken behoorlijk beperkt.

Waar vind ik die MCP servers?

Het is natuurlijk leuk, dat die MCP servers er zijn, maar waar vind je die? Vaak zal er op de site van je taal- of framework ergens naar ‘Mijn-taal-of-framework en AI’ worden verwezen. Als dat niet zo is, dan is er in ieder geval een site die naar meer dan tienduizend MCP servers, naar onderwerp gecategoriseerd, verwijst.

Kopieer de links die voor jou belangrijk zijn, en neem deze op in je projectbeschrijving.

Twee onmisbare tools voor de veiligheid van je project

Je bent nu bijna klaar. Maar om je project tot een goed einde te brengen heb je een tweetal ‘hardlopers’ nodig in je team, die eigenlijk constant voor je aan het werk zijn. Git – een versiebeheersysteem – en een testsuite voor jouw favoriete programmeertaal. In PHP zijn dat PHPUnit of Pest. Waarbij mijn persoonlijke favoriet ‘Pest’ is.

Wanneer een AI-agent zelfstandig bestanden kan toevoegen, wijzigen en verwijderen, is goed versiebeheer onmisbaar.

Git maakt zichtbaar welke wijzigingen zijn uitgevoerd en biedt de mogelijkheid om die wijzigingen terug te draaien. Zonder versiebeheer kan een agent tientallen bestanden aanpassen voordat duidelijk wordt dat de gekozen richting verkeerd was.

Een goed Git-proces helpt om het werk controleerbaar te houden.

Dat betekent onder meer dat wijzigingen in logische stappen worden uitgevoerd. Laat een agent niet in één keer de authenticatie, database, gebruikersinterface en betaalintegratie aanpassen. Verdeel het werk in kleine, afgebakende opdrachten.

Na iedere stap kan de ontwikkelaar:

1. de wijzigingen bekijken;
2. de applicatie uitvoeren;
3. tests draaien;
4. de code beoordelen;
5. een commit maken.

Hierdoor ontstaat een geschiedenis van begrijpelijke wijzigingen. Wanneer later een fout wordt ontdekt, is beter te achterhalen wanneer en waarom deze is ontstaan.

Ook branches blijven belangrijk. Een experimentele oplossing kan op een aparte branch worden uitgewerkt zonder de stabiele versie van de applicatie direct te beïnvloeden.

AI versnelt het schrijven van code. Git voorkomt dat die snelheid verandert in chaos.

Laat AI nooit ongecontroleerd doorwerken

Sommige coding agents kunnen langere tijd zelfstandig taken uitvoeren. Ze analyseren de codebase, maken een plan, wijzigen bestanden, voeren commando’s uit en proberen fouten zelf te herstellen.

Dat is krachtig, maar brengt ook risico’s met zich mee.

Een agent kan bijvoorbeeld:

• een bestaande functie onbedoeld verwijderen;
• configuratiebestanden overschrijven;
• een databasecommando uitvoeren;
• afhankelijkheden installeren die niet gewenst zijn;
• veiligheidscontroles vereenvoudigen;
• tests aanpassen zodat foutieve code alsnog slaagt;
• een tijdelijke oplossing als definitieve oplossing presenteren.

Daarom is het verstandig om vooraf grenzen te bepalen. Welke bestanden mag de agent aanpassen? Welke commando’s mag hij uitvoeren? Mag hij dependencies installeren? Mag hij database­migraties uitvoeren? Mag hij bestaande tests wijzigen?

Hoe groter de mogelijke gevolgen, hoe meer menselijke controle nodig is.

Tests zijn belangrijker dan ooit

AI kan code genereren die er professioneel uitziet en zelfs zonder foutmeldingen wordt uitgevoerd. Dat zegt nog weinig over de functionele juistheid.

De enige betrouwbare manier om vast te stellen of software doet wat zij moet doen, is testen.

Bij AI-geassisteerde ontwikkeling zijn geautomatiseerde tests extra belangrijk. De hoeveelheid geproduceerde code kan groter worden, waardoor handmatige controle alleen niet meer voldoende is.

Afhankelijk van het project kunnen verschillende soorten tests worden gebruikt:

Unit tests

Unit tests controleren kleine, afgebakende onderdelen van de applicatie. Bijvoorbeeld een berekening, een validatieregel of een methode die een status bepaalt.

Integratietests

Integratietests controleren of verschillende onderdelen correct samenwerken. Denk aan een controller die gegevens opslaat via een service en vervolgens een notificatie verstuurt.

Featuretests

Featuretests testen een complete functie vanuit het perspectief van de applicatie. Kan een gebruiker zich aanmelden? Kan hij een bestelling plaatsen? Wordt een onbevoegde gebruiker correct geweigerd?

End-to-endtests

End-to-endtests bootsen het gedrag van een echte gebruiker na. Een test opent bijvoorbeeld de browser, vult een formulier in, klikt op knoppen en controleert het resultaat.

Statische analyse

Tools voor statische analyse kunnen fouten ontdekken zonder de code uit te voeren. Ze controleren bijvoorbeeld types, onbereikbare code, onjuiste method calls en afwijkingen van afgesproken programmeerregels.

AI kan helpen bij het schrijven van tests, maar ook hier geldt dat de tests zelf gecontroleerd moeten worden. Een verkeerde test kan ten onrechte bevestigen dat de implementatie correct is.

Een test die alleen controleert of een functie een waarde retourneert, zegt bijvoorbeeld weinig wanneer niet wordt gecontroleerd of dit de juiste waarde is.

Test niet alleen de normale situatie

Door AI gegenereerde code werkt vaak goed voor het meest voor de hand liggende scenario. Problemen ontstaan vooral bij uitzonderingen.

Wat gebeurt er wanneer:

• een verplicht veld ontbreekt;
• een gebruiker geen toestemming heeft;
• een API tijdelijk niet beschikbaar is;
• dezelfde aanvraag twee keer wordt verstuurd;
• een betaling wel is uitgevoerd maar de terugkoppeling mislukt;
• een record ondertussen door iemand anders is gewijzigd;
• een bestand te groot of beschadigd is;
• een datum in een andere tijdzone valt;
• er geen resultaten beschikbaar zijn?

Een goede specificatie benoemt dergelijke situaties. Goede tests leggen vast wat de applicatie in elk van die gevallen moet doen.

De ontwikkelaar hoeft daardoor niet alleen te controleren of de zogenaamde happy flow werkt, maar ook of het systeem zich voorspelbaar gedraagt wanneer iets misgaat.

Omdat je in een AI traject vaak zal moeten testen, is het goed om goede tests voor te bereiden. Het voordeel is, dat het programmeren van tests vaak saai werk is, en daardoor juist iets wat een AI-agent makkelijk kan doen. Maar vergeet niet iedere test te onderzoeken op juistheid.

Houd opdrachten klein en controleerbaar

Een veelgebruikte aanpak is om een grote opdracht in één keer aan de AI te geven:

Bouw het volledige klantportaal.

Dat levert meestal een grote hoeveelheid code op die moeilijk te beoordelen is. Bovendien kan een verkeerde aanname op één plek doorwerken in tientallen bestanden.

Een betere werkwijze is incrementeel.

Begin bijvoorbeeld met:

1. het datamodel;
2. de migraties;
3. de modellen en relaties;
4. autorisatie;
5. de eerste service;
6. tests voor die service;
7. de gebruikersinterface;
8. integratie met bestaande onderdelen.

Na iedere stap wordt gecontroleerd of de gekozen richting nog klopt.

Deze aanpak is niet alleen veiliger, maar vaak ook sneller. Fouten worden ontdekt voordat ze zich door het hele project verspreiden.

AI-code moet gewone code blijven

Door AI geschreven code verdient geen aparte status. Het is gewoon onderdeel van de applicatie en moet aan dezelfde eisen voldoen als handmatig geschreven code.

Dat betekent dat de code:

• leesbaar moet zijn;
• duidelijke namen moet gebruiken;
• geen onnodige duplicatie bevat;
• aansluit op bestaande standaarden;
• testbaar is;
• goed wordt gedocumenteerd waar dat nodig is;
• geen verborgen afhankelijkheden introduceert;
• veilig omgaat met invoer en gegevens.

De vraag wie de code heeft geschreven is uiteindelijk minder belangrijk dan de vraag of een andere ontwikkelaar de code over een half jaar nog kan begrijpen en aanpassen.

Een coding agent kan een functie in enkele seconden schrijven. Onderhoud aan die functie kan jaren later nog steeds tijd kosten.

Beveiliging blijft mensenwerk

AI kan bekende beveiligingspatronen toepassen, maar garandeert geen veilige software.

Een agent kan bijvoorbeeld vergeten om:

• invoer correct te valideren;
• databasequeries veilig uit te voeren;
• rechten op recordniveau te controleren;
• gevoelige gegevens uit logs te houden;
• rate limiting toe te passen;
• bestanden op type en inhoud te controleren;
• secrets buiten de repository op te slaan;
• foutmeldingen voor eindgebruikers te beperken.

Bovendien kan een oplossing technisch veilig lijken, terwijl zij niet aansluit op de specifieke risico’s van de applicatie.

Een openbaar blogplatform heeft andere beveiligingsrisico’s dan een medisch dossier, financieel systeem of multi-tenant SaaS-platform.

Beveiliging begint daarom met het herkennen van waardevolle gegevens, mogelijke aanvallers en zwakke plekken. AI kan helpen bij een security review, maar vervangt geen doordacht beveiligingsmodel.

Van vibe coding naar professioneel ontwikkelen

De term vibe coding wordt vaak gebruikt voor een manier van werken waarbij iemand in gewone taal beschrijft wat er moet gebeuren en de gegenereerde code grotendeels zonder diepgaande controle accepteert.

Voor een prototype of experiment kan dat nuttig zijn. Een idee kan snel zichtbaar en testbaar worden gemaakt.

Maar zodra een applicatie echte gebruikers, gevoelige gegevens, betalingen of bedrijfsprocessen ondersteunt, is alleen op gevoel werken onvoldoende.

Professionele AI-geassisteerde ontwikkeling vraagt om discipline:

• duidelijke doelen;
• een technische specificatie;
• kleine ontwikkelstappen;
• versiebeheer;
• code reviews;
• geautomatiseerde tests;
• beveiligingscontroles;
• documentatie;
• een gecontroleerd deploymentproces.

AI maakt deze onderdelen niet minder belangrijk. Doordat ontwikkeling sneller gaat, moeten kwaliteitscontroles juist gelijke tred houden.

De beste resultaten ontstaan uit samenwerking

AI-geassisteerde softwareontwikkeling werkt het beste wanneer mens en machine ieder worden ingezet voor hun sterke punten.

De AI is sterk in:

• snel veel informatie verwerken;
• patronen herkennen;
• repetitieve code produceren;
• alternatieven voorstellen;
• documentatie samenvatten;
• foutmeldingen analyseren.

De ontwikkelaar is nodig voor:

• het begrijpen van de werkelijke behoefte;
• het afwegen van belangen;
• het maken van architectuurkeuzes;
• het herkennen van onjuiste aannames;
• het beoordelen van risico’s;
• het bewaken van samenhang;
• het nemen van verantwoordelijkheid.

De vraag is daarom niet of AI de ontwikkelaar vervangt. De interessantere vraag is hoe ontwikkelaars AI kunnen inzetten zonder de controle over het ontwikkelproces te verliezen.

Conclusie

AI kan softwareontwikkeling aanzienlijk versnellen. Een coding agent kan helpen bij het schrijven, analyseren, testen en verbeteren van code. Daardoor wordt het mogelijk om ideeën sneller uit te werken en meer tijd te besteden aan de onderdelen die werkelijk denkwerk vragen.

Maar snelheid is alleen waardevol wanneer de ontwikkeling beheersbaar blijft.

Zonder een duidelijke technische specificatie weet de AI niet precies wat er gebouwd moet worden. Zonder Git zijn wijzigingen moeilijk te controleren en terug te draaien. Zonder tests is niet betrouwbaar vast te stellen of de applicatie correct blijft werken.

Professionele AI-geassisteerde softwareontwikkeling begint daarom niet met de perfecte prompt. Het begint met een goed begrip van het probleem, een doordachte werkwijze en de bereidheid om iedere gegenereerde oplossing kritisch te blijven beoordelen.

Dat is ook het uitgangspunt van mijn cursus over AI-geassisteerde software ontwikkeling. Deelnemers werken daarin niet aan een voorgeschreven voorbeeldapplicatie, maar aan een eigen software-idee. Niet om zoveel mogelijk code te laten genereren, maar om te leren hoe je met AI sneller kunt ontwikkelen zonder grip te verliezen op architectuur, kwaliteit en veiligheid.