Die neue ABAP-Entwickler-Toolchain 2026: ABAP MCP Server, VS Code und der Custom-Code-Agent im Lifecycle

1. Was die neue ABAP-Toolchain umfasst

Die ABAP-Entwicklung hat 2026 ihre größte Werkzeug-Veränderung seit der Einführung der ABAP Development Tools für Eclipse erlebt. Im Kern stehen drei Bausteine, die SAP zur Sapphire 2026 als allgemein verfügbar oder für das zweite Quartal 2026 angekündigt hat.

Der erste Baustein ist der ABAP Language Server. Er ist eine Abstraktionsschicht, die ABAP-Entwicklungs-Fähigkeiten unabhängig von der jeweiligen Entwicklungsumgebung bereitstellt. Auf dieser Basis können verschiedene IDEs dieselben Funktionen nutzen.

Der zweite Baustein ist der ABAP MCP Server. Er baut auf dem Language Server auf und nutzt das Model Context Protocol, einen offenen Standard, über den KI-Agenten strukturiert mit externen Werkzeugen und Systemen interagieren. Der ABAP MCP Server stellt ABAP-Entwicklungs-Fähigkeiten als Werkzeuge für Agenten bereit, mit und ohne eingebettete KI. Er läuft in der Kernschicht und bietet dieselben Werkzeuge sowohl in den ABAP Development Tools für Eclipse als auch in der neuen Variante für Visual Studio Code.

Der dritte Baustein ist die Erweiterung der IDE-Auswahl. Die ABAP Development Tools sind nun auch für Visual Studio Code verfügbar. Eclipse bleibt nach SAP-Aussage die empfohlene Umgebung für vollumfängliche ABAP-Entwicklung, bis die VS-Code-Variante Funktionsgleichheit erreicht. Beide teilen sich dieselbe Codebasis und denselben MCP-Server.

1. Begleitende Komponenten. Drei weitere Elemente runden das Bild ab. Erstens das im Januar 2026 vorgestellte ABAP-spezifische Sprachmodell, das auf einer großen Menge ABAP- und CDS-Code trainiert wurde und über den GenAI Hub bereitsteht. Zweitens ein ABAP Custom Code Transformation Agent mit Fokus auf die Migration von SAP ECC nach SAP S/4HANA, dessen Verfügbarkeit für das zweite Quartal 2026 geplant ist. Drittens die Bereitstellung der ABAP-AI-Fähigkeiten für SAP S/4HANA Cloud Private Edition für Releases ab 2021, ebenfalls für das zweite Quartal 2026.

2. Was sich nicht ändert. Wichtig für die Einordnung: Die Werkzeuge, mit denen ABAP entwickelt wird, ändern sich. Die Mechanik, über die ABAP-Änderungen in die Landschaft gelangen, ändert sich nicht. Eine Änderung erzeugt weiterhin einen Transportauftrag, der über das Change and Transport System oder über git-basiertes CTS in die Folgesysteme transportiert wird. Das ist der entscheidende Punkt dieses Artikels: Eine moderne, teilweise agentische Erzeugung von Code trifft auf einen unveränderten Transport- und Freigabe-Mechanismus.

2. Warum die agentische Toolchain für SAP ALM zählt

1. ABAP öffnet sich für das Agenten-Ökosystem. Bisher war ABAP-Entwicklung weitgehend in der eigenen, geschlossenen Welt der ABAP Development Tools für Eclipse zu Hause. Mit dem ABAP MCP Server ändert sich das. Über das Model Context Protocol können externe Coding-Agenten ABAP-Entwicklungs-Aufgaben direkt ausführen. SAP nennt dabei ausdrücklich auch Assistenten außerhalb des eigenen Hauses. Damit rückt die ABAP-Entwicklung in dasselbe Ökosystem, in dem Entwickler ohnehin mit UI5 und CAP arbeiten.

Für SAP Application Lifecycle Management ist das ein doppelter Befund. Auf der einen Seite steigt die Produktivität, weil Agenten Routineaufgaben übernehmen und kontextbezogen unterstützen. Auf der anderen Seite verbreitert sich die Fläche, über die Code in die Landschaft kommt, und damit die Fläche, die Governance abdecken muss.

2. Der Migrations-Hebel. Der Custom Code Transformation Agent zielt auf einen der größten Schmerzpunkte der SAP-Community: die Anpassung von kundeneigenem ABAP-Code im Rahmen der Migration von ECC nach S/4HANA. Mit dem Wartungsende des klassischen ERP-Systems steht dieses Thema bei vielen Organisationen unter Zeitdruck. Ein Agent, der Custom Code analysiert und Transformationsvorschläge erzeugt, kann den Aufwand verändern. Er verändert aber auch die Frage, wer für die Korrektheit des transformierten Codes einsteht.

