Eine AL-Erweiterung, die ein Agent geschrieben hat: was die Prüfung erwischen muss

Ein KI-Agent kann AL schreiben, es gegen Ihre Symbole kompilieren und in eine Sandbox-Umgebung veröffentlichen. Der Code funktioniert meistens. Genau darum zählt die Prüfung.

Diese Seite ist die Prüfliste, die eine Beraterin durchgehen sollte, bevor agentengeschriebenes AL eine Produktionsumgebung erreicht, geordnet danach, was am meisten kostet, wenn es falsch ist.

Was kann ein Agent heute in AL?

Mehr, als die meisten Teams erwarten. Der Plan für die Release Wave 1 2026 listet sechs Punkte für diese Arbeit:

• KI-Agentenwerkzeuge für die AL-Entwicklung
• Einen AL-MCP-Server zur Fehlersuche
• An Business-Central-Agentensitzungen anhängen und sie debuggen
• AL-Tests, die aus Visual Studio Code laufen
• Symboldownload aus einem NuGet-Feed
• BC-Bench, zur Bewertung von AL-Programmieragenten

Eine praktische Schleife sieht so aus. Ein Mensch beschreibt die Änderung. Der Agent liest die Symbole, schreibt die Objekte, kompiliert, veröffentlicht in eine Sandbox und führt die Tests aus. Der Mensch probiert es aus, korrigiert es, und der Agent geht noch eine Runde.

Was die Schleife nicht enthält, ist ein Urteil über Ihre Produktionsumgebung. Das ist die Aufgabe der prüfenden Person, und sie wird nicht kleiner, weil der Code leichter zu erzeugen wurde.

Warum ist die Prüfung nicht optional?

Weil sich die Art des Fehlschlags geändert hat.

Eine Nachwuchsentwicklerin schreibt Code, der nicht kompiliert, und Code, der offensichtlich falsch ist. Beides ist günstig zu erwischen. Ein Agent schreibt Code, der kompiliert, seine eigenen Tests besteht und das Falsche tut, und zwar so, dass es absichtlich aussieht.

Die zweite Art von Fehler ist teurer, und sie ist für die Prüfungen unsichtbar, die die erste Art erwischen.

Die Prüfliste

Arbeiten Sie diese Liste ab. Die Reihenfolge richtet sich danach, was es kostet, falsch zu liegen, nicht danach, was leicht zu prüfen ist.

1. Alles, was gebuchte Daten berührt

Sehen Sie sich zuerst jeden Schreibvorgang in eine gebuchte Tabelle an, jeden Subscriber auf einer Buchungs-Codeunit und jede Verwendung von COMMIT innerhalb eines Buchungsablaufs. Ein Agent, der das Buchen „verbessert“, hat die teuerste Fehlerklasse in Business Central erzeugt, denn der Schaden liegt in der Buchhaltung, und die Buchhaltung ist die Aufzeichnung.

Behandeln Sie eine Änderung am Buchen als Änderung, die eine schriftliche Begründung, einen Test und eine zweite Leserin braucht.

2. Berechtigungen

Neue Objekte brauchen Berechtigungssätze. Ein Agent schreibt häufig die Objekte und vergisst die Berechtigungen, oder er erteilt mehr, als die Funktion braucht.

Prüfen Sie, dass jede neue Tabelle und Seite in einem Berechtigungssatz steht, dass der Satz zur Aufgabe passt, und dass nichts aus Bequemlichkeit einem Platzhaltersatz hinzugefügt wurde.

3. Upgrade und Datenmigration

Das ist das Stück, das am verlässlichsten fehlt. Ein neues Feld mit einem Vorgabewert, ein geänderter Feldtyp oder Daten, die verschoben werden müssen, brauchen Upgradecode. Ohne ihn installiert sich die Erweiterung in einer Sandbox ohne Daten sauber und scheitert in einer Produktionsumgebung mit fünf Jahren davon.

Fragen Sie direkt: was passiert mit den bestehenden Zeilen? Steht die Antwort nicht im Code, ist die Arbeit nicht fertig.

4. Objektbereiche, Benennung und Namespaces

Prüfen Sie, dass die Objekt-IDs innerhalb des Bereichs liegen, der Ihnen gehört, dass die Namen Ihrer Konvention mit dem richtigen Präfix folgen, und dass Namespaces gesetzt sind. Das ist jetzt günstig zu beheben und teuer, nachdem die Erweiterung veröffentlicht ist.

5. Leistung

