Von 600 Zeilen React zu 40 Zeilen JSON
Ein Lieferanten-Onboarding-Bildschirm, den wir letzten Monat migriert haben, hat 37 Felder, vier bedingte Abschnitte, drei Freigabepfade und einen Drill-through zu einer Vertragsdetailansicht. Die ursprüngliche Oracle Forms-Version umfasste ungefähr 2.400 Zeilen PL/SQL und Formularlogik. Eine handgeschriebene React-Portierung kam auf 610 Zeilen in sechs Dateien. Der DEX-Deskriptor hat 43 Zeilen JSON.
Der Deskriptor ist nicht kürzer, weil wir Features gestrichen haben. Er ist kürzer, weil die Laufzeitumgebung alles übernimmt, was sich zwischen Bildschirmen nicht ändert.
Was die Laufzeitumgebung tatsächlich leistet
Die Laufzeitumgebung ist die langweiligen 90 %. Authentifizierung gegen den unternehmenseigenen IdP. RBAC-Durchsetzung auf jedes Feld und jede Aktion. Audit-Logging in einem Format, das SOX-Prüfer bereits lesen können. Formular-Validierung mit denselben Fehlermeldungen auf Client und Server. Lokalisierung. Tastaturnavigation. Optimistische Updates mit Rollback. Export nach Excel. Drucklayouts. Barrierefreiheit bis zum Fokus-Ring.
Nichts davon gehört in einen Deskriptor. Es dort unterzubringen würde jeden Bildschirm zum Risiko machen. Die Laufzeitumgebung erledigt es einmalig, in TypeScript, in Code, den wir besitzen und testen.
Das Deskriptor-Schema
Ein Deskriptor hat fünf Top-Level-Abschnitte: data, layout, logic, integrations und access. Jeder wird vor dem Rendern gegen ein JSON Schema validiert. Der Validator läuft im Browser, in der Build-Pipeline und in der Tool-Use-Schleife des LLM, sodass fehlerhafte Deskriptoren immer an derselben Stelle scheitern.
Der data-Abschnitt benennt Entitäten und Felder aus der semantischen Schicht. Der layout-Abschnitt beschreibt Regionen, nicht Pixel. Der logic-Abschnitt deklariert Regeln — „Freigabe erforderlich, wenn Betrag den Schwellenwert überschreitet” — statt imperativem Code. Integrations referenzieren benannte Endpunkte aus einem OpenAPI-Dokument. Access referenziert Rollen aus dem RBAC-System.
Nichts im Deskriptor ist ein Freitext-String, den die Laufzeitumgebung heuristisch interpretieren müsste. Jede Referenz löst sich in etwas auf, das die Laufzeitumgebung bereits kennt.
Warum wir nicht zuerst einen visuellen Editor gebaut haben
Das naheliegende Produkt für diese Architektur ist ein Drag-and-Drop-Builder. Wir haben bewusst zuerst die Laufzeitumgebung und das Deskriptor-Schema gebaut, mit einem reinen Texteditor als einziger Authoring-Oberfläche, und dann KI-Generierung hinzugefügt, bevor wir einen visuellen Editor ergänzt haben.
Der Grund ist unspektakulär. Ein visueller Editor beschränkt, was Sie ausdrücken können, auf das, was der Editor zeichnen kann. Ein Schema beschränkt, was Sie ausdrücken können, auf das, was die Laufzeitumgebung ausführen kann. Die zweite Einschränkung ist die, die für Produktionssysteme zählt. Wenn das Schema stimmt, ist der visuelle Editor eine einfache Aufgabe. Wenn das Schema falsch ist, kaschiert der visuelle Editor das Problem, bis ein Kunde auf einen Randfall stößt, den der Editor nie angezeigt hat.
Erweiterungspunkte
Jeder Enterprise-Bildschirm hat mindestens eine Sache, die der Deskriptor nicht ausdrücken kann. Eine benutzerdefinierte Berechnung. Ein alter SOAP-Endpunkt, den niemand anfassen will. Ein regulierungsspezifisches Widget. Die Laufzeitumgebung behandelt diese über benannte Erweiterungspunkte — TypeScript-Module, die der Deskriptor namentlich referenziert.
Das hält den Deskriptor deklarativ und lässt gleichzeitig Notausgänge für die Realität offen. Wir haben festgestellt, dass ungefähr 5 % der Bildschirme eine Erweiterung benötigen, und diejenigen, die es tun, benötigen in der Regel genau eine. Die anderen 95 % bleiben reines JSON.
Was uns das kostet
Jede Architekturentscheidung hat ihren Preis. Unserer ist die Laufzeitumgebung selbst. Sie ist ein nicht-triviales Stück TypeScript, das sorgfältig gewartet, getestet und versioniert werden muss, weil jeder Bildschirm im Produktivbetrieb davon abhängt. Ein Fehler in der RBAC-Durchsetzungsschicht ist ein Fehler in jedem Bildschirm gleichzeitig.
Wir behandeln die Laufzeitumgebung so, wie ein Datenbankhhersteller seinen Query-Planner behandelt. Konservative Releases. Umfassende Regressionssuiten. Abwärtskompatibilität des Deskriptor-Schemas gemessen in Jahren, nicht in Sprints. Das ist der Preis dafür, dass die Deskriptoren günstig sind.
Die Quintessenz
JSON-Deskriptoren sind kein Trick. Sie sind eine Arbeitsteilung. Die Laufzeitumgebung übernimmt die Teile, die jedes Mal stimmen müssen. Der Deskriptor übernimmt die Teile, die sich pro Bildschirm ändern. Das LLM schreibt den Deskriptor. Der Prüfer liest den Deskriptor. Der Nutzer sieht eine Produktionsoberfläche, die sich wie Unternehmenssoftware verhält, weil Unternehmenssoftware genau das ist, wofür die Laufzeitumgebung gebaut wurde.