Vibe This! Alpha Phase

Vibe This (Alpha Launch)

Mit Monkey Ideas wollte ich untersuchen, ob man die Vorarbeit für Entwicklungsprojekte an den neuen Entwicklungsprozess mit KI anpassen kann. Insbesondere, weil aus meiner Sicht die Arbeit an Produktideen und Spezifikationen dann zum Bottleneck werden kann, wenn Projekte zunehmend schnell durch den Einsatz von generativen LLMs umgesetzt werden können. Monkey Ideas war vorrangig auf die lokale Umgebung ausgerichtet und zielte auf Self-Hosting sowie den Einsatz lokaler LLMs ab. Auf Basis dieser Erfahrung bin ich nun in die Entwicklung von Vibe This! eingestiegen und habe kürzlich die erste Version als closed Alpha gelaunched. Hier eine kurze Vorstellung von VibeThis!

VibeThis richtet sich an eine neue Techie-Spezies

VibeThis richtet sich an eine neue Spezies: Entwickler, die immer mehr zum KI-Stakeholder werden und sich stärker darum kümmern müssen, das Geplante zu artikulieren, so dass die richtigen Dinge in der richtigen Weise erfolgen. Oder an Produktleute, die nun ’technischer’ werden durch die Kollaboration mit Code-Agenten. Oder an Vibe-Coder, die vielleicht einfach nur eine neue Idee suchen, die sie ‘dem Vibe folgend’ mit KI umsetzen. Immer mehr Dinge lassen sich als 1-Personen-Team umsetzen. VibeThis ist Sparringspartner für die Ideenentwicklung in solchen Teams.

Die Entwicklung mit Tools wie Cursor bringt immer noch Herausforderungen mit sich. Für den klassischen Entwickler kann die Zusammenarbeit mit LLMs mitunter gewöhnungsbedürftig sein. Es entspricht nicht dem Gewohnten, in die Produkt-Rolle zu schlüpfen, zu vertexten, was hergestellt werden soll und welches Problem für eine Zielgruppe gelöst werden soll. So etwas muss nicht, kann aber einen Perspektivwechsel bedingen. VibeThis kann hier spielerisch unter die Arme greifen und bei der Ideengenerierung und -verwaltung helfen. Produktleute können mit VibeThis einfach auf die Suche nach neuen Optionen gehen, dem Ideen-Ping-Pong frönen und schnell Specs generieren, die als Grundstock für einen Prototypen herhalten mögen. VibeCoder, die eine neue Projektinspiration suchen, können VibeThis benutzen, um sich inspirieren zu lassen.

Jeder Jeck ist anders

… der eine möchte einfach ohne viel Schnick-Schnack eine ‘RANDOM’-Idee aus der Wunderkiste sehen, verwerfen, damit weiterdenken. Der andere möchte möglichst viel Kontrolle haben und die neue Produktidee anhand der eigenen Parametern entwerfen. In VibeThis kann man selbst entscheiden, wie viele Parameter man determinieren möchte. Man kann mit einem Klick alles randomisieren / generieren und sich vollends überraschen lassen oder das Problem genau eingrenzen und Details aufklappen, um eine Menge Parameter einzustellen.

Das Ziel der Ideengenerierung ist bei VibeThis immer ein technisches Entwicklungsprojekt. Neben einer Zielgruppe und dem zu lösenden Problem können daher auch technische oder Design-bezogene Aspekte konfiguriert werden.

Die Summe aller Parameter fließt in eine Prompt-Generierung ein und es wird ein Pitch für eine Idee generiert. Dieser kann auch umgeschrieben werden und dient daher als neuer Ausgangspunkt für die Ideenarbeit (wobei alle Eingangsparameter nicht verloren gehen). Der knappe Pitch der Idee kann so bereits veröffentlicht werden (was aber nicht zwingend nötig ist). Durch die Veröffentlichung kann man die eigenen Ideen mit der Community teilen und es ist anderen möglich, die Idee zu bewerten. Ideen können natürlich auch ‘privat’ bleiben. In jedem Fall kann man auf Basis der ersten Grundlagen nun an den Spezifikationen arbeiten. Diese können initial generiert und dann verfeinert werden. Schließlich kann man das Markdown der Spezifikation kopieren oder herunterladen, um den Coding Agent damit zu füttern.

Kollaborativ am Ideenpool arbeiten

Ideen können veröffentlicht, bewertet und ‘geforkt’ werden. Das bedeutet, dass man eine veröffentlichte Idee ‘klauen’ bzw. ‘klonen’ und diese dann nach Belieben verändern kann. Öffentliche Ideen können durchsucht werden und selbst kann man eine Idee auch ganz einfach als Link oder via QR-Code teilen.

Als Alternative zur Übersichtsseite, kann man sich auch die ‘Random’ Seite anschauen, in der eine zufällige Idee zur Schau gestellt wird.

Um den Überblick über die eigenen Ideen nicht zu verlieren, gibt es eine gesonderte Ansicht, in der man Favoriten markieren kann und schnell den Sichtbarkeitsstatus umsetzen / ändern kann (öffentlich / privat).

Learnings

Design hat einfach immer Vor- und Nachteile

