Blog › KI
KICoding

ABAP goes Agentic: MCP Server, VS Code und der Preis für KI-Unterstützung

· David · 8 min Lesezeit
ABAP goes Agentic: MCP Server, VS Code und der Preis für KI-Unterstützung

SAP hat auf dem Sapphire 2026 mehrere Ankündigungen gebündelt, die zusammen das beschreiben sollen, was SAP als „bedeutsamsten Schritt seit der Einführung von Joule for Developers" bezeichnet: den ABAP MCP Server in allgemeiner Verfügbarkeit, VS Code als zweite ABAP-IDE, drei Custom-Code-Agenten für S/4HANA-Migration, und ein neues Preismodell. Wir schauen uns an, was technisch dahintersteckt, was die Ankündigungen realistisch leisten — und was noch fehlt.

Die Architektur: Language Server als Fundament

Der ABAP Language Server bildet die technische Grundlage für alle Ankündigungen dieser Woche. Er ist keine neue Erfindung — er existiert seit Jahren als Abstraktionsschicht, über die Eclipse (ABAP Development Tools) mit SAP-Backendsystemen kommuniziert. Was SAP jetzt getan hat: auf diesem Fundament den ABAP MCP Server aufgebaut.

MCP steht für Model Context Protocol — ein offener Standard, den Anthropic entwickelt hat und der inzwischen von einem breiten Ökosystem an KI-Tools unterstützt wird. MCP beschreibt, wie KI-Agenten mit externen Systemen und Werkzeugen interagieren: strukturiert, verlässlich, ohne proprietäre Integrationen pro Tool. Wer den ABAP MCP Server nutzt, kann mit GitHub Copilot, Amazon Q, Claude Code oder jedem anderen MCP-kompatiblen Agenten ABAP-Entwicklungsoperationen durchführen — direkt aus der IDE, ohne SAP-spezifische Plugin-Kopplung. Claude Code etwa bindet MCP-Server über seine Konfigurationsdatei ein; der ABAP MCP Server ist für Claude Code genauso ansteuerbar wie für jeden anderen MCP-Client.

Was der Server konkret exponiert:

  • ABAP-Objekte lesen, anlegen, ändern und löschen
  • Transportaufträge verwalten
  • Syntaxprüfungen und Code-Analyse
  • Suche in ABAP-Keyword-Dokumentation, DSAG-Entwicklungsrichtlinien und ABAP Style Guide
  • ABAP Feature Matrix: Verfügbarkeit von ABAP-Features über Releases und ABAP-Cloud-Varianten

Der Server ist in Eclipse und in VS Code verfügbar.

Eine Einordnung zur Einordnung: Die Community hat diesen Weg bereits beschritten. Marian Zeis veröffentlichte im Februar 2026 einen ABAP MCP Server für GitHub Copilot in Eclipse, der die ADT-API über den offiziellen ADT-Endpunkt anbindet. Mario Andreschak baute eine eigene Variante auf GitHub. SAP institutionalisiert und supportet jetzt, was andere zuerst gebaut haben — das ist kein Kritikpunkt, aber eine präzise Beschreibung: SAP folgt einer Richtung, die die Community validiert hatte. Bemerkenswert ist, wie schnell die Gemeinschaft das MCP-Protokoll aufgegriffen hat, noch bevor es ein offizielles SAP-Produkt war.

VS Code: 14 Jahre Abstand aufgeholt

Am 29. Mai 2026 soll ABAP Development Tools (ADT) für Visual Studio Code allgemein verfügbar werden — vierzehn Jahre nach dem Launch von ADT für Eclipse. VS Code ist die meistgenutzte Entwicklungsumgebung weltweit, mit einem dichten Ökosystem an KI-Extensions. Die Entscheidung, ABAP dort hinzubringen, ist die logische Konsequenz aus der Language-Server-Architektur: Die IDE kommuniziert nicht mehr direkt mit dem Backend, sondern über den Language Server — und dieser kann unabhängig von der IDE angebunden werden.

SAP benennt die Einschränkung offen: Der initiale Funktionsumfang konzentriert sich auf SAP-Fiori-App-Entwicklung. Eclipse bleibt die IDE für vollständiges ABAP-Development, bis VS Code Funktionsparität erreicht. Wer tiefe Backend-Entwicklung betreibt, komplexe Business-Objekte anlegt oder ABAP-Cloud-spezifische Strukturen benötigt, bleibt an Eclipse gebunden — die Java-basierte IDE, die seit vierzehn Jahren auf Ablösung wartet und bis auf weiteres nicht abgelöst wird, hier weigert sich SAP weiter beharrlich in den 20Jahren des 21 Jahrhunderts anzukommen.

