Effiziente domänenspezifische Modellierung mit KI-Agenten, MPS und Portalon

Im Laufe dieses Jahres sind nicht nur LLMs mächtiger geworden, sondern auch Portalon, unser MCP-Server für MPS. Eine praktische domänenspezifische Sprache (DSL) für die Projektplanung, mit Scoping, Zyklenerkennung, Scheduling-Algorithmus, Beispielmodellen und 28 Tests: Mit Portalon 1.5 erstellt ein KI-Agent all das in einem leeren MPS-Projekt in unter zehn Minuten, ohne zusätzliche Skills. Der dabei erzeugte Code wirkt, als hätte ihn ein Entwickler mit viel MPS-Erfahrung geschrieben; die generierten Tests waren beim ersten Lauf vollständig grün. Die frei verfügbaren Alternativen benötigten für dieselbe Aufgabe circa 70 bis 90 Prozent länger.

Im Juli 2026 haben wir Portalon in diesem Blog vorgestellt, damals in Version 0.8. Portalon ist ein MPS-Plugin von itemis, das KI-Agenten wie Claude Code über das Model Context Protocol mit dem laufenden Modell eines JetBrains-MPS-Projekts verbindet. Den Hauptnutzen hatten wir seinerzeit bei analyseorientierten Aufgaben gesehen und offen geschrieben, dass die Implementierung kompletter Tool-Features noch nicht das Niveau textueller Sprachen erreicht. Diese Lücke hat sich seitdem deutlich verkleinert. Wir bei itemis und unsere Kunden setzen Portalon in realen Projekten ein, und die Erfahrungen daraus sind direkt in die Weiterentwicklung eingeflossen. In diesem Artikel werden die wichtigsten Verbesserungen in Performance, Funktionalität und Infrastruktur vorgestellt, gefolgt von den Anwendungsfällen, für die Portalon heute eingesetzt wird.

Was gleich geblieben ist

Die Designziele für Portalon sind seit den frühen Releases konstant geblieben:

• IDE und headless – Anwender und Agent kooperieren interaktiv in der IDE. Lang laufende Aufgaben lassen sich mit einer headless betriebenen MPS-Instanz ausführen.
• Alle Rollen unterstützen – Nutzer der DSLs, Entwickler und Language Engineers, jeweils lesend oder schreibend.
• Eine Codebasis, viele MPS-Versionen – eine große Bandbreite an MPS-Versionen wird unterstützt.
• Gut genug ohne Zusatzaufwand – der Agent soll bereits ohne zusätzliche Skills und ohne DSL-spezifische Instruktionen produktiv arbeiten können.
• Automatische Evaluierung – Tools zum Bauen, Prüfen und Testen, damit der Agent seine eigene Arbeit verifizieren und iterativ verbessern kann.
• Token-Effizienz – Optimierung von Roundtrips, effiziente Code-Erstellung.

Insbesondere die letzten drei Ziele sind für die folgenden Ergebnisse wichtig. Bei den unten angegebenen Benchmark-Läufen hat der Agent ausschließlich über Portalon mit MPS gearbeitet, ohne projekt- oder aufgabenspezifische Skills.

Performance: Wall-Clock-Zeit und Token-Bedarf

Bei der Arbeit mit Agenten dominieren zwei Größen. Die Wall-Clock-Zeit bestimmt, wie lange ein Nutzer oder ein Language Engineer auf das Ergebnis seines Prompts wartet; der Token-Bedarf bestimmt letztendlich die Kosten. Unsere Analysen zeigen, dass die Rechenzeit des MCP-Servers dabei praktisch keine Rolle spielt. Portalon antwortet fast immer in deutlich unter einer Sekunde. Die Zeit vergeht in der Inferenz des LLM, und zwar über alle LLM-Anfragen (sog. Turns) der Agenten-Session hinweg. Eine schnellere Schnittstelle ist daher vor allem eine, mit welcher der Agent weniger Turns benötigt und pro Turn weniger lesen, nachdenken und schreiben muss.

