Vom Code-Vervollständiger zum Development Agent
Noch vor kurzer Zeit bedeutete „KI in der Entwicklung“ hauptsächlich: Code vorschlagen, Funktionen erklären, Boilerplate erzeugen oder Fehlertexte übersetzen. 2026 verschiebt sich dieses Bild deutlich.
Microsoft stellt für Business Central inzwischen AI Agent Tools für die AL-Entwicklung bereit. Laut Microsoft können AI Agents unter anderem Projekte bauen, Extensions veröffentlichen, Symbole durchsuchen, Diagnosen auslesen und Debugging unterstützen. Zusätzlich gibt es einen eigenständigen AL MCP Server, der diese Fähigkeiten über das Model Context Protocol (MCP) für MCP-kompatible AI Agents bereitstellt.
Claude Code unterstützt MCP ebenfalls. Damit wird eine Kombination technisch interessant: Claude kann nicht nur AL-Code formulieren, sondern – in einer sauber konfigurierten Umgebung – auf definierte Development Tools zugreifen und Ergebnisse wie Build-Fehler oder Symbolinformationen direkt in den Arbeitsprozess einbeziehen.
Das ist mehr als Autocomplete.
Aber genau deshalb steigt auch das Risiko, falsche Dinge schneller zu tun.
AI beschleunigt Entwicklung. Architektur, fachliche Verantwortung und Qualitätskontrolle bleiben menschliche Aufgaben.
Was Microsoft 2026 konkret verändert hat
Die entscheidende Neuerung ist nicht, dass ein Sprachmodell AL-Syntax kennt. Entscheidend ist, dass der Agent Werkzeuge erhält.
Microsoft dokumentiert für die AL Language Extension 17.0 und neuer unter anderem Tools für:
- Build und Compile
- Symbolsuche
- Diagnostics
- Publishing
- Debugging-nahe Funktionen
- Test- und Entwicklungsworkflows
Der AL MCP Server kann als eigenständiger Prozess laufen und stellt diese Werkzeuge MCP-kompatiblen Agents bereit. Das bedeutet: Der Agent bekommt nicht einfach den gesamten Rechnerzugriff, sondern definierte Tools mit einem klaren Zweck.
Das ist architektonisch ein wichtiger Unterschied.
Ein guter Agent-Workflow sollte nicht lauten:
„Hier ist mein Projekt. Mach alles fertig.“
Sondern eher:
„Analysiere diese Anforderung. Prüfe zuerst bestehende Objekte und Events. Erstelle einen Lösungsvorschlag. Implementiere auf einem Feature Branch. Baue das Projekt. Behebe nur Fehler, die zu deiner Änderung gehören. Erstelle Tests. Zeige mir den Diff und warte auf Review.“
Die Qualität des Arbeitsauftrags wird damit zu einem Teil der Entwicklungsarchitektur.
Wo Claude Code in diesen Workflow passt
Claude Code kann MCP-Server anbinden und damit externe Tools oder Datenquellen nutzen. Der AL MCP Server von Microsoft ist ausdrücklich dafür gedacht, AL-Development-Tools für MCP-kompatible AI Agents bereitzustellen.
Das bedeutet nicht automatisch, dass jede Kombination in jeder Umgebung produktionsreif oder vom Hersteller als End-to-End-Szenario zertifiziert ist. Genau deshalb sollte man mit einem Sandbox- und Proof-of-Concept-Ansatz starten.
Ein sinnvoller Test wäre beispielsweise:
- Bestehendes AL-Projekt in Git.
- Separate Sandbox.
- AL MCP Server mit minimal notwendigen Berechtigungen.
- Claude Code im Projektordner.
- Klare `CLAUDE.md` mit Coding-Regeln.
- Eine kleine, gut definierte Änderung.
- Build und Tests.
- Human Code Review.
- Erst danach Publish in eine Testumgebung.
So lässt sich der Nutzen messen, ohne direkt produktive Risiken einzugehen.
Was sich am Entwicklerjob wirklich verändert
Die These „KI ersetzt Entwickler“ greift zu kurz. In Business-Central-Projekten liegt ein grosser Teil der Schwierigkeit nicht in der Frage, wie eine Schleife in AL geschrieben wird.
Die schwierigen Fragen sind:
- Gehört diese Logik überhaupt in Business Central?
- Ist sie im Standard bereits vorhanden?
- Gibt es ein passendes Event?
- Welche App besitzt die fachliche Verantwortung?
- Wie wirkt sich die Änderung auf Updates aus?
- Welche Datenquelle ist führend?
- Wie behandeln wir Berechtigungen?
- Was passiert im Fehlerfall?
- Wie testen wir Sonderfälle?
Ein Agent kann bei der Analyse unterstützen. Er kann aber nur auf Basis des verfügbaren Kontexts entscheiden. Wenn die fachliche Anforderung schlecht ist, kann er eine technisch elegante Lösung für das falsche Problem bauen.
Der ideale AI-gestützte AL-Workflow
1. Fachliche Anforderung zuerst
Vor dem Prompt steht eine vernünftige Anforderung:
- Ausgangslage
- Ziel
- betroffene Rollen
- Business-Regeln
- Daten
- Ausnahmen
- Akzeptanzkriterien
- Nicht-Ziele
Je klarer diese Informationen sind, desto weniger Interpretationsspielraum hat der Agent.
2. Bestehenden Standard und Code analysieren
Der Agent soll nicht sofort entwickeln. Zuerst sollte er nach vorhandenen Tabellen, Pages, Codeunits, Events, Enums und bestehenden Extensions suchen.
Gerade in älteren BC-Landschaften verhindert diese Phase unnötige Doppelentwicklungen.
3. Lösungsvorschlag vor Code
Ich würde den Agent zunächst ein kurzes Technical Design erstellen lassen:
- betroffene Objekte
- Datenmodell
- Events/Subscribers
- Berechtigungskonzept
- Integrationspunkte
- Teststrategie
- Risiken
Erst nach Review folgt Code.
4. Kleine Änderungen statt Mega-Prompt
Eine 2'000-Zeilen-Änderung in einem Schritt ist schwer zu prüfen. Besser sind kleine, nachvollziehbare Commits.
AI verändert nicht die Grundregel guter Softwareentwicklung: kleine Änderungen sind leichter zu testen, reviewen und zurückzurollen.
5. Build und Diagnostics automatisieren
Hier spielen die neuen AL Agent Tools ihre Stärke aus. Der Agent kann nach seiner Änderung selbst bauen, Diagnostics lesen und technische Fehler korrigieren.
Damit entfällt ein Teil der manuellen Schleife „Code schreiben – Build – Fehler kopieren – korrigieren“.
6. Tests als Pflichtbestandteil
Generierter Code ohne Tests ist technische Schuld mit höherer Geschwindigkeit.
Für relevante Business-Logik sollte der Agent Tests ergänzen oder bestehende Tests anpassen. Der Mensch prüft, ob die Testfälle fachlich die richtigen Risiken abdecken.
7. Human Review bleibt Gate
Vor Merge oder Publish sollten mindestens folgende Punkte geprüft werden:
- fachliche Korrektheit
- Datenmodell
- Performance
- Berechtigungen
- Error Handling
- Updatefähigkeit
- Naming und Struktur
- Tests
- Auswirkungen auf bestehende Prozesse
8. Sandbox vor Produktion
Ein Agent, der publizieren kann, ist mächtig. Genau deshalb sollten produktive Berechtigungen nicht der Default sein.
Die sichere Reihenfolge lautet: lokale Änderung → Build → Tests → Review → Sandbox → fachlicher Test → Deployment-Prozess.
Wo AI Agents besonders stark sind
Ich sehe aktuell mehrere attraktive Anwendungsfälle.
Wiederkehrende technische Änderungen
Neue Felder, Pages, API Pages, Berechtigungen oder standardisierte Erweiterungsmuster können deutlich schneller vorbereitet werden.
Refactoring und Aufräumen
Legacy-Code analysieren, ungenutzte Strukturen identifizieren, Naming vereinheitlichen oder bestehende Funktionen in kleinere Bausteine zerlegen.
Integrationsentwicklung
API Pages, DTO-nahe Strukturen, Mapping-Logik, Fehlerbehandlung und technische Dokumentation eignen sich gut für AI-Unterstützung – sofern die fachliche Ownership der Daten sauber geklärt ist.
Tests und Dokumentation
Ein oft unterschätzter Nutzen. AI kann aus Code und Anforderungen Testfälle, technische Beschreibungen und Change Notes vorbereiten.
Fehlersuche
Diagnostics, Call Stacks, Symbolinformationen und bestehender Code können schneller miteinander in Beziehung gesetzt werden.
Wo ich den Agent bewusst bremsen würde
Architekturentscheidungen
Nur weil etwas technisch möglich ist, gehört es nicht automatisch in BC.
Produktivdaten
Development Agents brauchen für die meisten Aufgaben keine echten produktiven Kundendaten.
Unkontrolliertes Publishing
Publishing-Fähigkeiten sollten minimal und umgebungsbezogen vergeben werden.
Sicherheitsrelevante Logik
Berechtigungen, Buchungslogik, finanzielle Kontrollen oder besonders sensible Prozesse benötigen explizite Reviews.
Grosse automatische Refactorings
Je grösser der Diff, desto schwieriger ist die menschliche Kontrolle. AI sollte nicht zur Ausrede für Review-Müdigkeit werden.
Illustrativer Business Case: Eine neue Integrations-Extension
Ein Unternehmen möchte aus einem externen Service strukturierte Daten nach Business Central übernehmen. Bisher würde ein Entwickler zunächst die API-Dokumentation lesen, Objekte suchen, eine Mapping-Struktur entwerfen, API Pages beziehungsweise passende Endpunkte prüfen, Fehlerbehandlung bauen und Testfälle schreiben.
Mit einem Agent-gestützten Workflow könnte der Ablauf so aussehen:
- Fachliche Spezifikation und Beispielpayload werden als Kontext bereitgestellt.
- Claude analysiert die vorhandene AL-App und schlägt die betroffenen Objekte vor.
- Der Entwickler korrigiert das Design.
- Claude implementiert die erste Version auf einem Branch.
- Der Agent führt Build und Diagnostics aus.
- Fehler werden iterativ korrigiert.
- Claude erzeugt Testfälle und technische Dokumentation.
- Der Entwickler führt Code Review und fachliche Prüfung durch.
- Deployment in Sandbox.
- End-to-End-Test mit dem realen Integrationspartner.
Der Business Case entsteht nicht dadurch, dass „KI Code schreibt“. Er entsteht dadurch, dass mehrere repetitive Schleifen verkürzt werden und der Entwickler mehr Zeit auf Architektur, Datenlogik und Qualität verwenden kann.
Welche Kennzahlen ich messen würde
Wer AI Development ernsthaft einführt, sollte nicht nur subjektiv fragen, ob es sich schneller anfühlt.
Sinnvolle Kennzahlen sind beispielsweise:
- Durchlaufzeit von Anforderung bis Pull Request
- Build-Fehler pro Änderung
- Review-Kommentare pro Pull Request
- Defects nach Deployment
- Anteil automatisierter Tests
- Dokumentationsgrad
- Rework nach fachlichem Test
- Zeitaufwand für repetitive Development Tasks
Nur wenn Qualität und Geschwindigkeit gemeinsam betrachtet werden, entsteht ein realistisches Bild.
Ein Beispiel für gute Projekt-Instruktionen an Claude Code
Die Qualität der Agent-Arbeit hängt stark davon ab, welche Regeln dauerhaft im Repository stehen. Für ein Business-Central-Projekt würde ich beispielsweise in einer `CLAUDE.md` festhalten:
- Zielversion von Business Central und AL Language Extension
- App-Aufteilung und Abhängigkeiten
- Naming Conventions
- bevorzugte Patterns
- Regeln für Events und Subscribers
- Verbot direkter Änderungen an fremden Apps
- Umgang mit Permissions
- Testpflicht für Business-Logik
- keine produktiven Secrets oder Kundendaten
- Publish nur in definierte Sandbox-Umgebungen
- vor grösseren Änderungen zuerst Technical Design und Plan erstellen
- bestehende Architektur respektieren, keine parallelen Frameworks erfinden
Damit wird Kontext zu einem wiederverwendbaren Bestandteil des Development-Prozesses. Ein guter Prompt ist dann kürzer, weil die grundlegenden Regeln bereits im Projekt liegen.
Warum Code Ownership sogar wichtiger wird
Wenn ein Agent grosse Teile einer Änderung erstellt, darf nicht unklar werden, wem die Lösung gehört. Für jedes Feature sollte weiterhin eine Person fachlich und technisch verantwortlich sein.
Ich würde Pull Requests deshalb nicht mit „AI generated“ abnicken, sondern dieselben Fragen stellen wie bei menschlichem Code:
- Versteht der Reviewer die Lösung vollständig?
- Würde er sie im Incident selbst supporten können?
- Ist klar, warum diese Architektur gewählt wurde?
- Sind Edge Cases sichtbar?
- Gibt es nachvollziehbare Tests?
- Ist der Code in zwei Jahren noch wartbar?
AI reduziert die Kosten der Code-Erzeugung. Dadurch steigt potenziell die Menge an Code. Genau deshalb müssen Teams aktiv verhindern, dass mehr Output automatisch mehr technische Schuld erzeugt.
Mein Reifegradmodell für AI-gestützte BC-Entwicklung
Level 1 – Assist
AI erklärt Code, erstellt kleine Snippets und unterstützt bei Dokumentation. Keine Tool-Aktionen.
Level 2 – Build
Agent darf Code ändern, Build und Diagnostics ausführen. Human Review ist Pflicht.
Level 3 – Test
Agent baut zusätzlich Tests, analysiert Regressionen und dokumentiert Änderungen.
Level 4 – Sandbox Delivery
Agent kann kontrolliert in Sandboxes publizieren und Testabläufe vorbereiten.
Level 5 – Orchestrated Development
Mehrere Agent-Schritte unterstützen Analyse, Entwicklung, Tests, Dokumentation und Pull Requests. Produktionsdeployment bleibt über normale Release-Gates kontrolliert.
Nicht jedes Team muss Level 5 erreichen. Der richtige Reifegrad ist derjenige, bei dem Nutzen und Kontrollfähigkeit zusammenpassen.
Fazit: AI macht schlechte Development-Prozesse nicht gut
Business Central bekommt 2026 eine deutlich agentischere Development-Toolchain. Microsoft öffnet AL-Funktionen über MCP, und Claude Code kann MCP-basierte Werkzeuge einbinden.
Das ist technisch spannend. Der grössere Hebel liegt aber in der Arbeitsweise.
Wer Anforderungen unsauber formuliert, ohne Git arbeitet, keine Tests hat und direkt in produktive Umgebungen publiziert, wird mit AI nicht professioneller. Er wird nur schneller.
Wer dagegen klare Spezifikationen, saubere Branches, automatisierte Builds, Tests, Reviews und Sandboxes nutzt, kann AI als echten Force Multiplier einsetzen.
Die Frage ist deshalb nicht mehr nur:
„Kann AI AL entwickeln?“
Sondern:
„Ist unser Entwicklungsprozess gut genug, damit ein Agent sicher darin arbeiten kann?“
