Das hab ich in 2 Stunden gebaut

TL;DR: AI ermöglicht Menschen ohne Entwicklungshintergrund, eigene Lösungen sichtbar und erlebbar zu machen. Entwickler sollten diesen Input als Bereicherung betrachten – und gleichzeitig verständlich erklären, was aus einem schnellen Prototyp eine integrierte, verlässliche Lösung macht.

„Bin gespannt, zeig mal her“

Ein Projektleiter kommt mit einer kleinen Anwendung ins Meeting. Er kann nicht sagen, in welcher Programmiersprache sie geschrieben wurde. Vielleicht kennt er nicht einmal die Datenbank darunter. Aber die Anwendung tut etwas, das vorher nur als Anforderung im Raum stand.

Und sie war an einem Nachmittag fertig.

Die spontane Reaktion eines Entwicklers könnte lauten: So einfach ist das nicht. Das ist kein produktionsreifer Code. Security fehlt. Das passt nicht in unsere Architektur. So können wir das niemals betreiben.

All das kann stimmen.

Meine erste Antwort wäre trotzdem eine andere:

Bin gespannt, zeig mal her.

Wenn Menschen plötzlich Lösungen bauen können

Ich finde es großartig, dass AI Menschen zu Dingen befähigt, die vorher außerhalb ihrer Möglichkeiten lagen.

Projektleiter bauen erste Anwendungen, ohne die verwendete Sprache zu kennen. Menschen automatisieren ihre Abläufe, ohne sich vorher tief in Werkzeuge wie n8n einzuarbeiten. Tabellen lassen sich in natürlicher Sprache analysieren, beinahe so, als würde man einen Spezialisten darum bitten.

Das bedeutet nicht, dass diese Menschen über Nacht Softwareentwickler, Automation Engineers oder Data Analysts geworden sind. Es bedeutet, dass sie nicht mehr jede Werkzeughürde überwinden müssen, bevor sie etwas mit ihrem eigenen Fachwissen anfangen können.

Sie können bei ihrem Problem beginnen.

Das ist eine enorme Veränderung. Wer einen Arbeitsablauf täglich erlebt, kann eine Idee nicht mehr nur in einem Ticket beschreiben oder in einer Präsentation skizzieren. Mit AI kann daraus eine erste funktionierende Lösung entstehen.

Auch Nichtentwickler haben das Potenzial, gute Lösungen zu finden. Diesen Input sollten wir nicht ignorieren.

Mehr als ein Ticket

Ein klassischer Anforderungskatalog beschreibt, was eine Lösung leisten soll. Trotzdem bleiben viele Dinge abstrakt. Menschen verwenden dieselben Wörter und stellen sich darunter unterschiedliche Abläufe vor.

Ein Prototyp macht diese Vorstellungen sichtbar.

Man kann bereits sehen, welche Schritte vorgesehen sind und welches Ergebnis am Ende entsteht. Man kann etwas anklicken, ausprobieren und direkt benennen, was funktioniert oder stört. Annahmen, die in einem Ticket unauffällig geblieben wären, werden plötzlich konkret.

Natürlich konnten Ideen auch vorher schon sichtbar gemacht werden. Werkzeuge wie Figma eignen sich hervorragend, um Oberflächen und Abläufe zu prototypisieren. Aber auch dafür braucht es eigene Fähigkeiten: Man muss das Werkzeug beherrschen, Interaktionen modellieren und eine Idee so gestalten können, dass andere sie nachvollziehen können. Nicht jeder Projektleiter oder Fachexperte bringt diese Erfahrung mit – und nicht jede Organisation hat für eine frühe Idee sofort Designkapazität verfügbar.

AI senkt auch diese Hürde. Ein Fachmensch kann einen Ablauf in natürlicher Sprache beschreiben und daraus eine erste klickbare oder sogar funktionierende Version erzeugen. Das ersetzt nicht die Fähigkeiten eines UX-Designers. Es ermöglicht aber ein erstes sichtbares Gespräch, das vorher vielleicht an fehlender Zeit oder Werkzeugkenntnis gescheitert wäre.

Ein AI-Prototyp kann außerdem schon Verhalten zeigen, das in einem reinen Oberflächenprototyp nur simuliert wird: Daten verarbeiten, ein Ergebnis berechnen oder einen kleinen Ablauf tatsächlich automatisieren. Auch das macht ihn nicht produktionsreif. Es macht die zugrunde liegende Idee aber auf eine andere Weise erfahrbar.

Der Prototyp muss dafür technisch nicht besonders elegant sein. Für seinen ersten Zweck ist das möglicherweise vollkommen ausreichend.

Er beantwortet eine wichtige Frage:

Könnte sich eine Lösung für dieses Problem ungefähr so anfühlen?

Das ist wertvolle Vorarbeit – selbst wenn später keine einzige Zeile des Codes übernommen wird.

Ein gutes One-Trick-Pony

Viele dieser schnellen Lösungen sind One-Trick-Ponys. Sie lösen ein klar begrenztes Problem und ignorieren alles, was außerhalb dieses einen Ablaufs liegt.