Der Benchmark-Prompt zur eingangs erwähnten Projektplanungs-DSL ist ursprünglich als Demo-Beispiel für meinen Vortrag auf der Konferenz LangDev 2026 entstanden. Die Aufgabe für den Agenten umfasste die Sprachstruktur mit Projekten, Bearbeitern, Tasks und ihren Abhängigkeiten, sauberes Scoping, die Erkennung von Abhängigkeits-Zyklen, einen Scheduling-Algorithmus mit Ergebnis-Cache, automatisch berechnete Ergebnis-Zellen im Editor, eine Sandbox mit Beispiel-Modellen sowie eine Test-Solution mit circa 20 Tests. Mit Portalon 1.0 hat der Agent dafür etwa 13 Minuten benötigt. Mit Portalon 1.5 sind es heute unter 10 Minuten, und alle 28 vom Agenten geschriebenen Tests waren beim ersten Lauf erfolgreich. Zu beachten ist, dass Portalon auf MPS 2025.1 und MPS 2026.1 praktisch identische Ergebnisse liefert (9:24 bzw. 9:43 Minuten); dies bestätigt das Designziel einer Codebasis für viele MPS-Versionen.

Mit derselben Aufgabe haben wir Portalon im November in einem Benchmark mit zwei anderen Agenten-Anbindungen für MPS verglichen, beide frei verfügbar. Dies sind zum einen der MCP-Server, der als Open Source mit MPS mitgeliefert wird, und zum anderen das Open-Source-CLI mops, das den Agenten über Kommandozeilenaufrufe mit einer headless betriebenen MPS-Instanz verbindet. Agent, Modell, Effort-Stufe und MPS-Version waren in allen Läufen identisch (Claude Code mit Opus 5.5, Effort medium, MPS 2026.1). Die beiden Open-Source-Werkzeuge durften ihre jeweils mitgelieferten Skills nutzen; Portalon arbeitete ohne Skills, nur mit seinen eingebauten Instruktionen. Die folgende Tabelle zeigt die wichtigsten Kennzahlen:

Bei den Kosten-Kennzahlen in der Tabelle liegt Portalon damit vorn, beim gelesenen Kontext allerdings nur knapp vor mops. Das zweitschnellste Werkzeug benötigte rund 70 % mehr Zeit; der MCP-Server aus MPS benötigte mehr als doppelt so viele Turns. Die vollständige Auswertung mit weiteren Kennzahlen stellen wir auf Anfrage gern zur Verfügung.

Einen großen Anteil an diesem Ergebnis hat die Effizienz bei der automatischen Erzeugung von Code in BaseLanguage, dem Java-Dialekt von MPS (mehr dazu im nächsten Abschnitt). Frühe Versionen von Portalon ließen den Agenten solchen Code als JSON-Repräsentation des Syntaxbaums schreiben. Seit Portalon 1.0 schreibt der Agent textuelles Java, einschließlich der MPS-Erweiterungen wie node<C> oder list<T>. Portalon übersetzt diesen Text in passende Syntaxbäume. In unseren Benchmarks sank dadurch bei gleichem Modell und gleicher Aufgabe die Menge an Tool-Input, die der Agent schreiben musste, signifikant. In einem typischen Benchmark sanken Laufzeit und Kosten auf etwa ein Drittel.

Bereits seit Version 1.0 bietet Portalon außerdem als weitere Performance-Optimierung eine Schnittstelle nach dem Prinzip Code Mode an. Dabei ruft der Agent nicht einzelne MCP-Tools nacheinander auf, sondern schreibt ein kurzes Programm in Python oder TypeScript, das über mitgelieferte Clients auf Portalon zugreift. Das lohnt sich bei komplexen Anfragen, die viele Knoten betreffen, etwa bei der Frage nach der Verteilung der Methodenanzahl über alle Klassen eines großen Projekts. Mit einzelnen Tool-Aufrufen wäre dafür eine lange Folge von Turns nötig; im Code Mode genügt ein einziges Skript, und nur das verdichtete Ergebnis gelangt in den Kontext des Agenten. Im obigen Benchmark war der Code Mode bei Portalon allerdings deaktiviert; die gezeigten Ergebnisse beruhen also allein auf den einzelnen MCP-Tools.

Funktionalität: Code wie vom erfahrenen Language Engineer

