Low-Code-Plattformen und die Zukunft der Softwareentwicklung

Werden Entwickler überflüssig, wenn Fachabteilungen ihre Apps selbst bauen? Was Low-Code-Plattformen für IT und Softwareentwicklung wirklich verändern

In vielen IT-Abteilungen sieht die Lage ähnlich aus: Die Liste der Wünsche aus den Fachbereichen ist lang, die Zahl der Entwickler begrenzt, und neue Fachkräfte sind schwer zu finden. Laut Branchenverband Bitkom fehlten 2026 in Deutschland rund 79.000 IT-Fachkräfte – etwa halb so viele wie 2023, aber noch immer Zehntausende. Gleichzeitig soll alles schneller gehen: neue Abläufe digitalisieren, Daten nutzbar machen, Kunden besser bedienen.

Low-Code-Plattformen versprechen einen Ausweg. Fachabteilungen bauen einfachere Anwendungen selbst, Entwickler kommen mit vorgefertigten Bausteinen schneller voran. Was Low-Code und No-Code grundsätzlich sind und worin sie sich unterscheiden, erklärt der Grundlagenbeitrag No-Code und Low-Code: Was dahintersteckt. Hier geht es um die Sicht der IT: Was ändert sich an der Arbeit der Entwickler, wie lässt sich die Entwicklung außerhalb der IT steuern, und wie passen Low-Code und KI-Code-Assistenten zusammen?

Was Low-Code an der Arbeit der Entwickler ändert – und was nicht

Ein großer Teil der Unternehmenssoftware besteht aus immer gleichen Mustern: Daten erfassen, prüfen, speichern, anzeigen, freigeben, weiterleiten. Wer solche Anwendungen klassisch programmiert, schreibt viel Code, der mit dem eigentlichen Fachproblem wenig zu tun hat – Anmeldung, Formularvalidierung, Datenbankzugriff, Darstellung auf verschiedenen Geräten. Low-Code-Plattformen liefern diese Grundlagen fertig mit. Die Entwicklung verschiebt sich vom Schreiben solcher Routinen hin zum Modellieren von Daten, Abläufen und Regeln.

Das verändert die Rolle der Entwickler, ersetzt sie aber nicht. Ihre Arbeit wandert an andere Stellen:

• Plattformarchitektur: Jemand muss entscheiden, welche Plattform eingesetzt wird, wie Umgebungen für Entwicklung, Test und Betrieb aufgebaut sind und wie Daten fließen.
• Schnittstellen: Low-Code-Anwendungen leben von Anbindungen an ERP, CRM, Personal- und Fertigungssysteme. Diese Anbindungen zu bauen, abzusichern und zu warten, bleibt Entwicklerarbeit.
• Wiederverwendbare Bausteine: Entwickler schreiben Komponenten und Konnektoren, die Fachanwender dann ohne Code nutzen.
• Qualität und Betrieb: Tests, Versionsverwaltung, Überwachung und Fehleranalyse brauchen auch in der Low-Code-Welt Fachleute.
• Beratung der Fachbereiche: Wer weiß, was die Plattform kann und was nicht, verhindert Fehlentscheidungen, bevor Wochen investiert sind.

Für Entwickler bedeutet das weniger Routine und mehr Architektur und Abstimmung. Wer gern jede Zeile selbst schreibt, empfindet das als Verlust; wer gern Probleme löst, eher als Entlastung.

Citizen Developer: Wer außerhalb der IT entwickelt und wer dafür geradesteht

Citizen Developer heißen Mitarbeitende aus Fachabteilungen, die mit Low-Code- oder No-Code-Werkzeugen eigene Anwendungen bauen – die Controllerin, die ihr Berichtswesen automatisiert, der Disponent, der eine App für die Tourenplanung zusammenstellt. Sie kennen die Abläufe besser als jeder externe Entwickler und können Ideen sofort ausprobieren.

