Vibe(d) This!: Learnings aus AI-Driven Development

Vibe This – ein Monkeylabs Projekt

VibeThis ist ein aktuelles Monkeylabs-Projekt, mit dem ich untersuche, wie sich Ideengewinnung und Spezifikationsarbeit für Softwareprodukte an eine Entwicklungsrealität anpassen lässt, in der inzwischen KI-gestützte Code-Erzeugung zum Alltag gehört. In diesem Ansatz steht nicht das Projektmanagement im Vordergrund, sondern die Ideengenerierung und Spezifikation. Die Funktionen von Vibe This beschäftigen sich mit der Phase vor der eigentlichen Umsetzung: dem Generieren, Formulieren, Nachjustieren und Spezifizieren von Ideen für Software oder App-Projekte.

Mit VibeThis untersuche ich zugleich ein Problem, das sich im Zuge von AI-driven Development verschärft: Wenn sich Software immer schneller mit generativen LLMs, spezialisierten IDEs und Code-Agenten umsetzen lässt, dann verlagert sich vermutlich der Engpass in Richtung Produktidee und Spezifikation. Die Frage lautet nicht „Wie bauen wir das?", sondern immer häufiger „Welche Idee setzen wir um – und wie formulieren wir es so, dass Mensch und Maschine es verstehen und eine vernünftige Lösung herauskommt?"

Projektgenealogie - Von Monkey Ideas zu VibeThis

Mit Monkey Ideas habe ich vor einiger Zeit untersucht, ob man die Vorarbeit für Entwicklungsprojekte stärker an lokale KI-Setups und Self-Hosting anlehnen kann. Der Fokus lag dort eher auf der eigenen Umgebung, auf lokalen LLMs und Tools, die sich gut in individuelle Workflows integrieren lassen. Monkey Ideas unterstützt die Ideen und Backlogerstellung und bietet MCP-Funktionen für Tools wie Cursor. Auf diese Weise werden Backlogs dann abgearbeitet.

VibeThis setzt an ähnlicher Stelle an, geht aber einen Schritt weiter: Weg von der lokalen Nutzung, hin zu einer „Community Edition" für Ideengenerierung und Spezifikation. Die erste Version ist derzeit als Closed Alpha im Testeinsatz. Ziel von VibeThis ist es, einen Sparringspartner für all diejenigen zu schaffen, die schnell Produktideen erzeugen und ausarbeiten.

Für wen ist VibeThis interessant?

Verkürzt kann man sagen, dass VibeThis ein Tool für Vibe-Coder ist. Es richtet sich im weiteren Sinne aber auch an solche Techies, die zunehmend zum KI-Stakeholder werden oder Kreativen, die zunehmend technischer arbeiten. Also:

• Entwickler:innen, die Cursor & Co einsetzen und stärker in die Produktrolle hineinwachsen.
• Produktmenschen, die KI-gestützt selbst z.B. Prototypen zu Testzwecken entwickeln wollen.
• VibeCoder, die eine Idee „aus dem Vibe heraus" Spec-Driven umsetzen möchten.
• Neugierige, die KI zur Ideengenerierung testen oder sich ins Thema einarbeiten wollen.

In allen Fällen geht es darum, das, was gebaut werden soll, so zu artikulieren, dass es anschlussfähig ist: für Teams, für Stakeholder und für KI-gestützte Entwicklungsumgebungen.

VibeThis hilft bei der Ideengenerierung und erzeugt ‘Assets’ wie Spezifikationen, Feature-Listen oder einfache Businesspläne

Ideengenerierung und Spezifikationen

Im Kern ist VibeThis eine App zur Ideengenerierung und -ausarbeitung für technische Projekte mit integriertem Spec-Workflow:

• Generierung von Ideen auf Basis (potentiell) zahlreicher Parameter (Zielgruppe, Problem, Tech-Stack, Design-Anmutung etc.).
• Unterschiedliche „Vibes": vom schnellen RANDOM-Impuls bis zur fein justierten Idee mit vielen einstellbaren Parametern.
• Community-Funktionen wie Veröffentlichen, Bewerten und „Forken" von Ideen.
• Leaderboards und explorative Funktionen zur Inspiration durch veröffentlichte Ideen
• Generierung von kompakten Business Cases, Pitch Decks, Feature-Listen und ausführlicheren Projektspezifikationen.
• Weitere KI-Feature um Feedback zu simulieren, Vorschläge oder Teaser Bilder zu generieren
• Export der Specs als Markdown, z.B. um sie direkt in Coding-Agents, Repos oder IDEs einzuspeisen.

Es gibt unterschiedliche Ansätze und zunehmend mehr Konventionen sowie Tools im Bereich Spec-driven Development (SDD) . Populär ist aktuell etwa Spec Kitty . VibeThis setzt schon vor den Specs an und beschäftigt sich mit KI-gestützter Ideen-Entwicklung, die dann in die Spezifikation übergeht. Projektspezifikationen können dann so exportiert werden, dass sie mit dem SDD Ansatz kompatibel sind und Coding-Agents für die Implementierung hinzugenommen werden können.

Technik

Unter der Haube ist VibeThis eine Full-Stack-App mit LLM-Integration:

• Nuxt 4 / Vue 3 / NodeJS / TypeScript als Frontend- und Anwendungs-Stack
• Supabase für Datenbank (row level security), Authentifizierung und Storage
• LangChain u.a. für die Modellintegration
• OpenRouter / Ollama Adapter für unterschiedliche LLM-Provider
• Coolify im Kontext des Deployments (via nixpacks) und der Verwaltung von Servern/Environments
• UI TailwindCSS, ausgewählte Icons, individuelles Design-System
• Notwendige Erweiterungen für Mermaid Diagramme, State Management, Markdown-Rendering oder WYSIWYG Editoren etc.
• Entwicklung stark unterstützt durch Cursor und KI-gestützte Workflows

Ein Ziel der Architektur ist es, Modell-Routing und -Rotation praxistauglich zu machen: Unterschiedliche Modelle können in verschiedenen Umgebungen (lokal vs. Staging vs. Produktion) zum Einsatz kommen, inklusive Fallbacks und kostensensitiver Auswahl. Über eine Admin-seitige Steuerung lassen sich Modellpräferenzen zur Laufzeit anpassen, um Qualität, Kosten und Antwortzeiten gegeneinander abzuwägen.

VibeThis wollte ich möglichst zügig umsetzen, aber bei einigen Aspekten habe ich etwas mehr Zeit investiert. Ein Beispiel: ich verwende in diesem Projekt Supabase für Authenthifizierung oder Datenhaltung, allerdings ist die Datenbank-Ebene parallel mit Drizzle ORM zusätzlich so abstrahiert, dass ich auf eine andere Postgres Datenbank umschwenken könnte und nicht von Supabase abhänge. Dies ist auch der Ansatz bei der Authentifizierung. Zudem spielen Performance und Skalierungsthemen eine Rolle, die gerade bei KI-Funktionen (LLM-Integration) im Speziellen zu betrachten sind. Z.B. auch deshalb, weil die dynamischen Anteile nicht immer deterministisch sind und oft Typisierung vermissen lassen.

Learnings aus dem Projekt

1. Das Design-Dilemma

Ich bin mit einem Neo-Brutalistischen Design gestartet – vielleicht, weil es zum “Vibe” passte. Von der Attitüde her stimmt das auch. Allerdings entstehen durch grob geschnitzte Pixel-Blöcke erhebliche Nachteile bei Platzökonomie und Informationsdichte. Ein Feedback war außerdem: “Die Farbe schmerzt beim Anschauen.”

Zusätzliches Learning: KI-Agents “vergessen” Design-Systeme über viele Files hinweg. Ohne strikte Component Library entsteht Inkonsistenz. Bei einem 2-Wochen-Sprint ist Design-Debt schwer zu vermeiden.

2. Modell-Rotation in der Praxis