Für Entwickler, die primär Fiori-Frontend oder ABAP Cloud schreiben, ist VS Code dennoch ein relevanter Fortschritt: direkter Zugang zu GitHub Copilot Agent Mode, Cursor, Claude Code oder anderen AI-Coding-Assistenten — in der Umgebung, die sie bereits nutzen, ohne Eclipse-Umweg.

Die Kombination aus Language Server, MCP Server und VS Code-Integration ergibt eine Architektur, die in anderen Entwicklungsökosystemen seit Jahren Standard ist. Dass sie für ABAP erst 2026 ankommt, ist die eigentliche Nachricht hinter der Ankündigung.

Custom-Code-Agenten: Der konkreteste Anwendungsfall

Die Custom-Code-Migration-Agenten (CCM) sind die Ankündigung mit dem unmittelbarsten Geschäftswert. SAP-S/4HANA-Migrationsprojekte scheitern nicht an fehlender Infrastruktur — ein wesentlicher Teil ihrer Komplexität liegt in bestehendem ABAP-Custom-Code: über Jahre gewachsen, oft undokumentiert, eng mit SAP-Standard-Objekten verflochten. Diesen Code zu verstehen, anzupassen und zu validieren ist zeitintensiv und teuer.

SAP plant drei Agenten für diesen Bereich:

AgentFunktionVerfügbarkeit
Mass S/4 Custom Code Conversion AgentATC-Findings identifizieren; deterministische und KI-generierte Fixes in großem Umfang anwendenQ2 2026
Mass Clean Core Adoption AgentClean-Core-ATC-Issues identifizieren, fixen oder strukturierte Empfehlungen liefernSpäter 2026
Web Dynpro to SAP Fiori App Modernization AgentLegacy Web-Dynpro-Code in modernes ABAP Cloud-Code umwandelnSpäter 2026

Ein Designprinzip, das SAP explizit kommuniziert: Jeder Agent soll zuerst den bestehenden Code verstehen und erklären, bevor Änderungen vorgeschlagen werden. Das ist sinnvoll — unkontrollierte Massenanpassungen an produktivem Custom-Code wären das Gegenteil eines Effizienzgewinns.

SAP nennt eine Zielsetzung von 40 % Effizienzgewinn in Custom-Code-Transformationsprojekten, basierend auf eigenen frühen Evaluierungen. Unabhängige Benchmarks dazu gibt es nicht. Das ist kein Vorwurf — externe Evaluierungen brauchen Zeit und produktive Einsätze. Aber für Projektbudgets sollte die Zahl als SAP-eigener Richtwert eingeordnet werden, nicht als externe Validierung.

Selbst bei einer deutlich niedrigeren Trefferquote wäre der Einsatz für Migrationsvorhaben mit großem Custom-Code-Anteil sinnvoll: Repetitive, regelbasierte Analyse in großem Umfang ist genau der Anwendungsfall, für den KI in Unternehmensumgebungen am besten geeignet ist — mit Mensch im finalen Review.

Platform Reach: Ältere Releases rücken ins Bild

Eine der praktisch relevantesten Ankündigungen betrifft nicht die neuen Fähigkeiten, sondern den Zugang zu ihnen. SAP Joule for Developers, ABAP AI-Capabilities, wird in Q2 2026 auch für SAP S/4HANA Cloud Private Edition verfügbar — für alle Releases ab 2021.

Bislang war ABAP AI an neuere Releases gebunden. Viele Kunden, die aus lizenz- oder stabilitätsbedingten Gründen auf älteren Releases arbeiten, waren ausgeschlossen. Die technische Grundlage für die Ausweitung ist ein Hub-Service auf SAP BTP, der Authentifizierung, Lizenzverwaltung, SAP BTP AI Core und ABAP-spezifische Geschäftslogik kombiniert. Der Hub kommuniziert direkt mit der IDE — weitgehend unabhängig vom ABAP-Backend-Release.

Was das nicht ändert: Rein On-Premise-Systeme ohne Cloud-Anbindung bleiben ausgeschlossen. Joule ist an RISE- oder GROW-Verträge gebunden. Das ist eine strukturelle Grenze, die SAP mit dieser Ankündigung nicht verschiebt — und die einen realen Wettbewerbsnachteil erzeugt. Anbieter wie Salesforce liefern KI-Funktionen ohne Migrationsvoraussetzung direkt in den Bestand. Wer als SAP-Kunde auf On-Premise sitzt und keine RISE-Migration plant, bekommt von diesem Ankündigungspaket nichts — und hat gleichzeitig Alternativen, die nicht fragen, wo seine Systeme laufen.