Angenommen, in einem Stadtwerk baut die Abteilung Netzbetrieb eine App, mit der Monteure Zählerwechsel per Smartphone dokumentieren. Nach drei Monaten nutzen 80 Menschen die App, die Daten fließen in die Abrechnung, und die Kollegin, die sie gebaut hat, wechselt in eine andere Abteilung. Wer pflegt die App jetzt? Wer haftet, wenn eine fehlerhafte Regel falsche Rechnungen erzeugt? Genau an dieser Stelle entscheidet sich, ob Citizen Development dem Unternehmen nützt oder eine neue Schatten-IT erzeugt.

Bewährt hat sich ein Stufenmodell: Persönliche Helfer und Team-Werkzeuge dürfen Fachanwender frei bauen. Sobald eine Anwendung abteilungsübergreifend genutzt wird, personenbezogene Daten verarbeitet oder in Kernsysteme schreibt, prüft die IT mit und übernimmt im Zweifel Betrieb und Pflege. Viele Unternehmen bilden dafür gemischte Teams aus Fachleuten und Entwicklern, manchmal Fusion-Teams genannt.

Governance: Leitplanken statt Verbote

Low-Code zu verbieten, funktioniert selten – die Werkzeuge stecken längst in der vorhandenen Bürosoftware. Wirksamer sind Leitplanken, die das Bauen erlauben und Risiken begrenzen. Dazu gehören:

• Umgebungen: getrennte Bereiche für Ausprobieren, Abteilungsanwendungen und unternehmenskritische Anwendungen, jeweils mit eigenen Regeln.
• Datenrichtlinien: Festlegen, welche Anbindungen kombiniert werden dürfen – etwa, dass Daten aus dem CRM nicht in private Cloud-Speicher oder beliebige Online-Dienste fließen. Die Microsoft Power Platform bietet dafür Datenrichtlinien (Data policies, oft noch DLP-Richtlinien genannt, nach Data Loss Prevention).
• Inventar: ein Überblick, welche Apps und Automatisierungen es gibt, wer sie gebaut hat und wer sie nutzt. Microsoft bietet dafür im Power Platform Admin Center die Bereiche Inventar und Nutzung an; das frühere Center-of-Excellence-Starter-Kit wird nicht mehr weiterentwickelt. Andere Plattformen haben eigene Verwaltungsoberflächen.
• Lebenszyklus: Versionen, Tests und kontrollierte Übergabe von der Test- in die Produktivumgebung, bei professionellen Plattformen auch mit Anbindung an Git und automatisierte Bereitstellung (CI/CD).
• Datenschutz und Sicherheit: Auch selbst gebaute Anwendungen unterliegen der DSGVO. Berechtigungen, Protokollierung und Speicherort der Daten gehören in die Freigabe.
• Befähigung: Schulungen, Vorlagen und eine Anlaufstelle, an die sich Citizen Developer wenden können. Wer gute Bausteine bereitstellt, muss weniger verbieten.

Meine Einschätzung: Die Governance muss leichter sein als der Umweg an ihr vorbei. Ein Freigabeprozess, der Wochen dauert, treibt die Fachabteilung zurück zu Excel-Makros und privaten Online-Diensten.

Low-Code und Pro-Code: Wie beide zusammenarbeiten

Die frühe Debatte „Low-Code gegen klassische Programmierung“ ist weitgehend vorbei. In der Praxis arbeiten beide zusammen, und die Grenze verläuft nicht zwischen Abteilungen, sondern innerhalb einer Anwendung. Fachleute sprechen von Pro-Code, wenn klassisch programmiert wird.

Erweiterungen in klassischem Code

Professionelle Low-Code-Plattformen haben definierte Stellen, an denen Entwickler eigenen Code einhängen. In Microsoft Power Apps sind das etwa eigene Komponenten über das Power Apps Component Framework und eigene Konnektoren für interne Schnittstellen. Mendix erlaubt Erweiterungen in Java und JavaScript, OutSystems ebenfalls eigene Code-Bausteine. So entsteht eine Arbeitsteilung: Die Oberfläche und der Standardablauf kommen aus dem Baukasten, die anspruchsvolle Berechnung oder die Anbindung an ein Altsystem aus der Entwicklung.