3. Lizenz- und Zugangsmodell. Die KI-Fähigkeiten von SAP Joule für Entwickler erfordern eine zusätzliche Lizenz. SAP hat den kostenfreien Zugang zu diesen Fähigkeiten bis September 2026 verlängert, was als Signal zu lesen ist, die Verbreitung vor einem kostenpflichtigen Modell zu beschleunigen. Für die Planung bedeutet das: Die Werkzeuge sind verfügbar, das dauerhafte Kostenmodell ist Teil der Entscheidung.

3. Die agentische Toolchain in den Lebenszyklus einbetten

Die Aufgabe für SAP-ALM-Verantwortliche ist nicht, die neuen Werkzeuge zu verhindern, sondern sie kontrolliert in den bestehenden Change- und Release-Prozess zu integrieren. Dafür eignen sich vier Ansätze.

1. Die Agenten- und IDE-Auswahl bewusst steuern. Da der ABAP MCP Server offen für verschiedene Agenten ist, wird die Auswahl der zugelassenen Agenten und Modelle zur Governance-Entscheidung. Eine Organisation sollte festlegen, welche Coding-Agenten und welche IDE-Varianten freigegeben sind, und das nicht dem Zufall der individuellen Entwickler-Präferenz überlassen. Das verbindet sich mit der ohnehin nötigen Whitelist- und Sandbox-Praxis für MCP-Server.

2. Den Transport als verbindlichen Kontrollpunkt erhalten. Der Transport bleibt der Punkt, an dem eine Änderung kontrolliert in die Landschaft gelangt. Genau hier setzt die etablierte Governance an: Code-Review, ATC-Prüfung beim Transport-Release, Downgrade Protection, Vier-Augen-Prinzip. Diese Kontrollen müssen unabhängig davon greifen, ob der Code von einem Menschen oder mit Unterstützung eines Agenten entstanden ist. Der Transport ist die Schicht, die KI-Erzeugung und Landschafts-Integrität voneinander trennt.

3. KI-Beteiligung nachvollziehbar machen. Wenn ein Agent an einer Änderung beteiligt war, sollte das nachvollziehbar dokumentiert sein. Das ist keine Schikane, sondern die Grundlage für Audit-Fähigkeit. Bei einer späteren Fehleranalyse oder einer Prüfung durch Wirtschaftsprüfer ist die Frage, wie eine Änderung entstanden ist, Teil des durchgängigen Audit Trails von der Anforderung bis zum Deployment.

4. Den Migrations-Agenten als Vorschlag, nicht als Entscheidung behandeln. Der Custom Code Transformation Agent erzeugt Transformationsvorschläge. Diese Vorschläge gehören geprüft, getestet und freigegeben wie jede andere Änderung. Eine automatisierte Transformation, die ungeprüft in einen Transport fließt, verlagert das Risiko nur, sie beseitigt es nicht. Test-Abdeckung und Impact-Analyse bleiben Pflicht.

4. Wo die agentische Toolchain Governance fordert

1. Verantwortung für KI-unterstützten Code. Die zentrale offene Frage ist die Verantwortung. Wenn ein Agent ABAP-Code erzeugt oder transformiert, bleibt die Verantwortung für die Korrektheit beim Menschen, der die Änderung freigibt. Das setzt voraus, dass dieser Mensch den Code versteht und bewerten kann. Eine Organisation, die Agenten produktiv einsetzt, ohne die Review-Kompetenz vorzuhalten, übernimmt ein Risiko, das im Transport-Protokoll zunächst unsichtbar bleibt.

2. Die verbreiterte Erzeugungs-Fläche. Mit der Öffnung für externe Agenten und eine zweite IDE wächst die Zahl der Wege, über die Code entsteht. Jeder zusätzliche Weg ist ein zusätzlicher Pfad, der in die Governance aufgenommen werden muss. Eine Toolchain, die offen, aber nicht geregelt ist, erzeugt eine Lücke zwischen dem, was technisch möglich, und dem, was kontrolliert ist.

3. Tempo gegen Prüfbarkeit. Agentische Werkzeuge versprechen Geschwindigkeit. Geschwindigkeit ohne entsprechende Prüfung erzeugt aber genau das Risiko, das durchgängige Change-Prozesse vermeiden sollen. Die schwierigste Aufgabe einer KI-gestützten Entwicklungs-Governance ist nicht, ob der Vorschlag des Agenten technisch funktioniert, sondern ob die Organisation die freie Wahl behält, ihn abzulehnen, auch wenn das Werkzeug ihn längst als fertig markiert hat. Wer diese Wahl nicht aktiv ausübt, überlässt die Kontrolle dem Werkzeug.

