Een internationaal onderzoeksteam laat zien dat een team van AI‑agenten vrijwel zelfstandig een werkende C‑compiler kan bouwen. In het experiment werken meerdere software‑agenten samen om broncode om te zetten naar uitvoerbare programma’s. Het project is bedoeld om te testen hoe ver autonome code‑systemen al zijn. De aanpak is relevant voor de Europese AI‑verordening en voor overheden die ontwikkeltools inkopen.
AI-agenten nemen bouw over
De onderzoekers gebruiken een groep AI‑agenten, die elk een afgebakende taak krijgen en met elkaar overleggen. Een AI‑agent is een stukje software dat zelfstandig doelen plant en stappen uitvoert met behulp van een taalmodel. Denk aan rollen als planner, code‑schrijver, tester en debugger. Samen zetten zij specificaties om in werkende broncode.
Het team richtte de agenten in als een pijplijn met controles na elke stap. Bij fouten start de tester een terugkoppeling en vraagt de debugger om een gerichte wijziging. Zo ontstaat een iteratief proces met kleine, verifieerbare verbeteringen. Dit beperkt het risico op grote, onopgemerkte regressies.
De coördinatie tussen agenten gebeurt met eenvoudige regels en automatisch gegenereerde takenlijsten. Elk voorstel moet langs unit‑tests en voorbeeldprogramma’s. Lukt dat niet, dan herhalen de agenten de cyclus met aangepaste instructies. Zo groeit de compiler stap voor stap in functionaliteit.
Een compiler zet broncode om in machinetaal, zodat een computer het programma kan uitvoeren.
Functioneel, maar nog beperkt
De resulterende compiler kan eenvoudige C‑programma’s vertalen en uitvoeren in een gecontroleerde omgeving. Basisfunctionaliteit zoals een parser (leest en controleert code) en codegenerator (maakt uitvoerbare instructies) is aanwezig. Ook zijn er elementaire foutmeldingen, zodat gebruikers zien waar het misgaat. Dit maakt het systeem bruikbaar voor demonstraties en lesdoelen.
Toch ontbreekt nog veel dat ontwikkelaars in productie nodig hebben. Optimalisaties die code sneller of zuiniger maken zijn minimaal of afwezig. Dekking van de volledige C‑standaard is niet gegarandeerd. Randgevallen en complexe bibliotheken leveren nog foutmeldingen of onjuiste uitvoer op.
De stabiliteit hangt bovendien af van de kwaliteit van de testset en de promptinstructies. Zonder goede tests accepteren de agenten sneller zwakke oplossingen. Herhaalbaarheid kan variëren wanneer modellen of instellingen veranderen. Daarom is versiebeheer en vastleggen van alle stappen cruciaal.
Techniek begrijpelijk gemaakt
De bouwblokken volgen de klassieke compiler‑keten in eenvoudige vorm. Eerst zet een lexer tekst om in tokens, kleine betekenisvolle stukjes code; daarna maakt een parser er een boomstructuur van. Een semantische controle kijkt of types en regels kloppen. Tot slot maakt de codegenerator instructies die de machine kan uitvoeren.
De AI‑agenten verdelen deze stappen en valideren ze met tests en kleine voorbeeldjes. Waar een mens normaal handmatig debugt, genereren de agenten patch‑voorstellen en testen die direct. Dit versnelt de cyclus van fout vinden naar oplossing. De mens houdt toezicht en grijpt in bij hardnekkige fouten.
Voor wie de termen nieuw zijn: een parser leest structuur, een optimizer verbetert prestaties, en een backend maakt machine‑instructies voor een doelsysteem. In dit project ligt de nadruk op parser en eenvoudige backend. Een volwaardige optimizer kost veel kennis en tijd. Dat verklaart waarom prestaties nog achterblijven bij gevestigde tools als GCC of Clang.
Gevolgen voor ontwikkelaars
Autonome code‑systemen kunnen boilerplate en repetitieve klussen uit handen nemen. Teams kunnen sneller een prototype voor een domeinspecifieke taal opzetten. Dat is handig in onderwijs, onderzoek en embedded projecten. Tegelijk blijft menselijke code‑review nodig om kwaliteit en veiligheid te borgen.
Er zijn veiligheidsrisico’s als agenten code uit externe bronnen overnemen. Onbedoelde kwetsbaarheden of licentieproblemen kunnen zo binnensluipen. Een Software Bill of Materials (SBOM) en automatische beveiligingstests helpen dit te beperken. Organisaties doen er goed aan strikte policies voor AI‑gegenereerde code vast te leggen.
Voor open‑source gemeenschappen is transparantie belangrijk. Deel daarom testsets, prompts en gegenereerde patches, zodat anderen werk kunnen nakijken. Koppeling met bestaande toolchains en test‑suites vergroot de betrouwbaarheid. Zo ontstaat een gemeenschappelijke basis in plaats van losse experimenten.
Europese regels raken ontwikkeltools
Onder de Europese AI‑verordening (AI Act) vallen generatieve modellen als algemene‑doel AI (GPAI) met transparantie‑eisen. Wie AI‑agenten als ontwikkeltool aanbiedt, moet documentatie, evaluaties en gebruiksrestricties duidelijk maken. Voor overheden en publieke instellingen speelt ook inkoopverantwoordelijkheid. Dit raakt de “Europese AI‑verordening gevolgen overheid” direct.
De AVG is hier meestal beperkt van toepassing, omdat er weinig persoonsgegevens worden verwerkt. Toch geldt dataminimalisatie en beveiliging altijd. Logbestanden met voorbeelddata of gebruikerscode kunnen vertrouwelijke informatie bevatten. Versleuteling en strikte toegang horen daarom standaard te zijn.
Daarnaast zijn NIS2 en de Cyber Resilience Act (CRA) relevant voor software in kritieke diensten en producten. Wie een AI‑gegenereerde compiler in de keten gebruikt, moet aantonen dat deze veilig en onderhoudbaar is. Denk aan beveiligingsupdates, kwetsbaarheidbeheer en traceerbaarheid. Dit geldt ook voor Nederlandse overheden en vitale sectoren.
Wat dit kan veranderen
Als deze aanpak doorzet, worden compilers en andere ontwikkeltools sneller op maat te maken. Onderwijs in Nederland en België kan hiermee studenten laten oefenen met echte toolchains. Met sandboxing en goede tests is het risico beheersbaar. Zo leren studenten zowel de theorie als de praktijk van compilerbouw.
Voor bedrijven opent dit de deur naar snellere experimenten met domeinspecifieke talen. Denk aan industrie, zorg of mobiliteit, waar kleine talen processen beschrijven. Snellere iteratie kan de time‑to‑market verkorten. De laatste kwaliteitsstap blijft wel mensenwerk.
Op korte termijn is de boodschap nuchter: het werkt, maar het is niet klaar voor productie. Op middellange termijn kan integratie met bestaande projecten als LLVM of GCC‑frontends de bruikbaarheid vergroten. Open documentatie en reproduceerbare evaluaties worden dan doorslaggevend. Dat bepaalt of dit meer is dan een knap experiment.
