AI-tools voor developers zijn pas het begin

De echte uitdaging is aantoonbare impact op software delivery.

AI-tools voor softwareontwikkeling worden in hoog tempo onderdeel van het dagelijkse werk. Bij veel organisaties heeft de eerste fase van adoptie inmiddels plaatsgevonden: developers hebben toegang tot tools als GitHub Copilot, Cursor of Claude Code.

Op individueel niveau kunnen de voordelen heel concreet zijn. Developers gebruiken AI om tests te genereren, onbekende codebases sneller te doorgronden, documentatie op te stellen of repetitief werk te automatiseren. Early adopters kunnen vaak duidelijk aanwijzen welke taken nu aanzienlijk minder tijd kosten.

Voor CIO’s, CTO’s en engineering leads vertellen die voorbeelden alleen niet het hele verhaal. Uiteindelijk moet de investering ook op team- en organisatieniveau zichtbaar worden: in meer ontwikkelcapaciteit, betere softwarekwaliteit, snellere delivery of meer tijd voor complex ontwikkelwerk. Dat is een stuk lastiger vast te stellen dan simpelweg kijken hoeveel developers een AI-tool gebruiken.

Individuele productiviteitswinst leidt niet automatisch tot betere software delivery

Softwareontwikkeling is een samenhangend proces. Code moet worden begrepen, gereviewd, getest, geïntegreerd en uitgerold, terwijl teams continu architectuur- en technische keuzes maken. AI kan afzonderlijke activiteiten flink versnellen, maar dat betekent nog niet dat het ontwikkelproces als geheel efficiënter wordt.

Sneller code genereren kan bijvoorbeeld meer werk richting code review verschuiven. AI-gegenereerde tests moeten nog steeds worden beoordeeld op kwaliteit en relevantie. In andere situaties zorgt het verminderen van repetitief werk juist wél voor extra capaciteit binnen het team. Het effect hangt af van waar AI wordt ingezet en wat er vervolgens in de rest van het ontwikkelproces gebeurt.

Alleen adoptie zegt daarom weinig over productiviteit. Interessanter is waar AI het ontwikkelproces als geheel verandert: welke activiteiten minder tijd kosten, of daardoor ergens anders nieuwe knelpunten ontstaan en of de winst uiteindelijk leidt tot snellere delivery, betere kwaliteit of extra capaciteit.

Voor technologieleiders verandert daarmee ook het gesprek over AI-investeringen. De vraag wordt minder hoeveel developers een tool gebruiken en meer welke manieren van werken aantoonbaar bijdragen aan betere engineeringprestaties.

Wat in één team werkt, schaalt niet vanzelf

AI-gebruik ontwikkelt zich binnen teams vaak vanuit de praktijk. Developers proberen verschillende tools en workflows uit en vinden toepassingen die voor hun werk goed werken. Succesvolle werkwijzen blijven daarbij alleen gemakkelijk beperkt tot één developer of team.

De ene developer heeft misschien een effectieve manier gevonden om een legacy-applicatie te doorgronden, terwijl een ander team een sterke workflow heeft ontwikkeld voor testgeneratie of agents inzet voor repetitieve engineeringtaken. Zonder een manier om die ervaringen te vergelijken en te delen, beginnen andere teams vaak opnieuw aan hetzelfde leerproces.

Zo kan er veel AI-activiteit ontstaan, zonder dat de organisatie als geheel even snel meeleert. Er ontstaan verschillende tools en workflows, teams lossen vergelijkbare problemen los van elkaar op en het wordt lastig om onderscheid te maken tussen aanpakken die structureel waarde opleveren en oplossingen die alleen in een specifieke context goed werken.

Het doel is niet om iedere developer op dezelfde manier met AI te laten werken. Wel wil je voorkomen dat ieder team opnieuw moet uitvinden wat werkt. Effectieve workflows kunnen breder worden gedeeld en waar nodig worden vastgelegd in praktische richtlijnen, terwijl teams ruimte houden om nieuwe tools en toepassingen te blijven testen.

Ook toolselectie wordt daardoor genuanceerder. De beste oplossing is niet per definitie één universeel AI-platform, maar ook volledige vrijheid voor ieder team is niet altijd wenselijk. Verschillende tools kunnen geschikt zijn voor verschillende toepassingen. De keuze moet daarom passen bij de ontwikkelomgeving, security-eisen, kosten en vooral de waarde die teams er daadwerkelijk uit halen.

Meer structuur hoeft experimenteren niet in de weg te zitten

Naarmate AI een vast onderdeel wordt van softwareontwikkeling, groeit ook de behoefte aan duidelijke kaders. Dan gaat het niet alleen om wat developers technisch kunnen, maar ook om vragen rond security, privacy, intellectueel eigendom, codekwaliteit en afhankelijkheid van leveranciers.

