AI technical debt tikt door

Waarom AI technical debt nu relevant is

De rol van AI in development verandert razendsnel. Coding assistants worden steeds vaker aangevuld of vervangen door agents die zelfstandig meerdere stappen doorlopen. Zoals een issue analyseren, verschillende bestanden aanpassen, tests uitvoeren en een pull request voorbereiden.

Sonar publiceerde in september 2026 nieuw onderzoek naar AI technical debt. Eerder onderzoek onder ruim 1.100 developers wees al uit dat 42 procent aangaf dat committed code met hulp van AI tot stand kwam. Terwijl slechts 48 procent die output altijd controleerde voordat deze werd gecommit.

Hoe zorg je dat een agent dezelfde standaarden volgt als het developmentteam? Welke context heeft een agent nodig om goede keuzes te maken? En hoe controleer je almaar grotere hoeveelheden gegenereerde code zonder dat review zelf een bottleneck wordt?

Atlassian meldde deze week dat 94 procent van de engineering leaders in hun onderzoek AI gebruikt, terwijl amper 6 procent systemen heeft ingericht waarmee AI over de volledige software development lifecycle kan worden opgeschaald. Vooral context blijkt daarbij doorslaggevend: een agent moet toegang hebben tot informatie over architectuur, standaarden en eerdere technische beslissingen om binnen een bestaande codebase zelfstandig goede keuzes te kunnen maken.

Architectuur en context voor AI coding agents

De nieuwste coding agents doorgronden een codebase een stuk beter dan eerdere generaties AI coding tools. Agents houden daardoor steeds vaker rekening met bestaande patronen en structuren.

De beschikbare context bepaalt voor een belangrijk deel de kwaliteit van de uitkomst. Veel architectuurkennis ligt verspreid over documentatie, tickets, pull requests, Slack-gesprekken en de hoofden van developers zelf. Een agent die alleen toegang heeft tot de repository, mist een deel van die informatie.

Dat weegt zwaarder naarmate agents meer autonomie krijgen. Een verkeerde keuze in één functie is doorgaans eenvoudig te herstellen. Een structureel verkeerd patroon dat tientallen keren wordt herhaald, kan later aanzienlijk meer werk veroorzaken.

Gartner benoemt dit inmiddels expliciet als ‘architectural technical debt from AI coding agents’. Bewaakt niemand de technische beslissingen, dan draagt intensief gebruik van AI coding agents volgens Gartner rechtstreeks bij aan architecturale schuld.

Architectuur wordt zo, misschien enigszins tegen de verwachting in, weer relevanter door AI. Architectural Decision Records, coding standards, security policies en duidelijke domeingrenzen krijgen daardoor een extra functie. Ze helpen niet alleen developers een systeem te begrijpen, maar kunnen evengoed coding agents richting geven.

Van code review naar verification debt

Een tweede begrip dat opkomt is AI code verification debt. Sonar gebruikt deze term voor het gat tussen de hoeveelheid AI-code die wordt geproduceerd en de hoeveelheid die daadwerkelijk zorgvuldig kan worden gecontroleerd.

Dat gat wordt omvangrijker naarmate agents grotere wijzigingen doorvoeren. Bij een pull request van honderden regels gegenereerde code is nog altijd inzicht nodig in de gevolgen voor product, architectuur en beveiliging.

Code review verandert daarmee mee met AI coding. Handmatige review blijft onmisbaar, terwijl geautomatiseerde kwaliteitscontroles een grotere rol krijgen: static analysis, automatische tests, security checks en quality gates kunnen een deel van de verificatie doorlopend uitvoeren.

Ook de inhoud van reviews verschuift. Wanneer code sneller wordt geproduceerd, wordt het belangrijker om te controleren of een wijziging past binnen de structuur en de uitgangspunten van het product. Een technisch correcte oplossing kan alsnog onnodige complexiteit toevoegen, of bestaande functionaliteit op een nodeloos afwijkende manier implementeren.

Technical debt in de AI-laag zelf

AI technical debt ontstaat ook in producten waarin AI onderdeel is van de functionaliteit zelf. Daar groeit steeds vaker een extra technische laag rond modellen, prompts, context, retrieval, evaluaties en modelproviders.

Die laag ontwikkelt zich doorgaans snel. Een eerste AI-feature begint bijvoorbeeld met één model en een handvol prompts. Later volgen meerdere use cases, fallback-mechanismen, extra databronnen en uiteenlopende modellen. Zonder heldere structuur wordt het steeds lastiger te achterhalen waarom een bepaalde keuze ooit is gemaakt.

Een prompt kan jarenlang meedraaien in productiecode terwijl onduidelijk wordt welke versie bij welke functionaliteit hoort. Een overstap naar een ander model kan bestaande output op onverwachte wijze beïnvloeden. Een RAG-oplossing (AI-technologie die de antwoorden van een groot taalmodel verbetert door te zoeken in je eigen externe bronnen of bedrijfsdata) kan leunen op databronnen waarvan de relevantie of kwaliteit intussen is veranderd.

Ook evaluatie speelt hierin een rol. Bij traditionele software valt een groot deel van de functionaliteit te controleren met vooraf bepaalde testcases. Bij AI-functionaliteit hangt de kwaliteit van output doorgaans af van meerdere factoren tegelijk. Teams hebben daarom evals (evaluatie-frameworks), testdatasets en heldere kwaliteitscriteria nodig om te kunnen beoordelen of een wijziging daadwerkelijk een verbetering oplevert.

Zonder die kennis ontstaat afhankelijkheid van onderdelen die steeds moeilijker te vervangen of aan te passen zijn. Ook dát is, hoe onopvallend ook, een vorm van AI technical debt.

Hoe voorkom je dat AI technical debt zich opstapelt?

Het voorkomen van AI technical debt begint bij dezelfde engineeringprincipes die bij elke softwareontwikkeling gelden. Alleen de toepassing ervan verandert, naarmate agents een groter deel van de code produceren.

• Maak architectuur expliciet. Leg belangrijke technische beslissingen en grenzen binnen het systeem vast op een manier die zowel developers als agents kunnen gebruiken.
• Werk met consistente quality gates. Laat gegenereerde code dezelfde automatische checks doorlopen als code die volledig met de hand is geschreven.
• Beheer context als onderdeel van de developmentomgeving. Bepaal welke informatie een coding agent nodig heeft over het product, de architectuur en de gebruikte standaarden.
• AI-componenten in versiebeheersysteem. Leg vast welke modellen, prompts, databronnen en configuraties bij welke functionaliteit horen.
• Bouw evaluatie in bij AI-functionaliteit. Zorg voor datasets en criteria waarmee veranderingen in output daadwerkelijk te meten zijn.
• Blijf code en architectuur actief onderhouden. Refactoring en het verwijderen van verouderde patronen blijven onderdeel van productontwikkeling.

De inrichting hiervan verschilt uiteraard per product. Een relatief kleine SaaS-applicatie stelt andere eisen dan een bedrijfskritisch platform met talloze integraties, gebruikers en gevoelige data. Naarmate software complexer wordt, weegt technische context en governance rond AI coding steeds zwaarder mee.