Ich nutze LangChain für LLM-Integration mit einer weiteren Abstraktionsschicht für Umgebungen (lokal/staging/production). Auf der lokalen Umgebung kann ich flexibel zwischen Ollama und Cloud-Modellen wechseln, in Production nutze ich aus Skalierungsgründen Cloud-Modelle.

Mit einer Admin-seitigen HotSwap-Funktion kann ich präferierte Modelle + Fallbacks zur Laufzeit tauschen – z.B. von Mistral zu Nemotron. Das ermöglicht Live-Testing verschiedener Modelle. Gleichzeitig macht es auch die Auswahl der richtigen Modelle und deren Performance-Optimierung zu einem wichtigen Thema. Nicht jedes Modell bringt etwa die gleiche Qualität oder Geschwindigkeit. Neben einem vernünftigen Wrapping ist also auch nötig, die Unterschiede der Modelle zu verstehen, zu bewerten und gezielt zu nutzen. Provider-Management und Caching-Strategien sind weitere wichtige Aspekte. Aus Performance- und Kostenaspekten muss man sich hier einen Ansatz erarbeiten. Weiter ist aber auch ein wichtiger Punkt, eine solide Fehlerbehandlung und Logging-Strategie aufzubauen. Mein Fokus lag neben der Performance-Optimierung auch auf einer Fallback-Strategie, die sicherstellt, dass das System auch bei Fehlern weiterhin funktioniert, sowie einer zusätzlichen Retry-Logik, die bei temporären Fehlern den Output erneut versucht zu generieren.

Learning: Der Umgang mit verschiedenen Providern, Caching und Fallback-Strategien ist ein Thema für sich. Entwickler sollten sich mit AI-Ops früh auseinandersetzen.

3. Typsicherheit vs. Randomness

LLMs erzeugen nicht unbedingt das, was eine typsichere Anwendung erwartet. Beispiel: Ich wollte Mermaid-Diagramme in Specs integrieren. Modelle generieren manchmal mermaid-ähnlichen Code, der nicht valide ist oder von meinem Parser nicht dargestellt wird. Aber auch für viele andere Datenstrukturen kann es vorkommen, dass das LLM nicht das ausgibt, was man erwartet. So muss man nicht selten den Output validieren und behandeln, so dass er für die Anwendung funktioniert.

Learning: Es gibt keinen universellen Ansatz, textbasierte Generierung und strikte Typisierung in Einklang zu bringen. Das hängt stark vom Use Case ab und sollte konzeptuell bedacht werden.

4. Unvorhersehbaren Output darstellen

Generierte Inhalte sind by design nicht 100% fehlerfrei, können syntaktisch inkorrekt oder inhaltlich unvollständig sein. In der Natur von LLMs liegt daher eine gewisse Unvorhersagbarkeit. Man muss entscheiden, wie viel Output man letzlich “korrigieren” will bzw. wie viel Imperfektion akzeptabel ist. Bei manchen Funktionalitäten, die generierten Content parsen und rendern musste ich viele Extrarunden einlegen, bis der Output akzeptabel war. Ein Beispiel sieht man weiter unten - generierte Mermaid Diagramme. Im Falle der generierten Specs (die insgesamt komplex sein können) müssen viele verschiedene Aspekte berücksichtigt werden, wenn es um die reine Darstellung für den Benutzer geht. Da das LLM im Hintergrund zwar strukturiert arbeiten soll, aber dennoch nicht vorhersagbar agiert, muss man sich mit dem Output intensiv auseinandersetzen und ihn entsprechend darstellen.

5. Allgemeine Erfahrungen

Positiv muss ich sagen, dass es im Grunde gut funktioniert, KI-Feature in eine Applikation zu integrieren. Auch wenn viele Herausforderungen dabei sind, ist es heute auch als 1-Personen-Team möglich, Applikationen in kurzer Zeit umzusetzen, die dynamische bzw. generative Anteile haben und damit zu neuen Möglichkeiten führen. Die KI-gestützte Entwicklung (in diesem Falle mit Cursor) funktioniert auch bei komplexeren Projekte inzwischen sehr gut, solange man die Herausforderungen ernst nimmt, einen Plan hat und sich mit Architektur, Konzept, dem generierten Code und Testing auseinandersetzt.