Geschwindigkeit bei der Erstellung allein genügt nicht; der erzeugte Code muss auch langfristig wartbar sein. Ein wesentlicher Schwerpunkt der Weiterentwicklung war daher die Erzeugung von idiomatischem BaseLanguage-Code. BaseLanguage ist die Java-ähnliche Sprache, mit der in MPS große Teile einer DSL implementiert werden, z.B. Verhalten, Constraints oder Editor-Funktionen. Sie bietet eigene Konstrukte für den Umgang mit Modellen, v.a. die smodel-Sprache für den Zugriff auf Knoten und die Collections-Sprache. Wer diese Konstrukte nutzt, erhält kompakten und gut lesbaren Code, der sich nahtlos in die MPS-Werkzeuge einfügt.

Agenten tendieren ohne besondere Maßnahmen dazu, Plain Java zu schreiben, also Code, der zwar funktioniert, aber die Java-Spracherweiterungen von MPS nicht nutzt. Das Benchmark-Ergebnis zeigt das recht deutlich. Mit dem in MPS mitgelieferten MCP-Server hat der Agent den Scheduling-Algorithmus und anderen Code des Benchmarks vorwiegend als Plain Java generiert. Mit dem mops-CLI entstand ebenfalls Plain Java; die Knoten werden dort über die Open API anhand von Property- und Rollennamen als Strings gelesen, was nicht refactoring-sicher ist.

Mit Portalon ist der gesamte erzeugte Code idiomatisches BaseLanguage, vom Scheduling-Algorithmus über Scoping und Checking Rules bis hin zu den Tests. Der erzeugte Code wirkt so, als hätte ihn ein erfahrener Language Engineer geschrieben. Für unsere interne Arbeit und unsere Kunden ist das ein wichtiger Vorteil, denn der Code eines Agenten wird anschließend von Menschen gelesen, reviewt und weiterentwickelt.

Infrastruktur: Bereit für reale Umgebungen

Ein Werkzeug, das auf dem Arbeitsplatzrechner eines einzelnen Entwicklers gut funktioniert, ist noch nicht unbedingt für den Einsatz in einer Unternehmensumgebung geeignet. Portalon unterstützt daher inzwischen Sicherheitsmechanismen, die einen solchen Einsatz erlauben. Die Verbindung zwischen Clients und Portalon lässt sich mit Bearer Tokens absichern, sodass nur autorisierte Agenten und Clients auf das MPS-Modell zugreifen können, auch wenn MPS headless auf einem Server läuft. Darüber hinaus lässt sich über Settings steuern, welche Zugriffe erlaubt sind. Ein Read-only-Modus beschränkt den Agenten auf lesende Operationen. Für Anwender, die DSLs nur nutzen, aber nicht DSLs entwickeln oder das Tool selbst ändern sollen, lassen sich außerdem die Language-Engineering-Werkzeuge abschalten.

Wofür Portalon heute eingesetzt wird

Mit diesen Verbesserungen hat sich das Spektrum der Aufgaben, die wir und unsere Kunden mit Portalon erledigen, deutlich verbreitert:

• Language-Engineering-Aufgaben – die Entwicklung neuer Features in bestehenden Sprachen bis hin zu komplett neuen DSLs, Refactorings sowie das Erstellen und Erweitern von Testsuites.
• Komplexes Debugging – die Ursachenanalyse für Fehler, die sich über mehrere Sprachaspekte wie Struktur, Typsystem und Generator verteilen und erst zur Laufzeit sichtbar werden.
• Architektur- und Design-Analysen – die Untersuchung großer MPS-Projekte auf Abhängigkeiten, Inkonsistenzen und Verbesserungspotenzial.

Querschnittliche Aufgaben wie Pull-Request-Erstellung, Reviews oder Modell-Migrationen werden natürlich ebenfalls erleichtert. Der Agent hat mit Portalon auch die Möglichkeit, mit mehreren geöffneten Projekten gleichzeitig zu arbeiten. Dies hilft insbesondere bei der Bearbeitung von Aufgaben über mehrere Projekte hinweg, wie man sie z.B. bei der Pflege von Plattformkomponenten antrifft.

