← Neueste Arbeiten
🤖 AI

BC-Bench: Evaluating Agentic Engineering in a Domain-Specific Language for ERP

Dieses Paper führt BC-Bench ein, einen neuartigen Benchmark bestehend aus 101 realen Aufgaben in der AL-domänenspezifischen Sprache für Microsoft Dynamics 365 Business Central, um zu demonstrieren, dass die Leistung von Agentic Engineering auf allgemeinen Benchmarks nicht zuverlässig auf Enterprise-ERP-Kontexte übertragbar ist, und unterstreicht damit die kritische Notwendigkeit einer domänenspezifischen Evaluierung.

Ursprüngliche Autoren: Haoran Sun, Klaus Marius Hansen

Veröffentlicht 2026-08-24
📖 6 Min. Lesezeit🧠 Tiefgang

Ursprüngliche Autoren: Haoran Sun, Klaus Marius Hansen

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

In der Welt der modernen Software ist eine neue Art von Arbeiter entstanden: eine künstliche Intelligenz, die in der Lage ist, Code zu schreiben, Fehler zu beheben und Programme eigenständig zu erstellen. Diese Systeme, die oft als Coding-Agenten bezeichnet werden, wurden anhand riesiger Bibliotheken menschlich geschriebener Anweisungen trainiert und haben bemerkenswerte Fähigkeiten in allgemeinen Programmiersprachen wie Python bewiesen. Sie können Rätsel lösen, für die Ingenieure einst Stunden brauchten. Doch die reale Welt der Business-Software ist selten so einfach. Ein Großteil der kritischen Infrastruktur, auf der der globale Handel basiert, stützt sich auf spezialisierte Sprachen, die für spezifische Branchen entwickelt wurden, in denen die Regeln anders, die Werkzeuge einzigartig und der Einsatz hoch sind. Eine solche Umgebung ist die Welt der Enterprise-Resource-Planning-Systeme, in der Unternehmen alles von der Lagerhaltung bis zur Gehaltsabrechnung verwalten. Hier spricht die Software eine Sprache namens AL, einen spezialisierten Dialekt, der zur Steuerung von Microsofts Business Central verwendet wird. Jahrelang war unklar, ob diese leistungsstarken KI-Agenten in der Lage wären, diese komplexe, proprietäre Landschaft zu navigieren, oder ob ihr Erfolg in der allgemeinen Programmierung ein Phänomen war, das angesichts realer geschäftlicher Einschränkungen verblasste.

Um diese Frage zu beantworten, schufen Forscher bei Microsoft eine neue Testumgebung namens BC-Bench. Sie erfanden kein theoretisches Rätsel; stattdessen tauchten sie in den tatsächlichen, lebendigen Code von zwei massiven Software-Repositories ein, die echte Unternehmen antreiben. Aus diesen digitalen Archiven wählten sie sorgfältig 101 spezifische Aufgaben aus, die Ingenieure in der Vergangenheit gelöst hatten. Dies waren keine künstlich erstellten Beispiele, sondern echte Probleme: ein Bug, der dazu führte, dass ein Kundendatensatz fehlschlug, ein fehlendes Feature in einem Verkaufsbericht oder ein Test, der geschrieben werden musste, um einen Fehler abzufangen. Die Forscher baten dann einige der weltweit fortschrittlichsten KI-Agenten, dieselben Aufgaben zu versuchen. Den Agenten wurde die ursprüngliche Problembeschreibung übergeben, die teilweise Screenshots des Fehlers enthielt, sowie ein Schnappschuss des Codes, wie er vor der Fehlerbehebung existierte. Ihr Ziel war es, exakt die Codeänderungen zu schreiben, die nötig waren, um das Problem zu lösen, genau wie ein menschlicher Ingenieur es tun würde. Das System ließ die Software anschließend in einer simulierten Umgebung laufen, um zu prüfen, ob der neue Code das Problem tatsächlich behob, ohne etwas anderes zu beschädigen.

Die Ergebnisse offenbarten eine Landschaft, in der die Identität des KI-Modells weitaig entscheidender war als das spezifische Werkzeug, mit dem es die Arbeit ausführte. Als die Forscher verschiedene Versionen der Agenten verglichen, stellten sie fest, dass die Wahl des zugrunde liegenden Gehirns – des Large Language Models – einen viel größeren Einfluss auf den Erfolg hatte als die Wahl des Software-Wrappers oder „Harness“, der es steuerte. Beispielsweise löste eines der neuesten Modelle, Claude Opus 4.6, fast 69 Prozent der Bugfixing-Aufgaben, wenn es mit einem Standardwerkzeug kombiniert wurde, während eine ältere Version desselben Modells nur etwa 58 Prozent löste. Im Gegensatz dazu bewirkte der Austausch des Werkzeugs selbst bei gleichbleibendem Modell nur winzige, statistisch insignifikante Unterschiede. Dies deutet darauf sich, dass für diese komplexen Geschäftsaufgaben die Intelligenz des Modells der primäre Erfolgsfaktor ist, nicht die spezifische Schnittstelle, über die es auf den Code zugreift.

