So fühle ich mich über Vibe-Coding. Jedes Projekt, das ich versuche und das irgendeine Art von Komplikation hat, hat diesen sofortigen Fortschrittsschub. Die Dinge sind erstaunlich und es fühlt sich an wie eine Superkraft. Dann... wenn ich mehr Komplexität hinzufüge, kommt alles zum Stillstand. Die einzigen Projekte, von denen ich denke, dass ich sie erstellen kann, sind solche, die in diese "Vibe-Zone" fallen. Prototypen, UIs, Produkte – alles, was einfach ist und eine niedrige Komplexität hat, passt genau in diese Zone. Machbarkeitsstudien, Interaktionen, solche Sachen. Die Werkzeuge können Dinge erstellen, die in diesen Slot passen. Aber. Alles zerfällt, wenn die Komplexitätskurve steigt. Und das Problem ist, dass jeder gute Produktdesignprozess zunehmende Komplexität hat. Ein einfacher Prototyp wird zu einem guten Prototyp, sobald er geschichtete Interaktionen, Übergänge, gute Affordanzen, Hover-Zustände, 1000 winzige Details hat, die etwas richtig und real erscheinen lassen. Der Vorteil des Vibe-Codings soll sein, dass man schnell vorankommt und Dinge schnell erstellen kann – die KI alles für einen erledigen lässt. Das Problem ist, dass es an Schwung verliert, sobald die notwendige Komplexität hinzugefügt wird. Es wiederholt sich ständig, schreibt Code neu, beeinflusst Dinge, die nicht miteinander verbunden sind, und verursacht dann andere Probleme. Aber wenn man diese Komplexität hinzufügt, verwandelt sich jede Vibe-Coding-Sitzung schnell in eine Whack-a-Mole-Bug-Bashing-Sitzung. Ich bin mir nicht sicher, was die Lösung dafür ist. Bei traditionellem Prototyping besteht die Lösung darin, zu duplizieren, mehr Komplexität hinzuzufügen, mehr Frames/Szenen zu erstellen, zu optimieren, zu forken usw. Beim Vibe-Coding kann jedoch ein kleiner Prompt buchstäblich alles zerstören. Es gibt eine Phase, in der ich auf "Prompt-Eierschalen" gehe – versuche, ihm nicht zu viel oder zu wenig Kontext zu geben, damit es nicht aus dem Ruder läuft und alles kaputt macht. Es gibt nur wenige Ausnahmen davon. @cursor und @framer. Ich kann mit Cursor große Fortschritte machen, ihm engen Kontext geben, und ich muss die Änderungen, die es vornimmt, genehmigen. Das fühlt sich nach einem richtigen Workflow an. Das Problem ist, ich kann das, was es erstellt, nicht sehen, weil es eine IDE ist, kein visuelles Umfeld. Ja, ich kann lokale Builds erstellen und meinen Browser aktualisieren und all das. Aber der visuelle Aspekt geht völlig aus der Codiererfahrung verloren. Es ist ein Entwicklerwerkzeug. Framer macht das richtig, weil es nur enge Updates innerhalb einer einzelnen Komponente auf der Seite zulässt. Ja, es ist einschränkend, weil es nur eine Sache auf einmal tun kann, aber zumindest versucht es nicht, die gesamte Seite von Grund auf neu zu erstellen und alles über eine Prompt-Schnittstelle zu verwalten. Das scheint der richtige Ansatz zu sein. @Cursor: Erlaube der KI, alles zu bearbeiten, aber erlaube dem Benutzer, diese Änderungen zu genehmigen und sie im Kontext zu sehen. @Framer: Erlaube der KI, nur eng eine einzelne Datei oder Komponente zu bearbeiten, um die Komplexität auf ein Minimum zu reduzieren und katastrophale Änderungen zu vermeiden. Ich bin optimistisch, dass Werkzeuge wie @Figma, @Lovable, @Bolt und @V0 coole Prototypen erstellen können, aber ich stoße immer wieder auf Wände, wenn es darum geht, mehr als nur einen grundlegenden Interaktionsprototyp zu erstellen. Sie müssen meiner Meinung nach weniger tun. Ich hoffe, dass diese Werkzeuge mehr Kontrollen hinzufügen, die in der gleichen Linie wie Cursor und Framer liegen. Ich möchte auch hinzufügen, dass dies ähnlich ist, wie wir es mit der @Basedash-Diagrammerstellung machen. Aber wir sind kein Vibe-Tool im normalen Sinne, sodass die Parallelen etwas schwieriger zu ziehen sind.