Der Kern AI-nativer Anwendungen ist nicht Codegenerierung, sondern Metadatengenerierung
Codegenerierung beschleunigt Prototypen, aber Unternehmensanwendungen brauchen eine Metadaten-Runtime, in der Objekte, Felder, Beziehungen, Ansichten, Berechtigungen, Workflows, Aktionen und Agent-Tools gemeinsam gesteuert werden.
Kurz gesagt: Eine AI-native Anwendung ist kein Haufen generierten Codes, sondern generierte Metadaten – Objekte, Berechtigungen, Workflows und Agent-Tools unter einer einzigen gesteuerten Runtime. Code wird ausgeführt; die Metadaten sind das, was änderbar und steuerbar bleibt.
Low-Code-Plattformen haben ein klares Problem gelöst: Interne Systeme sollten nicht jedes Mal von null mit Formularen, Seiten, Workflows und Admin-Oberflächen programmiert werden.
AI verschiebt diese Frage nun einen Schritt nach vorn. Wenn Low-Code Anwendungen visuell zusammensetzen kann, kann ein Fachbereich dann eine Anwendung aus einem Satz erzeugen?
Ja, aber der Begriff ist gefährlich, wenn er nur bedeutet: AI schreibt Code. Dann kehren die alten Probleme von Unternehmenssoftware zurück. Die erste Version wirkt schnell. Die zweite Version wird langsam. Seiten funktionieren, aber Berechtigungen sind fragil. Formulare speichern Daten, aber Prozesse sind schwer nachvollziehbar. AI beantwortet Fragen, aber Agents wissen nicht, welche Aktionen erlaubt sind und wann ein Mensch bestätigen muss.
Der Kern einer AI-nativen Anwendungsplattform ist deshalb nicht Codegenerierung, sondern Metadatengenerierung.
Leser interessieren sich weniger für Code als für Änderbarkeit
Aus Sicht von Fachbereich und IT ist die entscheidende Frage selten, ob die erste Version erzeugt werden kann. Wichtiger ist:
- Kann die Anwendung geändert werden, wenn sich das Geschäft ändert?
- Ändern sich Formulare, Listen, Berechtigungen und Workflows mit, wenn ein Feld geändert wird?
- Können alte Datensätze und laufende Prozesse erklärt werden, wenn eine neue Freigaberegel hinzukommt?
- Erbt der AI Agent die Berechtigungen des Benutzers?
- Lässt sich auditieren, wer was gesehen, geändert, bestätigt und genehmigt hat?
- Ist das System in sechs Monaten noch wartbar?
Codegenerierung löst Geschwindigkeit von null auf eins. Metadaten lösen die Struktur für dauerhafte Weiterentwicklung.
Das ist die wichtigste Erfahrung aus Jahren Low-Code: Eine Unternehmensanwendung ist nicht nur eine Sammlung von Seiten. Sie ist ein konfigurierbares, governbares und aktualisierbares Geschäftsmodell.
Warum Codegenerierung in Unternehmensanwendungen aus dem Ruder läuft
Codegenerierung passt gut für Prototypen, kleine Werkzeuge und einmalige Seiten. Sie kann schnell React-Komponenten, APIs, Datenbankschemas und Validierungen erzeugen.
Die Komplexität von Unternehmensanwendungen liegt aber meist in der Konsistenz über mehrere Schichten.
Ein Benutzer sagt zum Beispiel:
Füge Kunden ein Feld „Verlängerungsrisiko“ hinzu und erinnere den Customer-Success-Manager jede Woche bei hohem Risiko.
Als Codegenerierung könnte AI Datenbank, Formular, Liste und einen Zeitplan ändern. Das sieht fertig aus.
In einem echten Geschäftssystem beeinflusst dieses Feld aber auch:
- ob es auf der Kundendetailseite sichtbar ist;
- wer den Risikowert bearbeiten darf;
- ob Manager Teamrisiken sehen;
- ob Exporte das Feld enthalten;
- ob Agents es in Zusammenfassungen verwenden dürfen;
- ob Risikoregeln auditiert werden;
- ob Änderungen Benachrichtigungen auslösen;
- wie spätere Umbenennungen migriert werden.
Wenn diese Logik im Code verstreut ist, wird jede Änderung zu einem kleinen Refactoring. Das System wird schwerer und landet wieder bei klassischer Individualentwicklung.
Metadaten sind die Geschäftssprache der Runtime
Metadaten sind hier mehr als Konfiguration. Sie sind die Sprache, mit der die Runtime das Geschäft versteht.
| Metadatenschicht | Welche Frage sie beantwortet |
|---|---|
| Objekte | Welche Geschäftseinheiten existieren, etwa Kunden, Verträge, Tickets, Aufgaben |
| Felder | Welche Attribute ein Objekt hat, inklusive Typ, Pflichtstatus, Formel und Sensibilität |
| Beziehungen | Wie Objekte durch Referenzen, Rückbezüge und viele-zu-viele Beziehungen verbunden sind |
| Ansichten | Wie Rollen Daten als Liste, Board, Formular, Detail oder Dashboard sehen |
| Berechtigungen | Wer welche Datensätze und Felder sehen, ändern und bedienen darf |
| Workflows | Wie Status wechseln und welche Bedingungen Freigaben oder Automationen auslösen |
| Aktionen | Aufgaben erstellen, Freigaben starten, Berichte erzeugen, Erinnerungen senden |
| Agent-Tools | Was AI abfragen, vorschlagen oder ausführen darf und wann sie stoppen muss |
| Audit | Was AI vorgeschlagen, der Mensch bestätigt und das System ausgeführt hat |
Diese Metadaten steuern UI, API, Berechtigungen, Automation und Agents gemeinsam.
AI Builder sollte Anwendungsspezifikationen erzeugen
Ein reifer AI Builder schreibt nicht sofort Code. Er verhält sich wie ein Business-Architekt für Low-Code und erzeugt zuerst eine Anwendungsspezifikation.
Wenn ein Benutzer ein After-Sales-Ticketsystem anfordert, sollte der Builder zuerst Objekte wie Kunde, Ticket, Nachricht, Wissensbasis, SLA und Eskalation erzeugen; Felder wie Problemtyp, Priorität, Stimmung, Auswirkung und Frist; Ansichten wie Support-Warteschlange und Manager-Dashboard; Rollenrechte; Prozessschritte; Agent-Tools für Zusammenfassung, Klassifikation, Wissensabgleich und Antwortentwurf; sowie Auditpunkte.
Erst nach Bestätigung dieser Spezifikation erzeugt die Plattform Seiten, Datenstrukturen, Automationen und Tool-Aufrufe.
Das ist kaum langsamer als direkt Code zu erzeugen, aber später deutlich stabiler.
Was AI gegenüber klassischem Low-Code verändert
Klassische Low-Code-Plattformen verlangen, dass Nutzer Konfigurationsoberflächen verstehen: Objekt-Designer, Feldpanels, Workflow-Canvas, Berechtigungsmatrizen und Ausdruckseditoren.
AI Builder sollte diese Fähigkeiten nicht ersetzen, sondern die Ausdruckskosten senken.
Der Benutzer muss nicht wissen, welches Panel zu öffnen ist. Er kann sagen:
Lege Hochrisiko-Verträge in ein Legal-Board und füge ab 500.000 eine Finanzprüfung hinzu.
Die Plattform zerlegt diesen Satz in Filter, Ansichten, Workflow-Bedingungen, Freigabeknoten und Berechtigungsänderungen und zeigt einen Änderungsplan zur Bestätigung.
Das ist die echte Verstärkung von Low-Code durch AI: Die Plattform wird nicht zur Blackbox. Geschäftssprache wird direkt in Plattformstruktur übersetzt.
Sechs Prüffragen für einen ernsthaften AI Builder
Bei einer AI-Anwendungsplattform reicht eine schöne generierte Seite nicht. Fragen Sie:
- Erzeugt sie Code oder erklärbare Objekte, Felder, Ansichten, Berechtigungen und Workflows?
- Können Fachanwender die Struktur später per natürlicher Sprache ändern?
- Sind Berechtigungen eine einheitliche Runtime-Fähigkeit?
- Greifen Agents nur über kontrollierte Tools auf Daten zu?
- Werden AI-Vorschläge, menschliche Bestätigung und Systemaktionen auditiert?
- Ändert das System bei neuen Regeln Metadaten oder generiert es Code neu?
Diese Antworten entscheiden, ob es ein Demo-Werkzeug oder eine Unternehmensplattform ist.
Der Unterschied von ObjectStack
ObjectStack richtet sich darauf aus, natürliche Sprache in Metadaten zu übersetzen und diese Metadaten die Runtime steuern zu lassen.
Eine Anforderung erzeugt Objekte, Felder, Beziehungen, Ansichten, Berechtigungen, Workflows, Aktionen und Agent-Tools. Nach dem Start der Anwendung können Fachanwender sie weiter per natürlicher Sprache ändern. Agents arbeiten innerhalb derselben Objekt-, Berechtigungs- und Aktionsgrenzen.
Code existiert weiterhin, sollte aber nicht alle Geschäftsänderungen tragen. Geschäftsstruktur muss in die Metadatenschicht, damit sie erzeugt, verstanden, geändert, gesteuert und auditiert werden kann.