Rapid Prototyping Softwareentwicklung beschreibt den Unterschied zwischen Denken über Software und Arbeiten mit echter Software.
Vibe Coding ist nur Rapid Prototyping
Was Regelungstechniker seit Jahrzehnten wissen, lernt die Softwarebranche gerade.
16.02.2026 · ntaflos.de · Sprache: de
Eine Stunde am Whiteboard. Boxen zeichnen. Pfeile zeichnen. Über Pfeile diskutieren. Oder: eine Stunde mit einem KI-Coding-Agent arbeiten und etwas Lauffähiges haben, über das man reden kann.
Das ist nicht neu. Das ist Rapid Prototyping. Neu ist nur, dass es jetzt auch in der Softwareentwicklung in Gedankengeschwindigkeit geht.
Das kenne ich
Im Studium — Elektrotechnik, Automatisierungstechnik — habe ich viel mit dSPACE-Systemen gearbeitet. Für alle, die nicht aus der Embedded-Welt kommen: dSPACE baut Hardware-in-the-Loop (HIL) und Software-in-the-Loop (SIL) Simulationsplattformen. Stark verbreitet in der Automobil-, Luft- und Raumfahrt- sowie Industrieautomatisierung.
Das Prinzip ist einfach. Man entwirft einen Regler — etwa für einen Motor oder ein Bremssystem. Statt zu theoretisieren, wie er sich verhalten wird, steckt man ihn in eine simulierte Version des realen Systems. Das Streckenmodell simuliert die Physik. Der Regler rechnet seine Logik. Die Simulation läuft in Echtzeit. Man sieht sofort, was funktioniert und was nicht.
Kein Meetingraum-Debatte darüber, ob der Regler stabil sein wird. Man startet ihn. Die Simulation zeigt es. Schwingt er, wird korrigiert. Überreagiert er, wird nachgestellt. Die Feedback-Schleife ist kurz, die Randbedingungen real, und man lernt schneller als jedes Dokument es vermitteln könnte.
Das war vor 15 Jahren Standardpraxis in der Regelungstechnik. Niemand nannte es „Vibe Controlling.“
KI bringt das in die Softwareentwicklung
Mit Werkzeugen wie Cursor oder Claude Code passiert in der Softwareentwicklung gerade etwas Ähnliches. Man hat eine Idee — ein neues API-Design, eine Datenpipeline, eine UI-Komponente, einen Workflow. Statt es in einem Dokument zu beschreiben oder eine Woche an einem Design-Spec zu arbeiten, baut man es einfach.
Nicht die Produktionsversion. Einen Prototypen. Eine lauffähige Skizze. Etwas, das man starten, anfassen und daraus lernen kann.
Der Begriff „Vibe Coding“ hat sich durchgesetzt, und ich verstehe warum — klingt locker und leicht verantwortungslos. Aber was tatsächlich passiert, ist Rapid Prototyping. Man testet Ideen gegen reale Rahmenbedingungen in einer Geschwindigkeit, die vorher nicht möglich war. Das Framework wehrt sich. Der Compiler wehrt sich. Die Laufzeitumgebung wehrt sich. Diese Reibung ist der Punkt.
Manche nennen es „Demo Culture“ — Zeigen schlägt Beschreiben. Ich denke, es geht tiefer. Es geht darum, Code als Denkwerkzeug zu nutzen. Der Prototyp ist nicht das Ergebnis. Das Verständnis ist es.
Warum Bauen besser ist als Zeichnen
Was ein Whiteboard nicht kann: dir sagen, dass dein elegantes API-Design nicht mit dem vorhandenen Auth-Framework zusammenspielt. Dass das Datenformat, das du angenommen hast, nicht dem entspricht, was der Upstream-Service tatsächlich liefert. Dass die Bibliothek, die du nutzen wolltest, seit zwei Jahren nicht mehr gepflegt wird.
Code sagt dir das alles. Sofort.
Beim Prototypen mit einem KI-Agent sind die wertvollsten Momente nicht die, in denen alles funktioniert — sondern die, in denen etwas bricht. Jeder Fehler ist eine Randbedingung, die ich nicht kannte. Aufgedeckt in Minuten statt Wochen. Der Prototyp wird zum Gespräch mit der Realität.
Das verändert auch die Kommunikation. Statt eines 15-seitigen Designdokuments, das drei Leute lesen, hat man einen laufenden Prototypen, den jeder ausprobieren kann. Das Gespräch wandelt sich von „Würde das theoretisch funktionieren?“ zu „Hier ist, was funktioniert, und hier ist, was nicht funktioniert.“
Die Falle: Prototypen sind keine Produkte
Jetzt wird es gefährlich.
Die Demo funktioniert. Jemand zeigt sie einem Stakeholder. Der Stakeholder sagt: „Super, wann können wir das ausliefern?“ Und plötzlich ist der Prototyp — das Ding, das in zwei Stunden ohne Fehlerbehandlung, ohne Auth, ohne Tests, ohne Monitoring, ohne Deployment-Strategie gebaut wurde — „das Produkt.“
Das ist kein neues Problem. Ein Regler, der in der Simulation wunderbar läuft, überlebt nicht automatisch die reale Hardware. Thermische Belastung, Signalrauschen, Timing-Jitter, Grenzfälle, die die Simulation nie abgebildet hat. Die Lücke zwischen „funktioniert im Labor“ und „funktioniert im Feld“ — dort lebt echtes Engineering.
In der Software ist die Lücke dieselbe. Der Prototyp versteckt Komplexität, die die Produktion aufdecken wird. Kein Graceful Degradation. Kein Logging. Kein Rollback. Keine Überlegung, was passiert, wenn die Datenbank langsam ist, das Netzwerk ausfällt oder zwei Benutzer gleichzeitig denselben Endpunkt treffen.
Prototypen werden viel zu oft als produktionsreife Lösungen verstanden — oder sogar verkauft. Das ist kein KI-Problem. Das ist ein Disziplin-Problem.
KI macht es nur einfacher, überzeugende Prototypen schneller zu bauen. Die Versuchung wird stärker.
Ingenieurdisziplin ist die Brücke
Die Lösung ist nicht kompliziert. Ältere Ingenieurdisziplinen haben das längst verstanden: Prototypen als Prototypen behandeln. Nutzen, um zu lernen, zu validieren und zu kommunizieren. Dann das echte System bauen. Die Simulation informiert das Produktionssystem. Sie wird nicht zum Produktionssystem.
Softwareentwicklung ist jünger als die meisten anderen Ingenieurdisziplinen — und hat oft nicht dieselbe Strenge. Die Grenze zwischen Prototyp und Produkt verschwimmt, und zu viele finden das in Ordnung. Aber die Grenze zählt. Saubere Architektur. Saubere Tests. Saubere Fehlerbehandlung. Sauberes Deployment.
Die Disziplin liegt darin zu wissen, in welchem Modus man gerade ist. Prototyping oder Produktentwicklung? Sobald man diese Unterscheidung verliert, liefert man Simulationscode in die Produktion aus.
Fazit
KI-gestütztes Rapid Prototyping ist eines der wertvollsten Ergebnisse der aktuellen Welle von Werkzeugen. Die Fähigkeit, Ideen in Minuten statt Wochen gegen echten Code zu testen, verändert, wie wir denken, kommunizieren und Entscheidungen treffen.
Die Stärke liegt im schnellen Feedback. Die Gefahr liegt darin, den Prototypen mit dem fertigen System zu verwechseln.
Schnell prototypen. Schnell lernen. Dann sauber bauen. Die Werkzeuge sind neu. Die Disziplin ist es nicht.