Ein weiterer interessanter Anwendungsfall ist die Übertragung von DSLs und Modellen aus alten MPS-Versionen. Dafür arbeitet ein Agent mit zwei Portalon-Instanzen gleichzeitig. Die eine läuft in der alten MPS-Version und dient als Quelle, die andere läuft in der aktuellen Version und dient als Ziel. Ohne den traditionellen Weg über eine manuelle Migration des alten Modells liest der Agent DSLs und Modelle aus dem Quellprojekt und baut diese im Ziel neu auf. Dieses pragmatische Vorgehen setzen wir intern und bei Kunden immer wieder ein.

Schließlich eignet sich Portalon als Baustein für kundenspezifische Agenten. Eine gängige Architektur aus unserer Projektpraxis kombiniert ein Open-Source-LLM, eine Web-Oberfläche und eine headless betriebene MPS-Instanz mit Portalon zu einer lokalen agentischen Lösung im Intranet. Fachanwender können mit dieser Lösung in natürlicher Sprache mit ihren MPS-Modellen interagieren, also z.B. Fragen zu den Modellen stellen, Änderungen durchführen oder Auswertungen anstoßen, ohne die MPS-IDE zu öffnen und ohne dass Daten das Unternehmen verlassen. Die oben beschriebenen Zugriffsbeschränkungen sind dafür eine wichtige Voraussetzung. Solche Lösungen bauen wir als Teil unserer Custom-Tools-Projekte gemeinsam mit unseren Kunden auf.

Maßgeschneiderte Werkzeuge zu überschaubaren Kosten

Mit den gezeigten Verbesserungen verändern LLMs, KI-Agenten und Portalon das Language Engineering mit MPS grundlegend. Ein großer Teil der Implementierungsarbeit, der bisher erhebliche Projektzeit gebunden hat, lässt sich heute zuverlässig an einen Agenten delegieren. Language Engineers werden dadurch allerdings nicht ersetzt. Sie geben die Richtung vor, beurteilen die Ergebnisse und treffen die Designentscheidungen. Von Routinearbeit entlastet, können sie sich stärker auf Innovationen und konzeptionelle Arbeit konzentrieren und darauf, dass ein Custom Tool die Bedürfnisse seiner Anwender noch genauer abbildet.

Dies betrifft auch eine Grundsatzentscheidung, vor der viele Unternehmen immer wieder stehen. Gegen eine maßgeschneiderte Werkzeuglösung wurden bisher oft die initialen Entwicklungskosten angeführt; man solle sich daher besser mit den Einschränkungen eines Werkzeugs von der Stange abfinden. Dieses Argument verliert nun weitgehend an Gewicht. Mit KI-Agenten und Portalon lassen sich optimal angepasste Werkzeuge zu überschaubaren Kosten entwickeln. Gleichzeitig werden innovative Anwendungsfälle möglich, die sich mit generischen Werkzeugen nur schlecht umsetzen ließen, z.B. die oben beschriebene natürlichsprachliche Interaktion mit MPS-Modellen im Intranet.

Fazit

Portalon hat sich seit der ersten Vorstellung von einem vielversprechenden Werkzeug für Analysen zu einer Grundlage für professionelles Language Engineering mit KI-Agenten entwickelt. Der Agent kann damit effektiv arbeiten und erzeugt Lösungen, die den Konventionen erfahrener Language Engineers folgen. Mit den neuen Sicherheitsmechanismen ist Portalon zudem bereit für den Einsatz in realen Unternehmensumgebungen. Damit werden maßgeschneiderte Werkzeuge auch dort wirtschaftlich, wo bisher ein Kompromiss mit Werkzeugen von der Stange die naheliegende Wahl war. Wir entwickeln Portalon auf Basis der Erfahrungen aus unseren Projekten konsequent weiter.

Wenn Sie mehr über Portalon oder speziell über den Benchmark erfahren möchten, sprechen Sie mich gern direkt an, per E-Mail an kbirken@itemis.de oder über LinkedIn. Einen Einblick hinter die Kulissen der Optimierung gibt außerdem die Aufzeichnung meines LangDev-Vortrags. Stay tuned!

Custom Tools bei itemis — Individuelle Werkzeuge für Ihre modellbasierte Entwicklung: Custom Tool Development →