Die vielleicht erstaunlichste Entdeckung war, dass Verbesserungen in allgemeinen Coding-Tests nicht automatisch in diese spezialisierte Welt übertragen werden. In der breiteren Welt des Software-Engineerings zeigen neuere Modelle oft stetige, vorhersehbare Gewinne gegenüber ihren Vorgängern. Doch in dieser spezifischen Geschäftsumgebung zeigte ein Modell, das kürzlich in allgemeinen Benchmarks seine Vorgänger deutlich übertroffen hatte, hier keinen vergleichbaren Vorteil. Ein Modell, das bei allgemeinen Aufgaben signifikante Fortschritte gemacht hatte, schnitt bei diesen geschäftlichen Logikrätseln nicht besser ab als sein älteres Geschwistermodell. Dies deutet darauf hin, dass die Fähigkeiten, die zum Beheben eines generischen Python-Skripts erforderlich sind, nicht dieselben sind, die zur Korrektur einer Finanzberechnung in einem spezialisierten Geschäftssystem benötigt werden. Die spezialisierte Natur der Sprache, mit ihren strengen Regeln darüber, wie Daten fließen und wie die Geschäftslogik validiert wird, schafft eine Barriere, die durch allgemeines Training allein nicht leicht zu überwinden ist.

Die Forscher untersuchten auch genau, warum die Agenten scheiterten, wenn sie es taten. Sie fanden heraus, dass die Maschinen selten deshalb scheiterten, weil sie die Software nicht bauen konnten oder weil der Code nicht kompilierte; diese technischen Hürden wurden leicht überwunden. Stattdessen lagen die Fehler fast immer im Verständnis des Problems. In fast der Hälfte der Fehlversuche betrachtete der Agent den völlig falschen Teil des Codes und bearbeitete Dateien, die nichts mit dem Fehler zu tun hatten. In einer weiteren großen Gruppe von Fehlern fand der Agent zwar die richtige Datei und den richtigen Codeabschnitt, wandte aber dennoch die falsche Logik an und implementierte eine Lösung, die zwar korrekt aussah, aber die Geschäftsregel tatsächlich nicht korrigierte. Beispielsweise konnte ein Agent zwar korrekt identifizieren, dass eine Kundennummer fehlte, schrieb dann aber Code, der eine falsche Art von Nummer zuwies, wodurch das System weiterhin defekt blieb. Diese Fehler legen nahe, dass die Agenten Schwierigkeiten haben, das tiefe, miteinander verbundene Netz der Geschäftsregeln zu navigieren, die den Betrieb eines Unternehmens definieren, wobei sie oft den subtilen Kontext übersehen, den ein menschlicher Ingenieur sofort erfassen würde.

Auch die Komplexität der Aufgabe spielte eine entscheidende Rolle. Wenn die Behebung die Änderung nur einer einzigen Datei oder einer geringen Anzahl von Zeilen erforderte, waren die Agenten recht erfolgreich. Sobald die Lösung jedoch die Modifikation mehrerer Dateien oder das Schreiben von mehr als ein paar Dutzend Zeilen Code erforderte, sank die Erfolgsquote drastisch. Dieser Rückgang war massiv, wobei die Genauigkeit um mehr als zwanzig Prozentpunkte sank, wenn die Aufgabe mehr als eine Datei involvierte. Es scheint, dass diese Agenten zwar kleine, isolierte Reparaturen bewältigen können, aber immer noch Schwierigkeiten haben, Änderungen in einem großen, vernetzten System zu koordinieren. Darüber hinaus spielte die Art des Geschäftsbereichs eine Rolle; die Agenten waren erfolgreicher beim Beheben von Problemen in der Bestandsverwaltung als in der Lagerlogistik, was darauf hindeutet, dass ihre Trainingsdaten in einigen Geschäftsbereichen möglicherweise reicher waren als in anderen.

Die Studie kommt zu dem Schluss, dass die künstliche Intelligenz zwar unglaubliche Fortschritte in der allgemeinen Programmierung gemacht hat, der Weg zu einem vollständig autonomen Engineering in spezialisierten Geschäftsumgebungen jedoch noch nicht klar ist. Die Werkzeuge existieren, und die Modelle sind leistungsstark, doch die Lücke zwischen allgemeiner Kapazität und domänenspezifischer Meisterschaft bleibt groß. Die Forscher betonen, dass die Branche sich in Zukunft auf diese spezialisierten Benchmarks konzentrieren muss, anstatt sich auf allgemeine Tests zu verlassen. Sie weisen auch darauf hin, dass die derzeitigen Einschränkungen nicht nur eine Frage der rohen Intelligenz sind, sondern der Fähigkeit, Kontext zu verstehen, komplexe Codebasen zu navigieren und die korrekte Geschäftslogik anzuwenden. Während sich diese Systeme weiterentwickeln, besteht die Hoffnung, dass sie schließlich lernen werden, die komplexen Regeln der Business-Software mit derselben Leichtigkeit zu navigieren, die sie jetzt in der allgemeinen Programmierung zeigen, aber vorerst bleibt der menschliche Ingenieur essenziell, um sie durch die Komplexitäten der realen Welt zu führen.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →