Sollten Sie Ihren eigenen KI-Demo-Agenten per Vibe Coding bauen?

Können Sie Ihren eigenen KI-Demo-Agenten per Vibe Coding bauen? Einen, der funktioniert, schaffen Sie an einem Wochenende. Ihn jeden Tag vor echte Käufer zu stellen, auf Ihrem echten Produkt, ist ein ganz anderes Projekt. Und von diesem zweiten Projekt hängt Ihre Pipeline ab.

Das gehört zu diesem zweiten Projekt, und so schwierig ist jeder Teil:

Aspekt	Was dazugehört	Schwierigkeit
Ihr Live-Produkt steuern	Logins, Authenticator-Codes, Bot-Schutz und Abläufe, die Änderungen an der Oberfläche überstehen	Sehr schwer
Latenz	Zuhören, denken, sprechen und klicken in etwa einer Sekunde	Sehr schwer
Sprachtechnologie	Eine natürliche Stimme, Sprecherwechsel, Unterbrechungen, Akzente und Störgeräusche	Schwer
Sandboxes	Realistische Demo-Daten, die sich nach jeder Session zurücksetzen und mit Ihrem Produkt synchron bleiben	Schwer
Prompting und Guardrails	Bei der Botschaft bleiben und nie Preise, Funktionen oder Sicherheitsaussagen erfinden	Schwer
Evals	Gespräche bewerten und Verschlechterungen nach jeder Prompt- oder Modelländerung erkennen	Schwer
Übergabe an CRM und Pipeline	Lead-Erfassung, Anreicherung, Sync mit HubSpot oder Salesforce und Follow-up	Mittel
Pflege	All das bei jedem Produkt-Release und jeder Modelländerung erneut prüfen	Nie fertig

Das hören wir oft von Teams, die Karumi evaluieren: „Das könnte doch jemand bei uns schnell per Vibe Coding bauen.“ Der Gedanke ist nachvollziehbar. Coding-Agenten sind inzwischen sehr gut. Ein LLM an einen Headless Browser anbinden, eine Voice-API ergänzen, auf Ihre App richten, und am Sonntagabend spricht etwas und klickt sich durch Ihr Produkt.

Wir haben aber auch gesehen, wie es weitergeht. Teams, die selbst gebaut hatten, kamen zu uns zurück, als sie merkten, wie aufwendig und teuer es ist, das System aufzusetzen und am Laufen zu halten. Dieser Beitrag zeigt, worauf sie gestoßen sind, nachdem der Prototyp funktionierte.

Was macht ein per Vibe Coding gebauter Demo-Agent richtig?

Die Grundschleife ist heute wirklich einfach. Ein LLM kann eine Seite lesen, entscheiden, was angeklickt wird, und erklären, was es sieht. Eine Voice-API bringt es zum Sprechen. Ein Coding-Agent baut das Gerüst für all das in wenigen Stunden.

Für eine interne Demo reicht das. Für einen Käufer nicht, denn ein Prototyp muss nur einmal funktionieren, und zwar für jemanden, der will, dass er funktioniert.

	Wochenend-Prototyp	Agent vor echten Käufern
Publikum	Ihr eigenes Team, das jubelt	Skeptische Käufer, die beim ersten Fehler abspringen
Produktzustand	Eine eingeloggte Session auf einem Laptop	Tausende Sessions, jede mit eigenem Login, eigenen Daten und eigenem Timing
Gespräch	Fragen nach Drehbuch	Preise, Wettbewerber, Sicherheit, „Kann es X?“
Wenn es scheitert	Ein Lacher	Ein verlorener Deal und ein schlechter erster Eindruck
Lebensdauer	Eine Demo	Jeden Tag, über jedes Release hinweg
Verantwortlich	Wer es am Samstag gebaut hat	Braucht jemanden, dauerhaft

Die Lücke zwischen diesen beiden Spalten ist das eigentliche Projekt. Und eine Demo ist ein Ort, an dem Sie sich keinen Ausfall in Produktion leisten können: Wenn sie scheitert, dann vor genau dem Käufer, den Sie am meisten überzeugen wollten.

Was müssen Sie beherrschen, um einen zu betreiben?

Ein Demo-Agent in Produktion ist nicht eine Technologie. Es sind mindestens vier, und jede ist ein eigenes Fachgebiet:

• Sprachtechnologie. Speech-to-Text, Text-to-Speech, Sprecherwechsel, Unterbrechungen, Akzente und Hintergrundgeräusche. Eine Stimme natürlich klingen zu lassen und zu erkennen, wann der Käufer ausgeredet hat, ist ein Fachgebiet für sich.
• Sandboxes. Eine Kopie Ihres Produkts mit realistischen Daten, die sich nach jeder Session zurücksetzt, mit dem synchron bleibt, was Sie ausliefern, und nie einen echten Kunden preisgibt.
• Prompting. Anweisungen, die den Agenten bei der Botschaft, bei Ihrem Produkt und innerhalb Ihrer Guardrails halten, über Tausende Gespräche, die er noch nie gesehen hat.
• Evals. Eine Methode, Gespräche zu bewerten und Verschlechterungen zu erkennen, damit Sie wissen, dass eine Prompt- oder Modelländerung die Dinge verbessert hat und nicht verschlechtert.

Dazu kommt die Latenz, die alle vier betrifft. In einem gesprochenen Gespräch wirkt eine Pause von mehr als etwa einer Sekunde wie ein Fehler, und der Agent muss in diesem Zeitfenster zuhören, denken, sprechen und ein Live-Produkt bedienen. Um sie zu senken, muss jede Stufe gestreamt werden, Modelle müssen nach Geschwindigkeit und Qualität ausgewählt und Seiten vorgeladen werden, bevor der Käufer fragt. Das ist entscheidend und einer der schwierigsten Teile.

Warum ist die Steuerung eines Live-Produkts der schwierige Teil?

Hier steckt der Großteil unserer eigenen Engineering-Zeit, nicht im Chat. Wer Ihr echtes Produkt statt einer Aufzeichnung zeigen will, muss all das lösen:

• Logins, die sich wehren. SSO, Anmeldeseiten, die zuerst nach der E-Mail fragen, Magic Links, Authenticator-Codes und Sessions, die mitten in einer Demo ablaufen. Der Fehler sieht oft wie Erfolg aus: Der Agent glaubt, er sei eingeloggt, während er auf einer Login-Seite festhängt.
• Bot-Schutz. Cloudflare, Akamai und ähnliche Tools gibt es, um automatisierte Browser zu blockieren. Lassen Sie zu oft ein Skript auf Ihre eigene App los, kann Ihr Demo-Account gesperrt werden.
• Sichere Demo-Daten. Käufer sollten keine echten Kundendaten sehen und keinen gemeinsam genutzten Account beschädigen. Sie brauchen eine Sandbox, die echt aussieht, sich sauber zurücksetzt und nie die Produktion berührt.
• Eine Oberfläche, die sich ständig ändert. Jedes Release verschiebt Buttons und benennt Seiten um. Fest programmierte Klicks brechen unbemerkt, also brauchen Sie Prüfungen, die einen kaputten Ablauf erkennen, bevor ein Käufer es tut.
• Geschwindigkeit. Eine Demo, die bei jeder Seite acht Sekunden wartet, wirkt kaputt. Vorladen, Caching und das Timing der Erklärung über Ladezeiten hinweg sind jeweils eigene Aufgaben.
• Unterbrechungen. Echte Käufer fallen einem mit „Moment, noch mal zurück“ ins Wort. Der Agent muss anhalten, antworten und dort weitermachen, wo er aufgehört hat.

Nichts davon taucht in einem Prototyp-Video auf. Alles davon taucht vor einem Käufer auf.

Was braucht es, damit das Gespräch vertrauenswürdig ist?

Ein Demo-Agent spricht für Ihre Marke. Einer, der vor einem Käufer Dinge über Ihr Produkt erfindet, richtet mehr Schaden an als gar kein Agent. Ihn vertrauenswürdig zu halten, ist laufende Arbeit:

• Fundierte Antworten. Er sollte auf Basis Ihrer Dokumentation, Case Studies und Positionierung antworten und an Ihr Team übergeben, statt bei Preisen oder der Roadmap zu raten.
• Guardrails. Fragen zu Wettbewerbern, Rabatten, rechtlichen oder sicherheitsbezogenen Aussagen sowie Jailbreak-Versuche müssen alle gezielt behandelt werden.
• Natürliche Stimme. Niedrige Latenz, Unterbrechungen, Pausen und eine Erklärung, die synchron zu dem bleibt, was auf dem Bildschirm passiert.
• Sprachen. Wenn Sie in mehr als einem Markt verkaufen, muss jedes Skript, jeder Ablauf und jede Antwort in jeder Sprache funktionieren.
• Review. Jemand muss jede Woche Gespräche lesen, bewerten und schwache Antworten verbessern. Sonst lässt die Qualität nach, und niemand merkt es.
• Sicherheitsfragen. Ihr Security-Team wird fragen, wohin Transkripte gehen und welche Modellanbieter sie sehen. Sie brauchen die Antworten, bevor die Frage kommt.

Ist der Agent nicht schon das ganze Produkt?

Nein. Der Wert eines Demo-Agenten liegt in dem, was er für Ihre Pipeline leistet, und selbst gebaute Bots hören meist beim Gespräch auf. Vertrieb und Marketing brauchen alles, was dazugehört:

• Einstiegspunkte pro Kampagne, damit LinkedIn, Events, Ihre Website und Outbound jeweils einen eigenen Link, eine eigene Begrüßung und einen eigenen Startablauf bekommen und Sie sehen, welcher Kanal funktioniert.
• Lead-Erfassung und Anreicherung: wer der Besucher ist, von welchem Unternehmen er kommt und ob er zu Ihrem ICP passt.
• Übergabe an Ihren Stack: Qualifizierte Sessions landen mit einer Zusammenfassung in HubSpot oder Salesforce, der richtige Vertriebsmitarbeiter wird benachrichtigt, und das Follow-up geht automatisch raus.
• Erkenntnisse: die Fragen, die Käufer am häufigsten stellen, wo sie abspringen und welche Einwände aufkommen.
• Bearbeitung ohne Code, damit Marketing und Sales Engineers Skripte und Abläufe ändern können, ohne ein Ticket zu eröffnen.

Jedes davon ist ein kleines Produkt für sich. Bauen Sie sie intern, wird Ihr Demo-Bot zu einer internen Plattform mit eigener Roadmap.

Was kostet es wirklich, selbst zu bauen?

Vibe Coding macht die erste Version fast kostenlos. Die nächsten hundert Versionen macht es nicht kostenlos, und genau dort liegen die Kosten.

• Jedes Produkt-Update ist ein Demo-Update. Jedes Release kann einen Button verschieben, eine Seite umbenennen oder einen Ablauf ändern. Jemand muss die Journeys erneut prüfen, die Sandbox aktualisieren, die Skripte anpassen und die Evals neu ausführen, und zwar bei jedem Release.
• Jemand muss dafür verantwortlich sein. Wenn die Person, die ihn gebaut hat, zurück ins Kernprodukt wechselt oder das Unternehmen verlässt, bricht der Bot still und leise zusammen. Generierter Code, den niemand vollständig versteht, lässt sich schwer übergeben.
• Der Stack darunter bewegt sich ständig. Anbieter von LLMs, Voice und Browser-Automatisierung ändern alle paar Monate Modelle, Preise und APIs. Jede Änderung bedeutet eine weitere Testrunde und oft eine Neuentwicklung.
• Er konkurriert mit Ihrer Roadmap. Jede Engineering-Woche, die in den Demo-Bot fließt, fehlt dem Produkt, das Sie eigentlich verkaufen.
• Time to Value. Von einer funktionierenden internen Version bis zu einem Agenten, den Sie Käufern bedenkenlos zeigen können, vergehen meist Monate. Die Pipeline, die das Projekt rechtfertigen sollte, wartet so lange.

Der ehrliche Vergleich ist also nicht ein Abo gegen ein Wochenende Programmieren. Es ist ein Abo gegen ein Teilzeit-Engineering-Team auf unbestimmte Zeit, plus die Deals, die Ihnen entgehen, solange gebaut wird.

Wann lohnt es sich, selbst zu bauen?

Selbst bauen ist die richtige Wahl, wenn alle drei Punkte zutreffen:

1. Ein KI-Demo-Agent ist der Kern dessen, was Sie verkaufen, und kein Kanal, um etwas anderes zu verkaufen.
2. Sie können dauerhaft ein eigenes Team dafür abstellen, nicht nur für einen Sprint.
3. Es ist für Sie in Ordnung, Monate zu warten, bis Käufer ihn sehen.

Wenn nicht, ist das Nützlichste, was Ihr Team per Vibe Coding bauen kann, ein Prototyp dessen, was es sich wünscht. Geben Sie diese Wunschliste an eine Plattform, die Logins, Sandboxes, Guardrails, Stimme, Analytics und CRM-Übergabe bereits beherrscht, und investieren Sie Ihre Engineering-Zeit in Ihr eigenes Produkt.

Genau das macht Karumi. Der Agent lernt Ihr Produkt, indem er es erkundet, bedient es live, während er mit dem Käufer spricht, und überträgt jede Session in Ihr CRM. Die meisten Teams sind in zwei Wochen live, und wir übernehmen die Pflege.

FAQ

Können wir nicht mit einem Prototyp anfangen und später wechseln?

Können Sie, und ein Prototyp ist ein guter Weg, um herauszufinden, was Sie wollen. Planen Sie den Wechsel aber ein: Die Arbeit nach dem Prototyp verursacht den Großteil der Kosten, und Käufer, die eine kaputte Demo sehen, kommen nicht für einen zweiten Blick zurück.

Was, wenn sich unser Produkt jede Woche ändert?

Das ist das stärkste Argument gegen fest programmierte Abläufe. Karumi lernt Ihr Produkt neu, während es sich ändert, sodass eine umbenannte Seite oder ein verschobener Button die Demo nicht lahmlegt.

Verlieren wir die Kontrolle, wenn wir nicht selbst bauen?

Nein. Ihr Team schreibt die Skripte, wählt die Abläufe aus und legt die Guardrails fest. Was Sie abgeben, ist die Infrastruktur: Browser, Logins, Stimme, Sandboxes und die Integrationen.

Wie vergleichen wir beides fair?

Wählen Sie einen zentralen Ablauf, der Ihren Käufern wichtig ist, und testen Sie beides eine Woche lang daran: Ihren Prototyp und einen Karumi-Agenten, mit denselben Fragen. Zählen Sie, wie oft jeder die Demo ohne Fehler durchläuft.