APIs als Bindeglied

Noch wichtiger sind Programmierschnittstellen (APIs). Wenn die IT ihre Kernsysteme über gut dokumentierte, abgesicherte Schnittstellen öffnet, können Low-Code-Anwendungen darauf aufsetzen, ohne direkt in Datenbanken zu greifen. Das ist sauberer und sicherer. Angenommen, ein Maschinenbauer stellt Auftragsstatus und Lagerbestand über eine interne API bereit: Der Vertrieb baut daraus eine Auskunfts-App, der Service eine Ersatzteilbestellung, und beide greifen auf dieselben geprüften Daten zu. Wer so arbeitet, profitiert von Prinzipien der Softwarearchitektur wie klar geschnittenen Zuständigkeiten – egal, ob dahinter Low-Code oder klassischer Code steht.

Workflow, Build und Automatisierung

Low-Code-Werkzeuge helfen auch der Entwicklung selbst: Genehmigungsabläufe für Releases, Benachrichtigungen bei fehlgeschlagenen Builds, Übergaben zwischen Teams lassen sich mit Automatisierungsplattformen schneller verdrahten als mit eigenen Skripten.

Was eine gute Low-Code-Plattform ausmacht

Wer eine Plattform für den Einsatz über einzelne Abteilungen hinaus auswählt, sollte sie an denselben Maßstäben messen wie jede andere Entwicklungsumgebung. Diese Merkmale entscheiden:

• Visuelle Modellierung: Daten, Oberflächen und Abläufe werden grafisch beschrieben und sind damit auch für Fachleute ohne Programmierausbildung lesbar. Das beschleunigt die Entwicklung und erleichtert die Abstimmung mit dem Fachbereich.
• Fertige Funktionen: Datenverwaltung, Benutzeranmeldung, Formulare, Workflows und oft auch Module für Vertrieb oder Service sind enthalten und müssen nicht neu gebaut werden.
• Drag-and-Drop-Oberflächen: Komponenten werden per Maus angeordnet. Das nützt Einsteigern, spart aber auch Profis Zeit beim Bau von Oberflächen.
• Wiederverwendbarkeit: Einmal gebaute Komponenten, Datenmodelle und Konnektoren lassen sich in mehreren Anwendungen nutzen – ohne diese Eigenschaft verliert Low-Code einen großen Teil seines Sinns.
• Sicherheit: Rollen und Berechtigungen bis auf Datensatzebene, Verschlüsselung, Anbindung an die zentrale Benutzerverwaltung und regelmäßige Sicherheitsupdates der Plattform.
• Plattformübergreifender Einsatz: Anwendungen laufen im Browser, auf Smartphone und Tablet, ohne dass sie für jedes Gerät neu entwickelt werden.
• Skalierbarkeit: Eine Anwendung muss mit zehn wie mit tausend Nutzern funktionieren. Prüfen Sie, wo die Grenzen bei Datenmengen und gleichzeitigen Zugriffen liegen.
• Berichte und Überwachung: Nutzung, Laufzeiten und Fehler von Apps und Workflows müssen sichtbar sein, sonst bemerkt niemand, wenn eine Automatisierung still versagt.
• Lebenszyklus-Management: Testen, Fehlersuche, Bereitstellung und die Rückkehr zu einer früheren Version, wenn ein Update Probleme macht.

Architektur und Lock-in: Was Sie vor der Plattformwahl klären sollten

Die größte strategische Frage bei Low-Code ist die Abhängigkeit vom Anbieter. Eine Low-Code-Anwendung ist in der Regel an ihre Plattform gebunden. Daten lassen sich exportieren, die modellierte Logik meist nicht in eine andere Umgebung übertragen. Einige Anbieter erzeugen zwar Code, der sich theoretisch weiterverwenden ließe, praktisch ist dieser Code ohne die Plattform selten wartbar.

