Mehr Menschen bauen Software, aber nicht dieselbe: Was No-Code und Low-Code wirklich verändern
- Benjamin Metzig
- vor 5 Stunden
- 7 Min. Lesezeit
Wenn in einem Unternehmen ein neuer Prozess hakt, fehlt oft nicht die Idee. Meist fehlt die Übersetzung. Die Fachabteilung weiß ziemlich genau, welches Formular, welche Freigabeschritte, welche Benachrichtigungen und welche Daten sie braucht. Die IT weiß ebenso genau, dass daraus schnell mehr wird als ein kleines Hilfstool: Rechte müssen sauber gesetzt, Schnittstellen bedacht, Datenmodelle gepflegt und spätere Änderungen mitgedacht werden. Genau in diese Lücke stoßen No-Code- und Low-Code-Plattformen.
Sie versprechen, dass Menschen ohne klassische Entwicklerlaufbahn digitale Werkzeuge selbst bauen können. Das ist weder bloße Reklame noch die große Entmachtung des Software-Engineerings. Es ist eine Verschiebung. Künftig werden wahrscheinlich mehr Menschen Software bauen als heute, aber sie werden nicht dieselbe Art von Software bauen. Wer einfache Abläufe digitalisiert, arbeitet mit anderen Risiken, anderen Freiheitsgraden und anderer Verantwortung als jemand, der Kernsysteme, Datenarchitekturen oder sicherheitskritische Anwendungen entwickelt.
Die eigentliche Zukunftsfrage lautet deshalb nicht: Braucht man noch Entwickler? Sie lautet: Welche Schicht von Software kann von Fachabteilungen, Plattformen und KI-Assistenten übernommen werden, und ab welchem Punkt braucht es wieder professionelles Engineering?
Wenn der Engpass nicht der Code ist, sondern die Warteschlange
No-Code und Low-Code wirken so attraktiv, weil sie ein reales Organisationsproblem adressieren. Fachabteilungen müssen heute laufend kleine digitale Lösungen bauen: Genehmigungsstrecken, interne Dashboards, Datenerfassungen, Automatisierungen zwischen Tools, Serviceformulare, einfache Kundenportale. Für klassische Entwicklungsteams sind solche Vorhaben oft zu klein, zu kurzfristig oder zu zahlreich, um sie schnell genug abzuarbeiten.
Die Forschung spricht hier schon länger nicht nur von neuen Tools, sondern von einer alten Hoffnung in neuer Form. Eine systematische Übersichtsarbeit zum End-User Development zeigt, dass die Idee, Nicht-Programmierer digitale Artefakte anpassen oder selbst erstellen zu lassen, deutlich älter ist als der aktuelle No-Code-Hype. Neu ist vor allem die Kombination aus Cloud-Plattformen, vorgefertigten Integrationen und grafischen Oberflächen, die viele technische Details unsichtbar macht.
Genau diese Abstraktion ist der Kern des Versprechens. In einer aktuellen Arbeit zu industriellen Low-Code-Plattformen wird beschrieben, dass solche Systeme stark auf grafische Sprachen statt auf handgeschriebenen Code setzen, um Citizen Developer einzubinden. Anders gesagt: Die Plattform nimmt vielen Beteiligten nicht das Denken ab, aber sie ersetzt einen Teil der Handarbeit durch Bausteine, Regeln und Vorlagen.
Das ist ein wichtiger Unterschied. No-Code und Low-Code beseitigen die Logik eines Problems nicht. Sie verlagern sie in andere Formen: in Prozessmodelle, Konfigurationen, Berechtigungsstrukturen, Datenfelder und Trigger.
Was Baukästen besonders gut können
Dort, wo Abläufe relativ standardisierbar sind, spielen visuelle Plattformen ihre Stärke aus. Ein Antragsprozess, eine Eingabemaske, eine Erinnerungslogik oder ein interner Workflow muss nicht jedes Mal von Grund auf neu programmiert werden. Er lässt sich oft aus vorhandenen Bausteinen zusammensetzen. Genau deshalb sind solche Werkzeuge in Fachbereichen attraktiv: Sie verkürzen den Weg von der Anforderung zur ersten funktionierenden Lösung.
Eine HMD-Studie zur Einführung von Citizen Development in Unternehmen zeigt zwei typische Wege. Entweder Fachbereiche arbeiten mit einem Self-Service-Ansatz relativ eigenständig, oder ihre Vorhaben werden in das bestehende Demand-Management der IT integriert. In beiden Fällen ist derselbe Punkt entscheidend: Governance ist keine spätere Formalie, sondern eine Voraussetzung. Das ist ernüchternd und nützlich zugleich. No-Code skaliert nicht deshalb gut, weil Kontrolle überflüssig wird, sondern weil gewisse Formen von Kontrolle vorher in die Plattform und in Prozesse eingebaut werden.
Gerade für kleine interne Werkzeuge ist das plausibel. Ein Team braucht vielleicht kein neues Kernsystem, sondern nur einen verlässlichen digitalen Ablauf statt einer Excel-Wüste, zehn E-Mail-Ketten und zwei vergessener Freigaben. An dieser Stelle ist visuelle Entwicklung kein minderwertiger Ersatz für "echte Software", sondern oft die pragmatischere Form von Software.
Merksatz: Je standardisierbarer ein Ablauf ist, desto eher helfen Baukästen. Je stärker ein System in andere Systeme, Regeln und Verantwortlichkeiten eingreift, desto schneller wird aus einem Baukasten ein Architekturproblem.
Wo aus schneller Hilfe Schatten-IT wird
Die Kehrseite beginnt dort, wo lokale Lösungen anfangen, sich wie Infrastruktur zu verhalten. Ein Tool, das gestern nur einer Abteilung half, hängt heute an Kundendaten, an Freigaben, an APIs, an Reporting und an Ausnahmeregeln. Damit verändert sich sein Status. Es ist nicht länger bloß ein nützlicher Helfer, sondern Teil der Systemlandschaft.
Genau hier kommt Schatten-IT ins Spiel. Eine Analyse aus dem MDPI-Journal Systems beschreibt diese Ambivalenz ziemlich präzise: Shadow IT bringt oft Innovation und Flexibilität hervor, erhöht aber zugleich Heterogenität, Intransparenz und Integrationsprobleme. Besonders relevant ist der Befund, dass geringe Standardisierung und schwache Integration Automatisierung gerade behindern können. Das klingt paradox, ist aber zentral: Wer sehr schnell digitale Inseln baut, baut nicht automatisch eine digitalere Organisation.
In Unternehmen zeigt sich das oft unspektakulär. Ein Formular wird spontan mit einem Plattformtool gebaut. Dann braucht es Rollenlogik. Danach eine Datenanbindung. Danach eine Prüfung, wer Änderungen freigeben darf. Dann fällt auf, dass dieselben Daten schon an drei Stellen gepflegt werden. Spätestens jetzt ist nicht mehr nur Produktivität die Frage, sondern Verantwortlichkeit.
Deshalb ist es sinnvoll, No-Code und Low-Code nicht als Befreiung von IT zu beschreiben, sondern als Verlagerung von IT-Arbeit. Ein Teil der Arbeit wandert in die Fachbereiche. Ein anderer Teil verdichtet sich an einer noch kritischeren Stelle: Wer definiert Standards, prüft Schnittstellen, dokumentiert Abhängigkeiten und entscheidet, welche lokale Lösung dauerhaft bleiben darf?
Warum professionelle Entwickler nicht verschwinden
Die zugespitzte Behauptung, No-Code werde klassische Softwareentwicklung verdrängen, verwechselt zwei Ebenen. Sie verwechselt das Bauen von Oberflächen und Prozessketten mit dem verantwortlichen Entwurf von Systemen. Professionelle Entwicklerinnen und Entwickler schreiben künftig womöglich weniger repetitiven Boilerplate-Code, aber ihre Rolle wird in vielen Umgebungen eher systemischer als kleiner.
Eine MIS-Quarterly-Executive-Studie zu Citizen Development benennt genau die Punkte, an denen diese systemische Rolle wieder auftaucht: Softwarequalität, technische Schulden und Schatten-IT. Die Lösung besteht dort nicht darin, Bürgerentwickler zurück in die Zuschauerrolle zu schicken. Vielmehr betont die Studie die Rolle technischer Expertinnen und Experten bei der Governance. Das ist vermutlich die nüchternste Antwort auf die Frage, wer künftig Software baut: mehr Leute bauen mit, aber nicht alle bauen ohne Netz.
Dazu kommt eine zweite Ebene, die im Hype oft unterschätzt wird: Auch Low-Code-Plattformen selbst sind hochkomplexe technische Produkte. Die Dandelion-Arbeit macht sichtbar, wie viel Modellierung, Validierung, Heterogenitätsmanagement und Skalierungslogik unter der grafischen Oberfläche steckt. Wer also sagt, No-Code ersetze Engineering, übersieht, dass diese Werkzeuge auf verdichtetem Engineering beruhen. Jemand muss die Plattform bauen, ihre Grenzen kennen und ihre Integrationen absichern.
Hinzu kommt ein ganz praktischer Befund aus der gegenwärtigen Entwicklerrealität. Laut der Stack Overflow Developer Survey 2024 nutzen oder planen 76 Prozent der Befragten KI-Tools im Entwicklungsprozess, und die meisten erwarten die stärkste Integration bei Dokumentation, Tests und Schreiben von Code. Das spricht nicht für das Ende des Entwicklers, sondern für eine weitere Schicht der Abstraktion. Wie bei Low-Code verschwindet Arbeit nicht; sie verschiebt sich in Review, Auswahl, Validierung und Wartung.
Wer schon heute beobachtet, wie KI-Agenten im Büro administrative Abläufe vorbereiten, sieht dieselbe Tendenz in neuer Form: Immer mehr digitale Arbeit lässt sich zusammenklicken oder anstoßen. Aber je näher sie an echte Entscheidungen, Rechte und Daten rückt, desto wichtiger wird Kontrolle.
Die neue Trennlinie verläuft nicht zwischen Menschen und Maschinen
Der interessanteste Wandel liegt deshalb woanders. Er verläuft nicht sauber zwischen "Fachabteilung" und "IT" und auch nicht zwischen "Mensch" und "Maschine". Er verläuft zwischen verschiedenen Arten von Software.
Es gibt Software, die vor allem aus wiederkehrenden Mustern besteht: Formularlogik, standardisierte Prozesse, Benachrichtigungen, kleine Auswertungen, interne Helfer. Hier werden No-Code und Low-Code weiter Boden gewinnen, besonders wenn KI-Assistenten Konfigurationen aus natürlicher Sprache erzeugen. Es gibt aber auch Software, die an Grenzen stößt, sobald Ausnahmen, Sicherheit, Skalierung, Interoperabilität und langfristige Wartung ins Spiel kommen. Dann wird aus dem Workflow ein System.
Gerade an diesem Punkt lohnt sich der Blick auf Abhängigkeiten. Die BESSER-Arbeit zu einer offenen Low-Code-Plattform argumentiert ausdrücklich, dass offene Alternativen helfen können, Vendor Lock-in zu vermeiden. Das ist kein Nebenaspekt. Wer künftig mehr Entwicklung in Plattformen verlagert, muss sich stärker fragen, wem die Modelle, Integrationen und Exportpfade gehören. Der alte Konflikt zwischen Bequemlichkeit und Souveränität taucht in neuer Verpackung wieder auf. Wer tiefer in diese Frage einsteigen will, landet schnell bei offenen Standards gegen Lock-in und bei der Einsicht, dass digitale Freiheit oft an unscheinbaren technischen Regeln hängt.
Auch deshalb ist der Satz "Jeder kann jetzt Software bauen" nur halb richtig. Viele Menschen können künftig mehr digitale Werkzeuge bauen als früher. Aber nicht jeder kann die Folgekosten, Haftungsfragen, Sicherheitsprobleme und Integrationskonflikte gleich mitbauen. Der Engpass verschwindet nicht, er wandert.
Was künftig wirklich gebaut wird
Wenn man die Entwicklung nüchtern betrachtet, entsteht keine Welt ohne Entwickler, sondern eine breitere Werkbank. Fachabteilungen bauen mehr Prototypen, interne Tools und Prozesslogiken. Plattformen kapseln wiederkehrende Technik. KI beschleunigt das Formulieren, Variieren und Testen. Professionelle Entwickler verschieben ihren Schwerpunkt stärker auf Plattformarchitektur, Schnittstellen, Datenmodelle, Governance, Review und die besonders widerspenstigen Ausnahmen.
Das ist kein kleiner Unterschied. Er verändert auch, was digitale Kompetenz in Organisationen bedeutet. Künftig wird es nicht reichen, entweder nur Fachlogik oder nur Code zu beherrschen. Wertvoll werden jene Rollen, die dazwischen übersetzen können: Menschen, die Domänenwissen, Prozessverständnis und technisches Urteilsvermögen zusammenbringen.
In diesem Sinn bauen künftig tatsächlich mehr Menschen Software. Aber sie bauen sie auf verschiedenen Ebenen und mit ungleicher Verantwortung. Wer nur fragt, ob Baukästen das Programmieren ersetzen, stellt die falsche Frage. Wichtiger ist, welche Probleme standardisierbar sind, welche Systeme dokumentierbar und prüfbar bleiben müssen und wann lokale Nützlichkeit in Infrastruktur kippt. Genau dort entscheidet sich, ob No-Code und Low-Code digitale Handlungsfähigkeit verbreitern oder nur neue Unordnung mit hübscher Oberfläche erzeugen.
Das gilt nicht nur für Unternehmen. Auch in der öffentlichen Hand oder in stark regulierten Umgebungen reicht eine gute Oberfläche selten aus, wenn Zuständigkeiten, Ausnahmen und Nachvollziehbarkeit komplex bleiben. Wer das an großen Prozessen beobachten will, findet in der digitalen Verwaltung und in Fragen der dokumentierten KI-Governance denselben Grundkonflikt: Eine Lösung ist erst dann wirklich tragfähig, wenn sie nicht nur funktioniert, sondern auch verantwortbar bleibt.
Autorenprofil
Benjamin Metzig ist Gründer, Autor und redaktionell Verantwortlicher von Wissenschaftswelle.de. Wissenschaftswelle ist ein persönlich geführtes redaktionelles Wissensprojekt, das komplexe Themen aus unterschiedlichen Fachbereichen sorgfältig recherchiert, strukturiert und verständlich aufbereitet. Moderne Recherche-, Analyse- und KI-Werkzeuge dienen dabei als Unterstützung, während Auswahl, Einordnung, Ton, Quellenbewertung und Veröffentlichung redaktionell bei Benjamin Metzig verantwortet bleiben. Mehr zum Profil: Autorenprofil von Benjamin Metzig.
Wenn du Wissenschaftswelle auch jenseits des Blogs verfolgen willst, schau hier vorbei: Instagram und Facebook
Kommentare