Unerwartete VibeThis Lieblingsfeatures

Mich hat erstaunt, wie gut künstliches Feedback für das Tool funktioniert. Agent Feedback (z.B. von einer Kunden-Persona) wird an manchen Stellen im Tool verwendet. Im Bild unten zu sehen: Feedback Optionen für einzelne Sektionen der Spezifikation. Feedback von Agents kann hier z.B. mit dem eigenen Feedback kombiniert und dann für die Neugenerierung ganzer Passagen verwendet werden. Interessant ist dies auch bei Feature-Ideen (~ Wishlist), zu denen man etwa Benutzer- / Kundenfeedback einholen kann. Die Benutzer oder Kunden sind hier allerdings Agenten. Es gibt auch Produkt-, Entwickler- oder Produktfeedback für neue Feature-Kandidaten. Dies kann man generieren und dann für das weitere Refinement (generiert) als Kontext verwenden. So verdichtet sich die Anforderungsbeschreibung, deckt mehr Sichtweisen ab und wird häufig besser / präziser.

An anderen Stellen gibt es ‘Vorschläge’, die im Kontext einer Idee oder eines Features generiert werden. Weitere ‘Neu-Generieren’ Funktionen gibt es auch häufig in der Art, dass das User Feedback und sämtliche relevante Kontextinformationen mit einbezogen werden, so dass ein Inhalt entsteht, der die neuen Informationen mit einbezieht und somit optimiert wird. Bei den Spezifikationen ist dies am komplexesten realisiert. Jeder Abschnitt kann neu generiert werden, wobei das Feedback und der Kontext berücksichtigt werden und die Abschnitte versioniert werden. Denn auf diese Weise kann nachvollzogen werden, welches Feedback auf welche Version bezogen war.

Zu jeder Idee kann man sich ein Teaser Bild generieren lassen, das die Quintessenz der Idee visuell auf den Punkt bringt. Das war mir wichtig, damit andere VibeThis Nutzer nicht erst eine Wall of Text lesen müssen, sondern sich schneller ein ‘Bild von der Idee’ machen können. Gerade bei dem ‘Durchflippen’ von veröffentlichten Ideen hilft das schnell für die Einordnung (Was ist das überhaupt?). Bei den Bildern wollte ich eine visuelle Ästhetik konsistent durchziehen, damit die Summe der Bilder eine ansprechende visuelle DNA erzeugt, die der Attitüde des Tools zuträglich ist.

Gelungen finde ich auch die (Problem Space) Templates, die einige Parameter für die Ideengenerierung optimiert vorbelegen. Z.B. für ein SaaS MVP oder ein Browser-Game. Ursprünglich waren die Templates für neue Nutzer geplant, aber inzwischen sehe ich hier noch viel mehr Potenzial.

Bigger Picture Kontext: Code-Factories in 2025++

VibeThis ist eines der neuesten von inzwischen zahlreichen Projekten, die ich mit IDE’s wie Cursor (also dem erheblichen Zutun von KI) umgesetzt habe. Für mich steht völlig außer Frage, dass sich die Entwicklungspraxis bereits nachhaltig geändert hat und es letztlich keinen Weg zurück in die alte Welt geben wird. Code wird nicht mehr in erster Linie von Menschen, sondern vermehrt mit der Hilfe von LLMs, maßgenscheiderter Software und viel GPUs entwickelt. KI-fizierte IDE’s oder halbautonome Code-Agenten übernehmen einfach immer mehr Aufgaben, werden immer schneller, günstiger und besser. Es gibt viele gute Gründe für Skepsis gegenüber dieser neuen KI-Welt, und doch lässt sich nur schwer leugnen, welche Optionen sie eröffnet.

Wer Visionen hat, sollte zum Arzt Agent gehen

Was früher als unvernünftig galt, muss neu betrachtet werden. Der neue Entwicklungsprozess (mit KI) führt zu einer Veränderung der Kosten- / Nutzenbewertung hinsichtlich der Innovation und Produktentwicklung.

