In de wereld van moderne software is een nieuw soort werker opgekomen: een kunstmatige intelligentie die zelfstandig code kan schrijven, fouten kan herstellen en programma's kan bouwen. Deze systemen, vaak codingsagenten genoemd, zijn getraind op enorme bibliotheken van door mensen geschreven instructies en hebben een opmerkelijke vaardigheid getoond in algemene programmeertalen zoals Python. Ze kunnen puzzels oplossen die voorheen uren kostten voor menselijke ingenieurs. De echte wereld van zakelijke software is echter zelden zo eenvoudig. Veel van de kritieke infrastructuur die de wereldwijde handel aandrijft, steunt op gespecialiseerde talen die zijn ontworpen voor specifieke industrieën, waar de regels anders zijn, de tools uniek zijn en de belangen groot zijn. Een dergelijke omgeving is de wereld van enterprise resource planning, waar bedrijven alles beheren van voorraad tot salarisadministratie. Hier spreekt de software een taal genaamd AL, een gespecialiseerd dialect dat wordt gebruikt om Microsoft's Business Central-systeem aan te sturen. Jarenlang was het onduidelijk of deze krachtige AI-agenten dit complexe, propriëtaire landschap konden navigeren of dat hun succes in algemene codering een fenomeen was dat vervaagde wanneer het werd geconfronteerd met echte zakelijke beperkingen.

Om deze vraag te beantwoorden, creëerden onderzoekers van Microsoft een nieuwe testomgeving genaamd BC-Bench. Ze hebben geen theoretische puzzel bedacht; in plaats daarvan zijn ze gedoken in de werkelijke, levende code van twee enorme software-repositories die echte bedrijven aandrijven. Uit deze digitale archieven hebben ze zorgvuldig 101 specifieke taken geselecteerd die ingenieurs in het verleden hebben opgelost. Dit waren geen verzonnen voorbeelden, maar echte problemen: een bug die ervoor zorgde dat een klantrecord mislukte, een ontbrekende functie in een verkooprapport, of een test die moest worden geschreven om een fout te vangen. De onderzoekers vroegen vervolgens verschillende van de meest geavanceerde AI-agenten ter wereld om deze zelfde taken uit te voeren. De agenten kregen de oorspronkelijke probleembeschrijving, die soms screenshots van de fout bevatte, en een momentopname van de code zoals die bestond vóór de reparatie. Hun doel was om precies de code-wijzigingen te schrijven die nodig waren om het probleem op te lossen, net zoals een menselijke ingenieur dat zou doen. Het systeem draaide de software vervolgens in een gesimuleerde omgeving om te zien of de nieuwe code het probleem daadwerkelijk oploste zonder iets anders te breken.

De resultaten onthulden een landschap waar de identiteit van het AI-model veel belangrijker was dan de specifieke tool die het gebruikte om het werk te doen. Wanneer de onderzoekers verschillende versies van de agenten vergeleken, ontdekten ze dat de keuze van de onderliggende hersenen — het grote taalmodel — een veel grotere impact had op het succes dan de keuze van de software-wrapper, of "harness", die het begeleidde. Bijvoorbeeld, een van de nieuwste modellen, Claude Opus 4.6, loste bijna 69 procent van de bugfix-taken op wanneer het gekoppeld was aan een standaardtool, terwijl een oudere versie van hetzelfde model slechts ongeveer 58 procent oploste. In tegenstelling hiermee produceerde het wisselen van de tool zelf, terwijl het model hetzelfde bleef, slechts kleine, statistisch insignificante verschillen. Dit suggereert dat voor deze complexe zakelijke taken de intelligentie van het model de primaire drijfveer van succes is, en niet de specifieke interface die het gebruikt om toegang te krijgen tot de code.