Das ist zunächst keine Abwertung. Ein guter Proof of Concept darf genau das tun. Er soll nicht beweisen, dass eine Lösung bereits alle Anforderungen eines Unternehmens erfüllt. Er soll zeigen, dass eine Idee grundsätzlich funktioniert oder ein gewünschter Ablauf möglich ist.

Manche dieser kleinen Lösungen dürfen sogar bleiben. Wenn ein Werkzeug ein eigenständiges Problem zuverlässig löst, wenig kritische Integration benötigt und für seine Nutzenden funktioniert, muss es nicht zwangsläufig in eine große Plattform überführt werden.

Nicht jedes hilfreiche Skript braucht eine Enterprise-Architektur.

Schwierig wird es erst, wenn aus „Der Trick funktioniert“ automatisch „Das Produkt ist fast fertig“ wird.

Die unsichtbare Arbeit

Der schnelle Prototyp zeigt den sichtbaren Nutzen. Professionelle Entwicklung beschäftigt sich zusätzlich mit vielem, das in einer kurzen Demonstration kaum auffällt.

Eine Lösung innerhalb einer bestehenden Produkt- oder Unternehmenslandschaft muss beispielsweise Fragen beantworten wie:

• Wer darf welche Daten sehen oder verändern?
• Wo werden Daten gespeichert und wie lange bleiben sie erhalten?
• Welche bestehenden Schnittstellen und Prozesse müssen berücksichtigt werden?
• Wie fügt sich die Oberfläche in das UI-System ein?
• Sind Wording, Übersetzungen und Barrierefreiheit geklärt?
• Was passiert bei Fehlern oder nicht erwarteten Eingaben?
• Wie wird die Lösung getestet, überwacht und betrieben?
• Wer wartet sie, wenn sich angrenzende Systeme verändern?

Der Prototyp muss diese Fragen nicht beantwortet haben, um wertvoll zu sein. Die professionelle Lösung braucht darauf jedoch belastbare Antworten.

Das erklärt einen Teil des Unterschieds zwischen zwei Stunden und mehreren Wochen.

Nicht kleinreden, sondern den Unterschied erklären

Entwickler geraten durch schnelle AI-Prototypen in eine ungewohnte Situation. Bisher blieb ein großer Teil der technischen Machbarkeit unsichtbar, bis ein Entwicklungsteam etwas umgesetzt hatte. Jetzt steht schon früh eine funktionierende Teillösung im Raum.

Dadurch entsteht Rechtfertigungsdruck. Wenn das Ergebnis bereits zu sehen ist, kann zusätzlicher Aufwand wie unnötige Bürokratie wirken.

Die schlechteste Reaktion wäre, den Prototyp reflexhaft kleinzureden. „Das ist keine richtige Software“ ignoriert seinen tatsächlichen Wert und wirkt schnell wie Gatekeeping.

Hilfreicher ist eine andere Argumentation:

1. Anerkennen, was bereits funktioniert. Welches Problem löst der Prototyp und welche Erkenntnis liefert er?
2. Seinen Zweck klären. Soll er ein eigenständiges Werkzeug bleiben oder Teil einer größeren Landschaft werden?
3. Die Lücke sichtbar machen. Welche konkreten Anforderungen kommen durch Integration und Betrieb hinzu?
4. Erkenntnisse vom Code trennen. Abläufe und Ergebnisse können übernommen werden, auch wenn die technische Umsetzung neu entsteht.
5. Nur so viel professionalisieren wie nötig. Nicht jede kleine Lösung braucht alle Mechanismen eines großen Produkts.

So wird aus „Das dauert länger, weil es kompliziert ist“ eine nachvollziehbare Beschreibung zusätzlicher Arbeit.

Die Rolle der Entwickler bleibt

Wenn Fachmenschen mit AI selbst erste Lösungen bauen können, verschwindet die Rolle professioneller Entwickler nicht.

Entwickler bringen weiterhin Systeme zusammen, berücksichtigen den Gesamtkontext und machen aus einem funktionierenden Einzelfall eine verlässliche Lösung. Sie kümmern sich um die Teile, die ein isolierter Prototyp bewusst auslassen durfte.

Neu ist vor allem das Ausgangsmaterial. Statt nur ein Ticket zu erhalten, bekommen Entwickler möglicherweise schon einen Ablauf, ein sichtbares Ergebnis und erste Erfahrungen aus der Benutzung.

Das kann Druck erzeugen. Es kann die Zusammenarbeit aber auch erheblich verbessern.

Der Mensch, der den Prototyp gebaut hat, kennt vermutlich das Problem besonders gut. Der Entwickler kennt die Landschaft, in der eine dauerhafte Lösung bestehen muss. AI hat erstmals ermöglicht, dass beide Seiten nicht nur über eine abstrakte Idee sprechen, sondern gemeinsam auf etwas Konkretes schauen.

Das ist keine Konkurrenz. Es ist eine bessere Gesprächsgrundlage.

Wenn also das nächste Mal jemand sagt: „Das hab ich mit AI in zwei Stunden gebaut“, muss die Antwort nicht mit einer Liste von Einwänden beginnen.

Bin gespannt. Zeig mal her.