Produktteams entscheiden gerade anders über Software, die es noch nicht gibt. Statt in Meetings eine Idee zu verteidigen und auf freie Entwicklungskapazität zu warten, bauen Produktmanager einen klickbaren Prototyp, ohne eine Zeile Code von Hand zu schreiben – und testen ihn, bevor Budget in die Umsetzung fließt. t3n berichtet dazu am 4. Oktober 2026.

Für einen Betrieb mit zehn bis hundert Mitarbeitern heißt das konkret: Der Product Owner oder die IT-Verantwortliche kann eine Kundenfunktion – ein neues Buchungssystem, eine interne Bestandsverwaltung – als funktionsfähigen Entwurf aufbauen, bevor die Entwicklung ein Projekt aufschlägt. Kundenstimmen und Interview-Notizen füttert man in ein KI-Werkzeug, das wiederkehrende Muster herausfiltert. So zeigt sich, welches Bedürfnis eine anstehende Entscheidung tatsächlich betrifft und welches nur am lautesten war. Der Haken: Ein Prototyp bleibt ein Prototyp. Er ersetzt keine geprüfte Architektur, keine Sicherheitsprüfung, keine Barrierefreiheit. Und ein Klick-Dummy, der bereits fertig aussieht, verleitet Testpersonen dazu, den Feinschliff zu bewerten statt die Idee dahinter – ein Risiko, das t3n explizit benennt.

Was „Vibe Coding" technisch bedeutet – und was nicht

Der Begriff stammt von Andrej Karpathy, der ihn im Februar 2025 auf X prägte: „There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." – Es geht um einen Arbeitsmodus, in dem KI-generierter Code ohne Prüfung übernommen wird. Django-Mitgründer Simon Willison warnte bereits im März 2025, dass der Begriff „escaping its original intent" sei und inzwischen jede Form von KI-gestützter Entwicklung umfasse. Diese Verwischung ist kein sprachliches Detail, sondern macht es für Auftraggeber schwer, zu beurteilen, was ein Dienstleister tatsächlich tut, wenn er sagt: „Wir arbeiten mit KI."

Die Werkzeuglandschaft, die Hostinger im Vergleich auflistet, zeigt die Spannbreite. No-Code-Builder wie Hostinger KI Builder (ab 3,99 Euro im Monat) oder Base44 erzeugen eine App per Texteingabe, inklusive Backend, Hosting und SSL – ohne dass eine Entwicklungsumgebung konfiguriert werden muss. Lovable (25 Euro im Monat) und Bolt.new liefern echten React- und TypeScript-Code, der sich an einen Entwickler übergeben lässt. Replit bietet eine browserbasierte Umgebung mit über 50 Programmiersprachen und integrierten PostgreSQL- und SQLite-Datenbanken. Cursor, ein auf VS Code basierender Code-Editor, unterstützt Modelle wie Claude Opus 4.6, Gemini 3 und GPT-5.3 und plant Änderungen über mehrere Dateien hinweg. Windsurf (früher Codeium, 20 Euro im Monat) setzt auf einen Agenten mit persistentem Gedächtnis, der sich Programmierstandards aus früheren Sitzungen merkt.

Die entscheidende Trennlinie zieht MichelyWeb: Für Prototypen, Workshops und frühe Konzeptphasen ist der Ansatz sinnvoll – das bestätigt auch der IONOS Digital Guide. Für eine Produktions-Website, die in zwei Jahren gewartet und erweitert werden soll, fehlen Architektur, Code-Review und dokumentierte Tests. Die Frage, die sich dann stellt, lautet: Wer hat den Code gelesen, wer hat entschieden, welche Teile übernommen werden, und wer steht dafür gerade?

Was jetzt zu tun ist

1. Die anstehende Produktfrage in einen Satz fassen und prüfen, welche Annahme dahinter die riskanteste ist. Erst dann ein KI-Werkzeug wählen – für einen schnellen klickbaren Entwurf ohne Code genügt ein No-Code-Builder oder ein Tool wie Lovable; für einen Prototyp, der später in echte Entwicklung übergehen soll, wäre ein Code-Output wie von Replit oder Cursor die bessere Grundlage.
2. Den Prototyp mit mindestens drei bis fünf Personen testen, die das Produkt nicht kennen, und dabei explizit nach der Idee fragen, nicht nach dem Design. Ein Satz wie „Was verstehen Sie unter der Hauptfunktion?" filtert besser als „Gefällt Ihnen das?"
3. Bevor der generierte Code in ein produktives System wandert, einen Entwickler oder IT-Verantwortlichen den Code lesen lassen – Architektur, Abhängigkeiten, Sicherheitsrelevanz. Was nicht erklärbar ist, kommt nicht rein.

Das Ärgerliche an Vibe Coding ist ja nicht, dass es funktioniert – es funktioniert, und zwar erstaunlich gut. Das Ärgerliche ist, dass es so gut funktioniert, dass man vergisst, dass da noch jemand hinschauen müsste. Wer jetzt unsicher ist, ob der eigene Prototyp sauber in die Entwicklung übergeht oder ob die generierten Abhängigkeiten im Livebetrieb zu Problemen werden, hat damit schon die richtige Frage gestellt. Wir schauen uns das gerne konkret an – einmal durch den Code, die Architektur und die Abhängigkeiten Ihres Prototyps. Hier erreichen Sie uns.

Beitragsbild: Polina Zimmerman auf Pexels