AI in R&D wordt vaak gepresenteerd als een technologie die softwareontwikkeling radicaal verandert: tien keer sneller ontwikkelen, teams vervangen en traditionele processen overbodig maken. Maar binnen echte R&D-teams – met deadlines, legacy, domeinlogica en technische schuld – ligt het meer genuanceerd. De vraag is in mijn ogen niet of AI alles kan overnemen, maar waar het daadwerkelijk waarde toevoegt zonder de kwaliteitsstandaarden te ondermijnen.
AI versnelt…vooral op plekken waar weinig mensen kijken
De grootste versnelling die ik in de praktijk zie, zit niet in het autonoom bouwen van complexe modules maar in de minder zichtbare stappen van het proces. Prototypes ontstaan in dagen in plaats van weken, wat helpt om keuzes eerder te valideren zonder meteen robuuste code te verwachten. Tests worden sneller gegenereerd en gecontroleerd, waardoor regressies en herhaalwerk afnemen. En AI helpt ontwikkelaars sneller door grote, ingewikkelde codebases heen, zodat context en afhankelijkheden eerder duidelijk worden.
Het zijn geen showcasevoorbeelden, maar het zijn wel de plekken waar R&D-teams vandaag al structureel tijd winnen en ruimte creëren om zich te focussen op echt ontwerp- en integratiewerk.
En toch loopt AI nog regelmatig tegen de muur
Wat de grooste valkuil is? AI levert vaak iets wat eruitziet als software, maar dat betekent niet dat het geschikt is voor productie. Het verschil tussen “het werkt” en “dit kan live” blijft groot. Zeker in omgevingen met legacy – van grote codebases tot jaren aan domeinregels en historie – blijkt AI vooralsnog beperkt autonoom effectief.
Daarom werkt een incrementele aanpak hier het best. Eén enkele testset, één module of één repeterende taak biedt genoeg speelruimte om stabiliteit op te bouwen. Pas wanneer AI daar betrouwbaar presteert, is uitbreiding zinvol. Zo blijft kwaliteit leidend, en voorkom je dat prototypes worden aangezien voor productierijpe oplossingen.
De rol van developers verandert eerder dan hun werk
AI verandert in deze context vooral waar de waarde van developers ligt. Niet in elke regel code zelf produceren, maar in begrijpen wat er moet gebeuren, de kwaliteit van gegenereerde voorstellen beoordelen en meerdere tools tegelijk kunnen aansturen. Feitelijk verschuift hun rol meer naar die van product owner: domeinkennis en architecturale kaders worden belangrijker, omdat AI zonder duidelijke richting verkeerde aannames maakt.
AI gedraagt zich daarin als een extreem snelle junior: nuttig, maar niet zelfstandig. Teams die deze realiteit accepteren, bouwen sneller en consistenter dan teams die verwachten dat AI het werk van een senior vervangt.
R&D-teams gaan er anders uitzien
Naarmate agents meer onderdelen van het ontwikkelproces ondersteunen, verschuift wel de samenstelling en dynamiek van teams. Developers worden regisseurs van hun eigen agents; debugging verschuift richting monitoring; en onderhoud verandert in een proces waarin problemen vroegtijdig worden opgemerkt en voorbereid voordat support ze signaleert.
Moderne tooling maakt het bovendien mogelijk om agents direct te laten reageren op logs en observability-data. Daardoor ontstaat een workflow waarin handmatig speurwerk afneemt en tijd vrijkomt voor domeinontwerp, integraties en structurele verbeteringen.
De zorg dat AI leidt tot kleinere ontwikkelteams komt in de praktijk (nog) niet uit, maar zorgt dus wel voor duidelijke verschuivingen:
- repetitief test- en bugwerk verdwijnt uit de dagelijkse routine,
- en ontwikkelaars besteden meer tijd aan integraties, ontwerpkeuzes en klantwaarde.
Is AI dan een revolutie of een luchtkasteel?
AI is revolutionair waar het snelheid, validatie en automatisering toevoegt in ondersteunende processen. Maar het is een luchtkasteel zodra je verwacht dat het zelfstandig legacy herschrijft, prototypes productie-klaar maakt of senior engineering judgment vervangt.
AI verandert de manier waarop we software bouwen, maar niet de principes waarmee we kwaliteit borgen. Teams die dat onderscheid scherp houden, benutten de voordelen zonder te vervallen in overschatting.
Veelgestelde vragen
Legacy-systemen bevatten jaren aan domeinregels, uitzonderingen en impliciete logica die niet in code staat maar in de hoofden van ontwikkelaars. AI kan daar wel onderdelen van analyseren, maar niet automatisch de context reconstrueren. Daarom werkt AI uitstekend voor gerichte taken in legacy, zoals tests genereren, refactorvoorstellen, bugdetectie. Maar niet voor grootschalige autonome herbouw. Daar heb je menselijk denkwerk bij nodig.
De organisaties die het goed doen hebben in elk geval deze vijf dingen op orde:
– Guardrails: duidelijke grenzen aan gedrag en output.
– Code review: AI-gegenereerde code gaat nooit ongezien naar productie.
– Logging & metrics: alles is traceerbaar.
– Fallbacks: bij twijfel schakelt het systeem over op veilige paden.
– Monitoring: het gedrag van AI wordt continu geëvalueerd.
AI verschuift waar developers waarde leveren. Taken die voorspelbaar, repetitief of laagwaardig zijn verdwijnen. Wat overblijft is het werk dat altijd al bepalend was voor kwaliteit: domeinlogica begrijpen, structurele keuzes maken, beoordelen wat een agent oplevert, borgen dat het systeem correct, veilig en uitlegbaar blijft. Developers die systemen begrijpen en agents kunnen sturen, worden belangrijker dan ooit.
De juiste start is een enkele, afgebakende use case waarin je de volledige lifecycle kunt oefenen: van promptbeheer tot evaluatie, monitoring, explainability en fallback-mechanismen. De manier waarop je begint bepaalt of je later kunt opschalen zonder de basis opnieuw te moeten bouwen.