Lock-in ist nicht automatisch schlecht – jede Standardsoftware bindet. Er sollte aber eine bewusste Entscheidung sein. Hilfreich sind diese Fragen:

• Wo liegen die Daten? In der plattformeigenen Datenbank oder in Systemen, die das Unternehmen ohnehin betreibt? Je mehr Daten außerhalb der Plattform bleiben, desto leichter ist ein späterer Wechsel.
• Wo liegt die Geschäftslogik? Zentrale Regeln, etwa Preisberechnungen, gehören besser in Dienste hinter einer API als verstreut in Dutzende Low-Code-Apps.
• Wie entwickeln sich die Kosten? Lizenzen pro Nutzer oder pro App wirken anfangs günstig und werden bei breitem Einsatz zum großen Posten.
• Was passiert, wenn der Dienst endet? Amazon stellte seinen No-Code-Dienst Honeycode 2024 ein. Wer darauf Anwendungen betrieb, musste neu bauen.

Mein Rat: Kernsysteme und Logik, die das Unternehmen vom Wettbewerb unterscheiden, entstehen weiter in klassischer Entwicklung oder in Standardsoftware. Low-Code eignet sich hervorragend für die Schicht darüber: Oberflächen, Abläufe, Auswertungen und Ergänzungen, die sich schnell ändern.

Low-Code oder KI-Code-Assistent?

Seit KI-Assistenten wie GitHub Copilot, Claude Code oder Cursor ganze Funktionen und kleine Anwendungen auf Zuruf schreiben, stellt sich die Frage, ob Low-Code noch gebraucht wird. Wer per Texteingabe programmieren kann, braucht keinen Baukasten mehr – so die Überlegung.

Der Vergleich hinkt an einer entscheidenden Stelle. Ein KI-Assistent liefert Code. Dieser Code gehört danach dem Unternehmen, mit allen Pflichten: Er muss verstanden, getestet, abgesichert, betrieben und über Jahre gepflegt werden. Eine Low-Code-Plattform liefert dagegen einen betriebenen Rahmen, in dem Anmeldung, Hosting, Updates und Berechtigungen geregelt sind. Für ein Entwicklerteam ist KI-gestützte Programmierung oft der flexiblere Weg. Für eine Fachabteilung ohne Entwickler ist ein KI-generiertes Programm, das niemand im Haus versteht, ein Risiko – gerade wenn es nach der Methode „Vibe Coding“ entstanden ist, bei der der erzeugte Code kaum geprüft wird.

In der Praxis verschmelzen beide Welten. Die großen Low-Code-Plattformen haben eigene KI-Assistenten eingebaut, die aus einer Beschreibung eine erste App, ein Datenmodell oder einen Workflow vorschlagen. Entwickler nutzen KI-Assistenten, um Erweiterungen, Konnektoren und Tests für Low-Code-Anwendungen zu schreiben. Und KI-Agenten, die selbstständig Aufgaben erledigen, werden zunehmend in Low-Code-Umgebungen gebaut, weil dort Anbindungen und Berechtigungen schon geregelt sind. Wie Entwicklerteams KI-Assistenten im Alltag einsetzen, behandelt das Seminar KI-gestützte Softwareentwicklung.

Wofür sich Low-Code in Unternehmen bewährt

Unabhängig von Plattform und Branche zeigen sich einige Einsatzfelder, in denen Low-Code seine Stärken ausspielt:

• Prozess- und Workflow-Anwendungen: Anträge, Freigaben, Prüflisten, Reklamationen – Abläufe mit klaren Schritten und wechselnden Regeln.
• Kundennahe Anwendungen: Portale für Kunden oder Partner, Auskunfts- und Service-Apps, die auf vorhandene Daten zugreifen und die Bindung an das Unternehmen stärken.
• Modernisierung von Altsystemen: eine moderne Oberfläche vor einer alten Anwendung, oft als Zwischenschritt, bevor das Altsystem abgelöst wird.
• Automatisierung: Daten zwischen Systemen übertragen, Dokumente erzeugen, Benachrichtigungen versenden und so Fehler durch manuelle Übertragung vermeiden.
• KI-Funktionen in Fachanwendungen: Belege auslesen, Texte klassifizieren, Anfragen vorsortieren – viele Plattformen bieten dafür fertige Bausteine.
• Prototypen: eine Idee in Tagen testbar machen, bevor über eine aufwendige Entwicklung entschieden wird.

Weniger geeignet sind Anwendungen mit sehr hohen Anforderungen an Leistung, besonderer Rechenlogik oder ungewöhnlichen Oberflächen sowie Produkte, die ein Unternehmen selbst verkaufen will. Wie der Weg von der Idee zur eigenen App praktisch aussieht, beschreibt der Beitrag Von der Idee zur App mit Low-Code und No-Code.

Was das für IT-Abteilungen bedeutet

Die Zukunft der Softwareentwicklung ist nicht entweder Low-Code oder klassischer Code, sondern ein Nebeneinander mit klarer Arbeitsteilung. Low-Code wird zur Standardschicht für Fachanwendungen und Automatisierung, klassische Entwicklung bleibt für Kernsysteme, Schnittstellen und alles, was ein Unternehmen vom Wettbewerb abhebt. KI-Assistenten beschleunigen beide Seiten.

Für IT-Abteilungen heißt das: Sie verlieren nicht an Bedeutung, ihre Rolle verschiebt sich vom alleinigen Hersteller von Software zum Betreiber einer Plattform, Anbieter von Schnittstellen und Begleiter der Fachbereiche. Überschätzt wird die Hoffnung, mit Low-Code ließe sich der Fachkräftemangel lösen. Unterschätzt wird der Aufwand für Governance, Schulung und Pflege, wenn hunderte Anwendungen entstehen. Wer diesen Aufwand von Anfang an einplant, gewinnt Tempo, ohne die Kontrolle zu verlieren.

Häufige Fragen zu Low-Code in der Softwareentwicklung

Ersetzt Low-Code professionelle Entwickler?

Nein. Low-Code nimmt Entwicklern Routinearbeit ab und lässt Fachabteilungen einfache Anwendungen selbst bauen. Plattformbetrieb, Schnittstellen, Erweiterungen, Sicherheit und komplexe Anwendungen bleiben Aufgaben für Fachleute.

Wie lässt sich Low-Code mit Git und CI/CD verbinden?

Professionelle Plattformen unterstützen Versionsverwaltung und automatisierte Bereitstellung zwischen Entwicklungs-, Test- und Produktivumgebung, oft mit Anbindung an Git und an Werkzeuge wie Azure DevOps oder GitHub. Der Funktionsumfang unterscheidet sich je Plattform und Lizenz deutlich; prüfen Sie ihn vor der Auswahl.

Wer ist für eine Citizen-Developer-App verantwortlich?

Das sollte vor dem produktiven Einsatz schriftlich feststehen: Eine fachliche Eigentümerin oder ein fachlicher Eigentümer für Inhalt und Regeln, die IT für Plattform, Sicherheit und Betrieb. Ohne diese Klärung bleibt die App nach einem Personalwechsel verwaist.

Ist Low-Code günstiger als klassische Entwicklung?

In der Entwicklung meist ja, über die gesamte Lebensdauer nicht automatisch. Lizenzkosten pro Nutzer, Aufwand für Governance und die Kosten eines möglichen Plattformwechsels gehören in die Rechnung.

Wer in der Microsoft-Welt arbeitet, findet einen fundierten Einstieg in den Grundlagen von Microsoft Power Apps; für schlanke Datenbankanwendungen außerhalb von Microsoft eignet sich Digitalisierung mit Ninox.