Ich bin mit einem grobkörnigen Neo-Brutalistischen Design gestartet, als ich mit dem Layoutentwurf begonnen habe … vielleicht, weil ich das Gefühl hatte, dass es irgendwie zum Thema passt. Von der Attitüde her, finde ich auch immer noch, dass es passt. Allerdings entstehen durch die grob geschnitzten Pixel-Blöcke auch erhebliche Nachteile, was die inhaltliche Gestaltung im Kontext von vielen Informationen und die Platzökonomie im Allgemeinen betrifft. Auch manche Farbgebung hat nicht immer geholfen. Ein Feedback war: “…Die Farbe bei … schmerzt etwas beim anschauen”. Im Nachhinein hätte ich eventuell bei einigen Design-Annahmen anders bzw. reflektierter vorgehen sollen.

Modell-Rotationen

Zum Einsatz kommen verschiedene Konzepte, was die Verwendung von LLM-Modellen betrifft. Einerseits verwende ich LangChain für die Integration, andererseits habe ich hier funktionale Abhägigkeiten, die mir nötig machen, auch eine weitere Abstraktion einzuziehen, die für mich die Umgebungen (etwa lokale Entwicklung vs. Staging vs. Produktion) mit einbezieht. Lokal kann ich z.B. problemlos zwischen Ollama und Cloud-Modellen wechseln, in einer Produktionsumgebung habe ich aber keinen Ollamaansatz vorgesehen. Ferner versuche ich ein halbwegs intelligentes Modell-Routing zu ermöglichen, um gute Antworten zu erhalten, aber auch um die Kosten zu minimieren und die Antwortzeiten zu optimieren. Mit einer Admin-seitigen HotSwap Funktion kann ich präferierte Modelle inkl. Fallbackmodelle aus einer aktuellen Liste auswählen. Cool dabei ist, dass ich so auch ganz simpel im laufenden Betrieb zwischen Mistral und Nemotron (oder was auch immer) wechseln und so die Unterschiede testen kann.

Und dennoch: der Umgang mit verschiedenen Modellen und Providern ist ein Thema für sich. Dazu kommen Themen wie Caching usw. die noch nicht damit zu tun haben, ob Prompts gut oder schlecht funktionieren. Entwicklern rate ich, sich mit diesen Design und AI-Ops Themen lieber früher als später auseinanderzusetzen, wenn es darum geht, Anwendungen mit ‘KI-Feature’ zu entwickeln.

(Unvorhersagbaren) Output darstellen

Ich habe jüngst ein paar Erweiterungen vorgenommen, um den inhaltlichen Spielraum bei der Spezifikationsgenerierung zu vergrößern. Konkret wollte ich Mermaid-Code in die Spezifikationen einbauen und diese dann in eine grafische Darstellung umsetzen. Hier müssen Modelle und mein Parsing-Code nicht immer einer Meinung sein. D.h. es kann passieren, dass ein Modell mermaid-ähnlichen Code generiert, der aber nicht valide ist oder von meinem Code nicht richtig zur Darstellung umgesetzt wird. Ein wenig liegt das in der Natur der Sache, denn Funktionen wie diese sind nicht 100%ig vorhersagbar und somit by Design nicht 100%ig fehlerfrei. In Folge kann es passieren, dass ein Markdown-Diagramm nicht richtig dargestellt wird.

Gradwandern zwischen Typsicherheit und RandomStuff

LLMs erzeugen nicht unbedingt das als Output, was man sich in einer typsicheren Anwendung erwartet. Es gibt hier immer mehr Ansätze, um diesem Umstand gerecht zu werden, aber die Frage ist auch immer, wie weit man es eigentlich treiben will. Vieles hängt sicher vom Anwendungsfall und Nutzungsszenario ab, denn manchmal ist Text als Output völlig ok. Wenn ich aber mit dem Text weiterarbeiten möchte, wie im Falle der Specs bei VibeThis, dann sind hier zumindest ein paar konzeptuelle Gedanken neben der Textdarstellung und der applikationsseitigen Typisierung wichtig. Das alles ist ein Thema für sich, doch noch bin ich nicht sicher, ob es zum jetzigen Zeitpunkt bereits die universelle Antwort geben kann, um die textbasierte Generierung und strikte Typisierung immer sinnvoll in Einklang zu bringen.

Ausblicke

Momentan möchte ich die Grundfunktionalität noch testen, mir eine Meinung durch den praktischen Einsatz aufbauen und viel Feedback sammeln. Aber es gibt bereits viele Dinge, die ich auf die Roadmap gesetzt habe. Viele kleine Dinge sind irgendwie naheliegend, um den konkreten Nutzen für die User zu erhöhen. Doch spannend wird sein, welche Richtung das Tool einschlagen wird, da sich dies vor allem aus der Verwendung ergeben wird.

Fazit

Nach Monkey Ideas ist VibeThis ein für mich logischer nächster Schritt, um Ideenarbeit und KI-Funktionalität zu verbinden. Bei VibeThis geht es im Vergleich nicht um das lokale KI-Setup, sondern vielmehr um die ‘Community’ Edition, die anderen bei der Ideenfindung und -entwicklung helfen soll. Eine konkrete Zielgruppe sind hier Entwickler, die inzwischen AI-augmented arbeiten oder plakativ: VibeCoder. Doch schließt VibeThis andere Personengruppen mit ein, nämlich alle, die auf der Suche nach technischen Produkt- oder Projektideen sind.

Von der ersten VibeThis-Codezeile bis zum Alpha-Launch wurde nicht viel Zeit benötigt. Produkte lassen sich immer schneller erstellen. Auch wenn viele noch diskutieren, ob das stimmt, für mich steht fest, dass die Zukunft von Kreativität, dem Mut zur Umsetzung und guten Ideen abhängt. Deshalb ist VibeThis für mich bereits in der Alpha ein Erfolg.