9. April 2026
Du hast 4.000 Nicht-Entwickler zu Buildern gemacht. Sie lösen ihre eigenen Probleme. Und jetzt stellen sie alle dieselbe Frage — auf die niemand eine saubere Antwort hat.
Das Versprechen war einfach: Gib den Leuten KI-gestützte Werkzeuge, lass sie Lösungen für ihre eigenen Teams bauen, und schau zu, wie die Produktivität steigt. Und es hat funktioniert. In großen Konzernen bauen inzwischen Tausende von Fachkollegen Agenten, Automatisierungen und kleine Anwendungen, die echte Probleme lösen. Die Werkzeug-Revolution hat geliefert.
Aber sie hat noch etwas anderes geliefert — eine Frage, die ich inzwischen mehrmals pro Woche höre, und auf die niemand eine befriedigende Antwort hat:
„Mein Prototyp läuft auf meinem Rechner. Wo lasse ich ihn produktiv laufen?“
Das ist der Elefant im Raum der Citizen-Development-Bewegung. Wir sind außerordentlich gut darin geworden, Menschen das Bauen zu ermöglichen. Beim Ausliefern sind wir nicht mitgekommen.
Die Landschaft heute
Wenn mich jemand fragt, wo das neu gebaute System laufen soll, sehen die Antworten derzeit ungefähr so aus:
Die Standardantwort: Die Enterprise-Cloud-Plattform
Der etablierte, unternehmenstaugliche Weg. Robust, reguliert, sicher — und gebaut für professionelle Engineering-Teams mit den Fähigkeiten und Prozessen, die diese Umgebung voraussetzt. Für jemanden, der gerade seinen ersten funktionierenden Agenten gebaut hat, fühlt sich das an, als würde man die Schlüssel zu einem Jumbo-Jet bekommen, obwohl man eigentlich nur ein Fahrrad braucht.
Die Nahe Zukunft: Workflow-Plattformen wie n8n
Low-Code-Orchestrierung, die die Lücke zwischen „läuft auf meinem Laptop“ und „läuft irgendwo echt“ überbrückt. Standardpipelines, vorgefertigte Konnektoren und ein zugänglicheres Betriebsmodell. Vielversprechend — aber in Sachen Enterprise-Governance noch nicht ausgereift.
Die Wildcard: Copilot Studio und ähnliche Plattformen
Eng integriert in das Microsoft-Ökosystem, das viele Teams ohnehin nutzen. Ein möglicher Weg, der aber eigene Fragen zu Flexibilität, Kosten und Abhängigkeit aufwirft.
Keine dieser Antworten ist falsch. Aber keine ist vollständig. Und genau das ist das eigentliche Problem.
Es ist nicht nur ein Werkzeug-Problem
Je tiefer man in diese Frage einsteigt, desto klarer wird: Die Werkzeug-Frage ist eigentlich drei Fragen in einem Trenchcoat.
Das Drei-Schichten-Problem:
- Werkzeuge: Wo läuft der Code physisch, und wie kommt er dorthin?
- Prozesse: Welche Prüfungen, Reviews und Freigaben sind nötig — und sind sie für diese neue Realität gemacht?
- Verantwortung: Wer betreibt das Ganze in Produktion? Wer wird um zwei Uhr nachts geweckt? Wer patcht die Abhängigkeit, wenn eine Sicherheitslücke veröffentlicht wird?
Ein erfahrener Kollege aus dem Plattform-Engineering brachte es auf den Punkt: Das ist ein Prozess- und Verantwortungsproblem, nicht nur ein Werkzeug-Problem. Und er hat recht. Ein Prototyp, der auf einem Laptop großartig aussieht, kann in Produktion erschreckend fragil sein, wenn niemand über Sicherheit, Staging, Versionierung, Fehlertoleranz, Resilienz und Backups nachgedacht hat.
Stimmen aus der Praxis
Das ist keine abstrakte Sorge. Hier ist, was Menschen in Großkonzernen tatsächlich erleben:
“Wir haben einen Agenten gebaut, der automatisch E-Mails beantwortet. Das lief wunderbar in der Sandbox. Jetzt wollen wir in Produktion — aber das ist deutlich schwieriger als den Agenten selbst zu bauen. Fünf Prüfungen von verschiedenen Abteilungen, bevor sich überhaupt jemand unser System anschaut. Nicht alle Abteilungen sind darauf vorbereitet, dass wir selbst Lösungen bauen.”
“Wir brauchen dringend Ansprechpartner als Lotsen und einen geschützten Raum, in dem jeder Lösungen entwickeln kann.”
Das sind keine Beschwerden. Das sind Signale. Die Kluft zwischen „ich habe etwas gebaut“ und „es läuft in Produktion“ ist so breit, dass viele vielversprechende Lösungen einfach in der Mitte sterben.
Wie könnte die Antwort aussehen?
Aus vielen Gesprächen mit Kollegen hat sich eine Vision herauskristallisiert, die es verdient, klar formuliert zu werden:
Die Vision: Nahtloser Übergang vom Prototyp in die Produktion
Stell dir eine Welt vor, in der jede selbst entwickelte Lösung in einer Sandbox mit Leitplanken startet. Wenn sie bereit ist, startet man einen automatisierten „Produktionsreife-Check“ — KI-gestützte Sicherheitsscans, Resilienz-Prüfungen, Architektur-Validierung — alles zentral gesteuert, aber reibungslos ausgeführt.
Derselbe Technologie-Stack, dieselben Muster, jedes Mal. Der Prototyp wird zum Enterprise-Deployment — nicht durch Heldentaten Einzelner, sondern durch einen Prozess, der genau für diesen Moment entworfen wurde.
Das ist keine Science-Fiction. Es ist ein Engineering-Problem mit bekannten Bausteinen: standardisierte Container-Pipelines, integrierte Sicherheitsscans, vorkonfiguriertes Monitoring, zentrale Governance-Regeln als automatisierte Prüfungen statt manuelle Warteschlangen. Die Einzelteile existieren. Sie müssen mit Citizen Developern als primärer Zielgruppe zusammengesetzt werden — nicht nur für professionelle Ingenieure.
Wo es von hier aus weitergeht
Eine fertige Antwort hat noch niemand. Aber der Weg nach vorne hat ein paar klare Konturen.
Erstens: Die Leitplanken zentral steuern, nicht die Werkzeuge. Sicherheitsstandards, Betriebsanforderungen und Resilienz-Vorgaben sollten als automatisierte Prüfungen kodifiziert sein, die jeder Deployment-Pfad bestehen muss — egal welche Plattform dahinter steht. Governance sollte ein Tor sein, kein Torwächter.
Zweitens: Den Prozess für die neue Persona gestalten. Citizen Developer sind keine Junior-Entwickler. Sie sind Fachexperten, die zufällig etwas gebaut haben. Der Produktionspfad muss sie dort abholen, wo sie stehen — nicht dort, wo der bestehende Software-Entwicklungsprozess sie vermutet.
Drittens: Gemeinschaft schaffen. Ansprechpartner, offene Foren, geteilte Muster. Die Menschen, die diese Lösungen bauen, brauchen einander — zum Troubleshooting, zur Ermutigung, und für den kollektiven Druck, der organisatorischen Wandel vorantreibt.
Der Elefant im Raum geht nirgendwo hin. Aber immerhin reden wir jetzt darüber.