Te weinig structuur kan zorgen voor onnodige risico’s en versnippering, terwijl te veel centrale sturing juist het experimenteren vertraagt dat nodig is om te ontdekken waar AI waarde toevoegt. Een werkbare aanpak biedt daarom duidelijke kaders voor verantwoord gebruik en voldoende consistentie om succesvolle werkwijzen breder toe te passen, zonder iedere workflow centraal vast te leggen.

Dat is extra belangrijk omdat zowel de technologie als de manier waarop developers ermee werken snel verandert. Wat vandaag logisch is, kan bij nieuwe mogelijkheden of krachtigere tools alweer moeten worden aangepast. Governance moet daarom niet alleen duidelijke kaders bieden, maar ook ruimte laten om te blijven leren.

AI-agents maken een ad-hocaanpak steeds lastiger

Die balans wordt belangrijker naarmate softwareontwikkeling meer agentic wordt.

Coding assistants ondersteunen vooral afzonderlijke activiteiten. AI-agents kunnen steeds grotere reeksen taken overnemen, zoals een codebase verkennen, wijzigingen voorbereiden, tests genereren of documentatie opstellen. Naarmate de omvang van dat werk groeit, raken vragen over toegang, review en verantwoordelijkheid steeds meer verweven met de inrichting van het ontwikkelproces zelf.

Een volledig ad-hocaanpak wordt daardoor moeilijker vol te houden. Organisaties moeten niet alleen weten of een tool veilig gebruikt kan worden, maar ook voor welke activiteiten die geschikt is, waar menselijk oordeel essentieel blijft en wat agentic workflows betekenen voor de rest van het werk.

Een statisch beleid rond de tools van vandaag brengt je daarom maar tot een bepaald punt. Teams hebben een praktische manier nodig om nieuwe mogelijkheden te beoordelen zodra ze ontstaan en te bepalen welke daarvan nuttig en volwassen genoeg zijn om breder toe te passen.

De echte capability is leren wat werkt

Op langere termijn draait het niet om het beheersen van één specifieke AI-tool, maar om het vermogen om betere manieren van werken te blijven vinden, testen en breder toepassen terwijl de technologie zich ontwikkelt.

Dat begint met begrijpen wat developers nu al doen en waar de grootste kansen liggen. Nieuwe werkwijzen kunnen vervolgens worden getest binnen echte projecten en codebases. Zo wordt zichtbaar of ze het werk daadwerkelijk verbeteren of alleen goed presteren in een demo.

Werkwijzen die zich bewijzen, moeten vervolgens hun weg vinden buiten het oorspronkelijke team. Interne experts kunnen collega’s helpen voortbouwen op de kennis die er al is, terwijl een engineering community ruimte biedt om workflows uit te wisselen, nieuwe tools te bespreken en experimenten samen te evalueren. Zo hoeft niet ieder team dezelfde lessen opnieuw te ontdekken en wordt vooruitgang minder afhankelijk van een eenmalige training of een kleine groep early adopters.

Na verloop van tijd bouwt de organisatie zo zelf het vermogen op om nieuwe tooling te beoordelen, bestaande werkwijzen verder te verbeteren en bewuster te bepalen waar verdere investering in AI-assisted software development zinvol is.

Van AI-experimenten naar een nieuwe manier van werken

Dat is ook het uitgangspunt van Yuma’s aanpak voor AI-Assisted Software Development. We werken samen met development teams om te begrijpen hoe AI al wordt gebruikt, waar het concreet waarde toevoegt in het ontwikkelproces en welke tools passen bij de omgeving en doelstellingen van het team.

Die mogelijkheden testen we binnen bestaande projecten en codebases. Developers doen ervaring op door AI toe te passen in hun eigen werk, terwijl werkwijzen die het ontwikkelproces aantoonbaar verbeteren kunnen worden vertaald naar gedeelde workflows en praktische richtlijnen.

Tegelijk bouwen we aan het vermogen om die kennis binnen de organisatie verder te ontwikkelen en te delen. Coaching, interne experts en een actieve engineering community helpen teams om te delen wat werkt, voort te bouwen op elkaars ervaring en hun werkwijze aan te passen wanneer nieuwe tools en mogelijkheden beschikbaar komen.

De focus ligt daarbij op het verbeteren van softwareontwikkeling, niet op meer AI-gebruik als doel op zich. De echte waarde ontstaat wanneer duidelijk wordt waar AI teams effectiever laat werken en die verbeteringen onderdeel worden van hoe software wordt ontwikkeld en opgeleverd.