4. Werkzeug-Wildwuchs als Altlast in neuer Form. Die Wahlfreiheit bei IDE und Agent ist ein Vorteil für Entwickler, kann aber zu einer fragmentierten Landschaft führen, in der verschiedene Teams unterschiedliche Werkzeuge und Modelle nutzen. Ohne eine bewusste Standardisierung entsteht eine neue Variante des Tool-Wildwuchses, den viele Organisationen im Change-Management ohnehin als Problem kennen.

5. Ein Rahmen für die agentische ABAP-Entwicklung

1. Zugelassene Werkzeuge und Agenten definieren. Eine Organisation legt fest, welche IDE-Varianten und welche Coding-Agenten über den ABAP MCP Server freigegeben sind, und dokumentiert diese Entscheidung.

2. Den Transport als Kontrollpunkt unangetastet lassen. Code-Review, ATC-Prüfung beim Release, Downgrade Protection und Vier-Augen-Prinzip greifen unabhängig von der Erzeugungsart.

3. KI-Beteiligung protokollieren. Wenn ein Agent beteiligt war, ist das Teil des Änderungs-Datensatzes und des Audit Trails.

4. Review-Kompetenz vorhalten. Wer KI-unterstützt entwickelt, braucht Entwickler, die den erzeugten Code verstehen und verantworten können. Agenten ersetzen das Urteil nicht, sie beschleunigen die Vorbereitung des Urteils.

5. Migrations-Vorschläge als Änderungen behandeln. Der Output des Custom Code Transformation Agent durchläuft denselben Test-, Impact- und Freigabe-Prozess wie jede andere Änderung.

6. Das Lizenz- und Kostenmodell einplanen. Die kostenfreie Phase ist begrenzt. Eine belastbare Planung berücksichtigt das dauerhafte Modell.

6. Tool Landscape

Die folgende Tabelle zeigt, wie sich die neue Erzeugungs-Ebene und die etablierte Transport-Governance-Ebene verteilen. Sie macht deutlich, dass die agentischen Werkzeuge die Code-Erzeugung verändern, aber die Kontrolle über den Transport und den Audit Trail bei der Governance-Ebene bleibt.

¹ Solutive AG ist Initiator des Change Orchestration Institute. Die Bewertung in der Tabelle ist eine Selbstauskunft des Anbieters und nicht Teil einer redaktionell unabhängigen Validierung. Die KI-Assistenz und die IDE-Wahl liegen bewusst außerhalb des Funktionsumfangs einer Change- und Transport-Governance-Schicht und werden durch die SAP-Entwicklungswerkzeuge abgedeckt.

Die Tabelle zeigt die Arbeitsteilung. Die SAP-Entwicklungswerkzeuge, einschließlich der agentischen Anbindung über den ABAP MCP Server, sind stark in der Erzeugung und KI-Assistenz. Sie sind aber konstruktionsbedingt nicht die Schicht, die Transporte freigibt, Downgrades verhindert und einen lückenlosen Audit Trail liefert. Diese Aufgabe liegt bei der Change- und Transport-Governance, sei es über ChaRM, Cloud ALM in seinen aktuellen Grenzen oder eine Orchestration-Schicht. Eine vollständige Abdeckung der ABAP-Änderungs-Kette kombiniert beide Ebenen.

7. Operative Konsequenzen für SAP-ALM-Verantwortliche

Aus der neuen Toolchain ergeben sich konkrete Schritte.

Die erste Konsequenz betrifft die Werkzeug-Strategie. Organisationen sollten aktiv entscheiden, welche IDE-Variante und welche Agenten freigegeben sind, statt die Auswahl der individuellen Präferenz zu überlassen. Eine dokumentierte Entscheidung ist die Grundlage für jede weitere Kontrolle.

Die zweite Konsequenz betrifft die Transport-Governance. Die bestehenden Kontrollen am Transport müssen daraufhin geprüft werden, ob sie auch greifen, wenn Code mit Agenten-Unterstützung entstanden ist. In den meisten Fällen greifen sie unverändert, weil sie am Transport ansetzen, nicht an der Erzeugung. Genau das ist die gute Nachricht: Der etablierte Kontrollpunkt bleibt wirksam.

Die dritte Konsequenz betrifft die Migration. Wer den Custom Code Transformation Agent für die S/4HANA-Migration einsetzen will, sollte den Output von Beginn an in den geprüften Change-Prozess einbetten, einschließlich Test-Abdeckung und Impact-Analyse. Eine automatisierte Transformation ohne Prüfung verschiebt das Risiko in die Produktivlandschaft.

Die vierte Konsequenz betrifft die Kompetenz. Die produktive Nutzung agentischer Werkzeuge setzt voraus, dass im Team die Fähigkeit vorhanden ist, erzeugten Code zu verstehen und zu verantworten. Diese Kompetenz ist die eigentliche Voraussetzung dafür, dass die Geschwindigkeit der Werkzeuge zu einem Vorteil und nicht zu einem Risiko wird.