Eine App bauen war nie das Problem. Sie zu betreiben schon. Login. Rechte. Hosting. Monitoring. Sicherheitsprüfungen. Deployment. Was bei einer internen Anwendung oft nach dem eigentlichen Build beginnt, kostet Teams Zeit, Geld und Nerven. Genau dieser Teil verändert sich gerade.
Mit Power Apps Code Apps entwickelst du eine ganz normale moderne Web-App mit React, TypeScript und Vite. Und dabei veröffentlichst du sie mit einem Befehl in die Power Platform, wo Anmeldung, Freigabe, Verwaltung und Monitoring schon vorhanden sind. Parallel dazu gibt es mit Generative Pages in model-driven Apps eine Funktion, mit der du eine App-Seite beschreibst und daraus einen echten React-Code erhältst. Das Entscheidende daran ist nicht, dass Microsoft jetzt auch KI kann. Oder dass React plötzlich in Power Apps auftaucht. Die Grenze zwischen Low-Code und klassischer Softwareentwicklung fällt gerade auseinander. Und zwar von beiden Seiten gleichzeitig.
In der Power Platform gibt es seit Jahren eine unsichtbare Trennlinie. Auf der einen Seite Low-Code. Schnell, governt, aber irgendwann stösst du an die Grenze dessen, was sich mit Standardkomponenten abbilden lässt. Auf der anderen Seite klassische Webentwicklung: Volle Freiheit, aber jedes Projekt beginnt bei null (Authentifizierung, Rollenmodell, Hosting, Deployment-Pipeline, Logging). Und am Ende die unangenehme Frage aus der IT-Sicherheit: Wer hat das eigentlich geprüft?
Was gerade passiert, ist bemerkenswert: Die Trennung zwischen Low-Code und «richtiger» Entwicklung war schon immer künstlicher, als wir gerne zugegeben haben. 2026 fällt sie nun endgültig auseinander.
Von der Code-Seite kommen Code-Apps, mit denen Entwickler in ihrer gewohnten IDE arbeiten, aber in der Power Plattform landen. Von der Low-Code-Seite kommen Generative Pages, die aus einer Beschreibung produktionsnahen TypeScript- und React-Code erzeugen. In der Mitte treffen sich beide bei React-Komponenten, die in einer verwalteten Unternehmensumgebung laufen.
Microsoft beschreibt Code-Apps sinngemäss so: Power Apps-Fähigkeiten in eigene, code-first entwickelte Webapplikationen bringen. Du entwickelst lokal. Du verwendest bekannte Frameworks wie React oder Vue. Du hast volle Kontrolle über UI und Logik. Und trotzdem läuft die Anwendung anschliessend innerhalb der Power Platform.
Eine Beschreibung aus der Community bringt es auf den Punkt: Die erste Code-App ist «a regular modern web app that becomes a managed Power Platform app». Kein eingeschränkter Baukasten, kein «geht leider nicht, weil die Komponente das nicht kann». Ist ein Design-System vorgegeben, wird es umgesetzt. Muss eine Interaktion speziell sein, wird sie gebaut. Das ist Webentwicklung.
Model-driven Apps waren immer die solide, unaufgeregte Seite der Power Platform: datenmodellgetrieben, konsistent, governt und optisch sehr standardisiert. Wer eine wirklich eigene Ansicht brauchte, landete schnell bei Custom Pages oder bei einem Kompromiss.
Generative Pages setzen hier an. Und nein: Das ist nicht einfach «KI baut mir schnell eine hübsche Seite». Die spannendere Entwicklung ist eine andere. Eine der klassischen Grenzen der Power Platform wird durchlässig. Bisher galt oft: Entweder du akzeptierst die Standardoberfläche oder du verlässt die Welt der Standardoberfläche und baust selbst. Generative Pages bewegen sich dazwischen.
Du beschreibst in natürlicher Sprache, was du brauchst, benennst die relevanten Dataverse-Tabellen und kannst sogar ein Bild anhängen, wie die Seite aussehen soll, bis hin zu einer, im Wortlaut von Microsoft «rough napkin sketch».
Daraus wird ein React-Code generiert, der sowohl das Frontend-Erlebnis abdeckt – Auswahl der passenden Komponenten, bestes Layout – als auch die zugehörige Business-Logik. Danach geht es im Dialog weiter: Elemente lassen sich verändern, Layouts anpassen und Funktionalitäten erweitern.
Wichtig für alle, die Governance ernst nehmen: Generative Pages sind solution-aware. Sie erscheinen als «UX Agent Project»-Zeilen und lassen sich zwischen Umgebungen exportieren und importieren. Der normale ALM-Prozess greift also. Und bevor Nutzende eine Seite sehen, müssen sie explizit publiziert werden. Es rutscht nichts versehentlich in Produktion. Und die Seiten sind keine Inseln: Sie nehmen Input-Parameter entgegen und werden über die reguläre model-driven Navigation aufgerufen. Echte Bausteine im Fluss der App, nicht ein hübsches Anhängsel.
Generative Pages gibt es auch direkt im Browser innerhalb des App Designers. In der Praxis ist dieser Weg aber regional beschränkt und für uns in Europa aktuell keine Option. Der interessante Weg ist ohnehin der andere und Microsoft nennt ihn ausdrücklich den empfohlenen: die Arbeit aus der Entwicklungsumgebung mit KI-Code-Tools wie der GitHub Copilot CLI oder Claude Code.
Die Gründe sind handfest: Zugriff auf die neuesten Frontier-Modelle, weltweite Verfügbarkeit in Public Clouds und du kannst in einem einzigen Durchlauf mehrere Seiten plus die dazugehörigen Dataverse-Tabellen bauen. Die Funktion selbst ist inzwischen global verfügbar.
Dahinter steckt ein orchestriertes Vorgehen: Ein Planner-Agent analysiert die Anfrage und schlägt einen Plan vor – welche Seiten, welche Tabellen, welche App, welche Solution – und delegiert dann an spezialisierte Agenten wie einen Table Builder und einen Page Builder, die produktionsnahen TypeScript- und React-Code erzeugen. Optional gibt es einen «verify-in-browser»-Schritt mit automatisch generierten Playwright-Tests.
Auch der Sprachaspekt ist auf diesem Weg gelöst: Der Agent erkennt alle in der Umgebung aktivierten Sprachen und generiert entsprechenden Code. Die Seite respektiert danach die individuellen Regionaleinstellungen für Datum, Zahlen und Währung.
Model-driven Apps bringen heute nicht nur generierte Seiten mit. Mit Copilot Chat können Endnutzer Fragen in natürlicher Sprache zu den Daten ihrer Anwendung stellen und direkt Antworten erhalten. Dazu kommt die Form-Fill-Assistenz, die bei komplexen Formularen Vorschläge auf Basis des vorhandenen Datenkontexts macht. Für Dynamics 365 Nutzer sind diese Funktionen allgemein verfügbar und standardmässig aktiviert. Für Standalone Power Apps befinden sich beide weiterhin in Public Preview und müssen im Power Platform Admin Center aktiviert werden. Die Richtung ist trotzdem klar: Die Oberfläche wird nicht nur generativer. Die Anwendung selbst wird zunehmend dialogfähig.
Die häufigste Frage in Workshops lautet nicht «Was kann die Plattform?», sondern «Was nehme ich wofür?». Microsoft hat an der European Power Platform Conference 2026 in Kopenhagen eine Landkarte gezeigt, die das gut sortiert.
Von oben nach unten gibst du Führung ab und gewinnst Freiheit. Alles ausser Power Pages BYOC ist für interne Nutzende gedacht. Wer eine anonym erreichbare Oberfläche braucht, ist auf dieser Landkarte ganz rechts.
An derselben Konferenz haben Vivian Voss und Yannick Reekmans eine Tabelle gezeigt, die ich für die brauchbarste Entscheidungshilfe zum Thema halte. Sie stellt nicht die Frage «Was ist möglich?», sondern «Was geht schief, wenn ich mich falsch entscheide?».
Zwei Dinge fallen daran auf:
Zweimal lautet die Antwort «Standardformular» oder «Canvas + PCF». Die neuen Möglichkeiten sind nicht automatisch die richtige Antwort. Die häufigste Fehlentscheidung ist nicht «zu wenig Technik», sondern zu viel.
Die Spalte mit den Fehlermodi ist der eigentliche Wert. Generative Page, wenn du im Kontext der model-driven App bleiben und ihr Sicherheitsmodell erben willst. Code App, wenn die Anwendung eigenständig sein soll, mehr als Dataverse braucht oder das Frontend als echtes Engineering-Artefakt behandelt werden muss.
Und häufig ist die richtige Antwort nicht «entweder-oder», sondern: die Fachanwendung als model-driven App, die anspruchsvolle Spezialansicht als Generative Page, die eigenständige Oberfläche als Code App. Alle drei in derselben Umgebung, unter demselben Rechtemodell.
Ein Beitrag, der nur schwärmt, hilft dir bei der Planung nicht. Diese Punkte gehören auf den Tisch:
Der generierte Code ist nicht automatisch produktionsreif oder konform mit den Standards deiner Organisation. Microsoft formuliert das ungewöhnlich klar: Der Agent unternimmt einen «best-effort attempt», vollständigen, produktionsreifen Code inklusive Accessibility- und Security-Best-Practices zu erzeugen. Die Verantwortung für die Validierung bleibt trotzdem beim Team. Er muss getestet und überprüft werden, bevor er publiziert wird. Das ist kein Nachteil, sondern ein normaler Review-Schritt, wie bei jedem Code.
Technische Randbedingungen bei Generative Pages: ausschliesslich Dataverse als Datenquelle, maximal sechs Tabellen pro Seite, kein gleichzeitiges Arbeiten mehrerer Maker an derselben Seite, sowie Prompt-Limit von 50'000 Zeichen. Das sind keine Gründe, die Funktion nicht zu nutzen. Aber sie gehören in die Architekturentscheidung.
Code Apps müssen in der Umgebung freigeschaltet sein – das ist eine Admin-Handlung, keine Selbstbedienung. Auch das Tooling entwickelt sich weiter. Neben den bisherigen pac code-Befehlen gibt es eine neuere npm-basierte CLI, die diese künftig ablösen soll. Microsofts aktuelle Quickstarts arbeiten bereits mit den neuen Befehlen. Ein Migrationspfad ist dokumentiert. Wer heute startet, sollte diese Entwicklung kennen.
Lizenzen: Für diese Szenarien wird Power Apps Premium benötigt. Andere Lizenzformen reichen für diese Szenarien nicht. Premium kostet 20 USD pro User und Monat (12 USD ab 2'000 neuen User-Lizenzen) und berechtigt zum Bauen und Ausführen unbegrenzt vieler Apps. Für einen Machbarkeitsnachweis vorab gibt es den kostenlosen Developer Plan.
React konnten wir vorher schon. KI konnte vorher schon Code generieren. Und Low-Code konnte vorher schon Anwendungen bauen. Die eigentliche Veränderung passiert dazwischen. Klassische Entwicklung zieht in die Power Platform ein. Gleichzeitig verlässt Low-Code seine bisherigen Grenzen. Dadurch entsteht eine neue Architekturfrage. Nicht mehr: Low-Code oder Pro-Code? Sondern: Was wollen wir selbst bauen und was soll die Plattform für uns übernehmen? Das ist aus unserer Sicht die wirklich interessante Entwicklung. Denn eine interne Anwendung muss nicht mehr automatisch bei null anfangen.
Die Grenze verschwindet. Und damit wird nicht alles einfacher. Aber die Möglichkeiten werden deutlich besser.