Das Preismodell: Transparent — mit Vorbehalt für Agentic Workloads

Ab Q2 2026 endet die Kostenfreiheit. SAP führt ein consumption-basiertes Preismodell für SAP Joule for Developers, ABAP AI-Capabilities, ein — abgerechnet in AI Units.

Das Grundprinzip ist nachvollziehbar: Wer mehr nutzt, zahlt mehr. Keine Pauschalgebühr für eine Funktion, die selten eingesetzt wird. Die Aktivierung erfolgt über SAP for Me; Nutzerzuweisung läuft über Cloud Identity Services. SAP verspricht Echtzeit-Monitoring des Verbrauchs.

Die Herausforderung liegt in der Natur agentischer Workloads: Ein Agent, der Custom-Code in großem Umfang analysiert und transformiert, konsumiert AI Units in einer Menge, die von der Codebasis-Größe, der Iterationstiefe und der Komplexität der Findings abhängt — Faktoren, die sich im Voraus kaum präzise schätzen lassen. Consumption-Pricing ist planbar, solange die Nutzung planbar ist. Bei agentischen Prozessen ist das strukturell schwieriger.

Laut einer Marktanalyse haben aktuell nur rund 3 % der SAP-Kunden Joule in produktivem Betrieb. Der Hauptfaktor dabei: die Bindung an RISE- oder GROW-Verträge, die On-Premise-Kunden vollständig ausschließt. Das neue Preismodell und die erweiterte Platform-Verfügbarkeit adressieren einen Teil dieser Hürde — aber nicht ihre Wurzel.

Einordnung: Was SAP richtig macht — und was noch fehlt

Die Entscheidung, auf MCP als offenem Standard zu setzen, ist strategisch richtig. Statt einer proprietären SAP-Joule-Integration, die Entwickler in ein geschlossenes System zieht, entsteht eine offene Schnittstelle: Agenten-Wahl liegt beim Entwickler. Das macht die ABAP-Plattform langfristig attraktiver — auch für Teams, die primär mit GitHub Copilot, Claude Code oder anderen Tools arbeiten.

Die Language-Server-Architektur hätte früher kommen können. Dass sie jetzt als Fundament für MCP-Integration und IDE-Unabhängigkeit genutzt wird, ist der richtige Einsatz des richtigen Werkzeugs.

Was fehlt:

Governance für autonome Agenten in produktiven ERP-Systemen. Agenten, die Custom-Code in Transportaufträge schreiben, Fiori-Apps umbauen oder massenhaft ATC-Findings automatisch fixen, treffen Entscheidungen in einer Umgebung mit erheblichen Konsequenzen. Der EU AI Act sieht für autonome Systeme in bestimmten Kategorien formale Risikobewertungen vor. SAP adressiert diesen Punkt in den Ankündigungen bisher nicht.

Unabhängige Benchmark-Daten. Der 40-%-Effizienzgewinn ist SAPs eigene frühe Evaluierung. Das ist der Ausgangspunkt für interne Planung, nicht die Grundlage für externe Budgetentscheidungen. Kunden, die Migrationsprojekte auf dieser Basis planen, sollten eigene Piloten durchführen, bevor sie hochrechnen.

Ein vollständiges Angebot für On-Premise. Die Hub-Architektur auf SAP BTP löst das Problem für Private-Edition-Kunden mit Releases ab 2021 teilweise. Für Systeme ohne BTP-Anbindung oder mit älteren Releases bleibt ABAP AI außer Reichweite und das ist weiterhin der größte Schwachpunkt in der AI Strategie der SAP. Joule wird damit weiterhin ein Randsystem bleiben das durch Marketingstrategien künstlich verkrüppelt wird.

Die Ankündigungen vom Sapphire 2026 liefern konkrete Deliverables mit Q2-Terminen — kein Versprechen ohne Datum. Der ABAP MCP Server gibt einem Ökosystem eine offizielle, supportete Schnittstelle, das sich diese Schnittstelle bereits selbst gebaut hatte. VS Code ADT ist ein vierzehn Jahre überfälliger Schritt. Und die Custom-Code-Migration-Agenten adressieren das teuerste Problem in S/4HANA-Projekten mit einem Werkzeug, für das KI tatsächlich gut geeignet ist.

Was der September 2026 an realer Nutzung und Abrechnungsdaten zeigen wird, ist die nächste relevante Datenpunkt in dieser Geschichte.

Quellen

David
David
AI, Apple Silicon, Coding-Experimente, SwiftUI und Haltung.
Weiterlesen