Misschien wel de meest opvallende ontdekking was dat verbeteringen die zichtbaar zijn in algemene coderingstests niet automatisch vertalen naar deze gespecialiseerde wereld. In de bredere wereld van software engineering laten nieuwere modellen vaak gestage, voorspelbare winsten zien ten opzichte van hun voorgangers. Toch toonde een model dat onlangs een voorsprong had behaald op algemene benchmarks in deze specifieke zakelijke omgeving niet hetzelfde voordeel. Eén model dat aanzienlijk was verbeterd op algemene taken, presteerde niet beter dan zijn oudere broertje wanneer het werd geconfronteerd met deze zakelijke logica-puzzels. Dit geeft aan dat de vaardigheden die nodig zijn om een generiek Python-script te repareren, niet hetzelfde zijn als die nodig zijn om een financiële berekening in een gespecialiseerd zakelijk systeem te corrigeren. Het gespecialiseerde karakter van de taal, met zijn strikte regels over hoe data stroomt en hoe zakelijke logica wordt gevalideerd, creëert een barrière die algemene training alleen niet gemakkelijk kan overwinnen.

De onderzoekers keken ook nauwgezet naar waarom de agenten faalden wanneer ze dat deden. Ze ontdekten dat de machines zelden faalden omdat ze de software niet konden bouwen of omdat de code niet compileerde; die technische hindernissen werden gemakkelijk overwonnen. In plaats daarvan gingen de fouten bijna altijd over het begrijpen van het probleem. In bijna de helft van de mislukte pogingen keek de agent naar het verkeerde deel van de code, waarbij bestanden werden bewerkt die niets met de fout te maken hadden. In een andere grote groep fouten vond de agent het juiste bestand en het juiste gedeelte van de code, maar paste toch de verkeerde logica toe, waarbij een oplossing werd geïmplementeerd die er correct uitzag maar de zakelijke regel niet daadwerkelijk oploste. Een agent kon bijvoorbeeld correct identificeren dat een klantordernummer ontbrak, maar vervolgens code schrijven die het verkeerde type nummer toewees, waardoor het systeem defect bleef. Deze fouten suggereren dat de agenten moeite hebben met het navigeren door het diepe, onderling verbonden web van zakelijke regels die definiëren hoe een bedrijf opereert, waarbij ze vaak de subtiele context missen die een menselijke ingenieur onmiddellijk zou begrijpen.

De complexiteit van de taak speelde ook een beslissende rol. Wanneer de reparatie slechts één bestand of een klein aantal regels vereiste, waren de agenten vrij succesvol. Echter, zodra de oplossing vereiste om meerdere bestanden te wijzigen of meer dan een paar dozijn regels code te schrijven, daalde het succespercentage scherp. Deze daling was dramatisch, waarbij de nauwkeurigheid met meer dan twintig procentpunten afnam wanneer de taak meer dan één bestand betrof. Het lijkt erop dat hoewel deze agenten kleine, geïsoleerde reparaties kunnen afhandelen, ze nog steeds moeite hebben met het coördineren van wijzigingen over een groot, onderling verbonden systeem. Bovendien deed het type zakelijk gebied ertoe; de agenten waren succesvoller in het oplossen van problemen in voorraadbeheer dan in magazijnlogistiek, wat suggereert dat hun trainingsdata in sommige zakelijke domeinen rijker was dan in andere.

De studie concludeert dat hoewel kunstmatige intelligentie ongelooflijke stappen heeft gezet in algemene codering, de weg naar volledig autonome engineering in gespecialiseerde zakelijke omgevingen nog niet duidelijk is. De tools bestaan, en de modellen zijn krachtig, maar de kloof tussen algemene capaciteit en domeinspecifieke beheersing blijft groot. De onderzoekers benadrukken dat de industrie, om vooruit te komen, zich moet richten op deze gespecialiseerde benchmarks in plaats van te vertrouwen op algemene tests. Ze wijzen er ook op dat de huidige beperkingen niet alleen gaan over ruwe intelligentie, maar over het vermogen om context te begrijpen, complexe codebases te navigeren en de juiste zakelijke logica toe te passen. Naarmate deze systemen evolueren, is de hoop dat ze uiteindelijk de complexe regels van zakelijke software zullen leren navigeren met dezelfde gemak waarmee ze nu algemene programmering tonen, maar voor nu blijft de menselijke ingenieur essentieel om hen door de complexiteit van de echte wereld te leiden.