Ein Beispiel: Ich persönlich bin zwar technisch aufgestellt, habe aber immer deutlich mehr Ideen gehabt, als ich jemals hätte zeitnah umsetzen können. Die technische Realisierung war daher immer der Endgegner - im Sinne eines Aufwands, der in einem sinnvollen Verhältnis zum Nutzen stehen musste. Doch wenn eine SaaS-Idee in zwei Tagen in einen funkionstüchtigen Prototypen überführt werden kann, ändert sich die Ratio.

Jeder, der jemals ein Unternehmen mit der Herstellung einer Softwarelösung beauftragt hat, kann sicher aus eigener Erfahrung sagen, dass man dies nicht mit jeder guten Idee wiederholen würde. Denn wenn ein professionelles Team Software umsetzt ist es zeit- und kostenintensiv. Dieses Naturgesetz löst sich nach und nach auf. AI-augmented Development, oder KI-gestütze Entwicklung zwingt zum Umdenken. Denn Ideen können skalierbarer umgesetzt werden, in kürzerer Zeit, in schnelleren Iterationen.

Eine neue Produktidee hätte man bislang intensiv evaluiert und diskutiert, bevor man Budgets verabschiedet und die Entwicklung mit der Umsetzung beauftragt. Das alte Credo war dementsprechend häufig: erst denken, Meinungen abgleichen, diskutieren, verabschieden und dann machen. Das klingt inzwischen überhaupt nicht mehr sinnvoll. Die Logik von Innovationsfunneln und Prozessen orientiert sich an einer Welt, die ins Wanken geraten ist. Deshalb bedarf es eines Umdenkens (mehr zu diesem Thema hier im Blog ).

Zurück zu VibeThis (und Monkey Ideas) - VibeThis ist zu ~ 80% KI generiert.

Es ist zu ~ 90% ein Tool für das frühe KI-Zeitalter, in der die Kreativität zum limitierenden Faktor wird.

Je schneller die Umsetzung skaliert, je intensiver KI eingesetzt wird, desto wichtiger werden klar formulierte Problemstellungen, artikulierte Produktstrategien und Spezifikationen für Coding-Agents. Neue Prozesse müssen geschaffen und tradiert werden. Tools werden benötigt, die Ideenarbeit zwischen Mensch und Maschine so möglich macht, dass verschiedene Akteure damit umgehen können. Es ist nötig viel mehr Ideen auf einmal betrachten zu können, z.B. um verschiedene Prototypen zu bewerten und darunter auszuwählen. Technische Personen müssen mehr Kompetenz in Abläufen vor und nach der Umsetzung aufbauen, und nicht-technische Personen benötigen eine Möglichkeit KI hinreichend sinnvoll für die Umsetzung zu instruieren.

In diesem Problemraum operieren VibeThis und Monkey Ideas .

Ausblick

Aktuell befindet sich VibeThis in einer Closed Alpha. Im Vordergrund stehen Tests im realen Einsatz, das Sammeln von menschlichem (!) Feedback und die ergebnisoffene Weiterentwicklung.

Langfristig interessiert mich vor allem, wie solche Ansätze die Zusammenarbeit zwischen Menschen und KI und den Prozess bei der Entwicklung von Produkten verändern. VibeThis ist für mich somit auch explorative Wissensarbeit und untersucht Aspekte eines kontinuierlichen Ideenfindungs-, Spezifikations- und Umsetzungsprozesses in einer zunehmend digitalen Umwelt.

Ich bin fest überzeugt, dass Kreativität und Ideenreichtum in der Zukunft noch deutlich wichtiger werden als bisher. Mit Tools wie VibeThis richte ich deshalb den Blick auf die Skalierung der Ideenarbeit.

Bei Interesse an der weiteren Entwicklung oder an der Teilnahme an einer späteren Beta-Runde, lohnt es sich, das Projekt im Blick zu behalten – insbesondere, wenn Du bereits heute AI-augmented arbeitest oder Lust hast, mit VibeCoding experimentell in die nächste Runde zu gehen.