Suchen Sie nach der Schleife, die eine Abfrage hätte sein sollen, nach fehlendem SetLoadFields, nach einem FlowField in einer Schleife, und nach jedem Filter auf einem Feld ohne passenden Schlüssel.

Ein Agent optimiert auf richtige Ausgaben für die Daten, die er sehen kann. Ihre Produktionsdaten sind größer als das, und die Kosten zeigen sich erst in dieser Größe.

6. Fehlerbehandlung

Prüfen Sie, dass Fehler nicht verschluckt werden. Eine TryFunction, deren Fehlschlag ignoriert wird, macht aus einem lauten Fehlschlag ein stilles falsches Ergebnis, und das ist das Schlimmere von beidem.

Prüfen Sie, dass Fehlermeldungen den Datensatz und den Grund nennen, denn diese Meldungen erscheinen in der Telemetrie als RT0030, und eine vage Meldung verschwendet die Stunde der nächsten Person.

7. Übersetzung und Beschriftungen

Bestätigen Sie, dass jede Beschriftung übersetzbar ist und dass keine Zeichenkette, die Benutzer sehen, in einer Sprache fest verdrahtet ist. Für einen dänischen oder deutschen Kunden ist das kein letzter Schliff. Es ist der Unterschied zwischen einer benutzbaren Seite und einem zweisprachigen Durcheinander.

8. Tests

Fragen Sie, was die Tests tatsächlich behaupten. Agentengeschriebene Tests neigen dazu, zu behaupten, dass der Code gelaufen ist, statt dass das Ergebnis stimmt.

Ein Test, der eine berechnete Zahl gegen einen bekannten Wert prüft, ist zehn andere wert, die nur auf „kein Fehler“ prüfen.

Was Agenten am häufigsten falsch machen

Aus unserer eigenen Prüfarbeit, in grober Reihenfolge der Häufigkeit:

1. Fehlender Upgradecode für neue oder geänderte Felder.
2. Berechtigungssätze, die nie angelegt wurden.
3. Ein Subscriber, der bei jedem Buchen läuft, wenn er bei einer Belegart laufen sollte.
4. Filter, die nicht suchen können, auf Tabellen, bei denen es zählt.
5. Beschriftungen, die nicht übersetzbar sind.
6. Tests, die nichts Nützliches behaupten.
7. Selbstsichere Verwendung eines Musters aus einer älteren Business-Central-Version.

Punkt 7 sollten Sie im Auge behalten. Agenten lernen aus veröffentlichtem Code, und viel veröffentlichtes AL ist alt. Ein Muster, das in einer früheren Version richtig war, kann heute veraltet sein, und es kompiliert weiterhin.

Wie Sie die Prüfung günstig machen

Die Prüfung ist der Engpass, also richten Sie alles auf sie aus.

Halten Sie Sitzungen klein. Eine Änderung pro Sitzung. Eine Sitzung, die sechs Bereiche berührt, lässt sich nicht richtig prüfen und wird trotzdem genehmigt.

Verlangen Sie eine Sandbox. Nichts erreicht die Produktion direkt. Der Agent veröffentlicht in eine Sandbox, ein Mensch probiert die Änderung aus, und erst dann prüft eine Beraterin den Code.

Setzen Sie der Sitzung ein Budget. Eine Obergrenze, die vor dem Start gesetzt wird, hält einen Agenten davon ab, eine Stunde auf dem falschen Weg zu verbringen.

Machen Sie das Diff zur Einheit der Prüfung. Prüfen Sie die Änderung, nicht die Datei. Wer das ganze Objekt lesen muss, wird es überfliegen.

Halten Sie die Regeln an einer Stelle. Ein geschriebener Satz Qualitätsregeln, den sowohl der Agent als auch die prüfende Person nutzt, macht aus der Prüfung ein Nachsehen statt einer Meinungsäußerung. Der Agent liest dieselben Regeln, bevor er schreibt.

Der Sinn der Schleife

Der Wert liegt nicht darin, dass der Code umsonst ist. Der Wert liegt darin, dass die Person, die den Geschäftsprozess versteht, die Änderung selbst ausdrücken kann, und dass die Beraterin ihre Zeit auf das Urteil verwendet statt auf das Tippen.

Dieser Tausch geht nur auf, wenn die Prüfung echt ist. Eine agentengeschriebene Erweiterung, die niemand gelesen hat, ist eine Produktionsänderung, die niemand gelesen hat, und das Werkzeug, das sie leicht gemacht hat, ist keine Verteidigung.