Lovables Vent Tool: Wenn der Agent selbst Bugs meldet

Warum das relevant ist – auch wenn ihr nicht Lovable seid

Lovable hat im Mai zwei Loops vorgestellt, die ihren Agenten kontinuierlich besser machen – ohne dass ein Mensch in der Mitte sitzt. Das ist nicht nur ein Lovable-Thema. Das ist eine Blueprint für jedes Team, das eigene Agenten in Produktion betreibt.

Für uns als AI First Builder ist das hochrelevant: Wir bauen für Kunden zunehmend Agenten in monday, Make und Custom-Stacks. Die Frage "wie wird der Agent über die Zeit besser, ohne dass wir jeden Bug händisch debuggen?" wird damit operativ beantwortet.

Die zwei Loops

Loop 1: Lovable Stack Overflow (LSO)

Der Agent hat eine kuratierte Wissensbasis – kein Wiki für Menschen, sondern ein Lookup für sich selbst. Jeder Eintrag hat zwei Teile:

description: |
  Fix React errors from duplicate React copies in the bundle
  (null hook errors, "render2 is not a function", blank screens).
knowledge: |
  Multiple React copies break hooks. Fix with `resolve.dedupe` in
  vite.config.ts. Downgrade react-leaflet to v4, use framer-motion v11+.
  Diagnose with `npm ls react`.

Vor jeder Prompt-Ausführung läuft ein leichter Klassifizierer: Passt einer der Einträge zur aktuellen Situation? Wenn ja, wird die Lösung in den Kontext injiziert. Wenn nein, kein Overhead.

Ergebnis: 5% weniger Stuck-Rate, 2% mehr Publish-Rate – ohne Latenzkosten.

Drei Learnings, die übertragbar sind:

1. Wissen veraltet. Lovable löscht zufällig Einträge und misst per A/B, ob sie noch helfen. Tut man das nicht, vergiftet der Stack Overflow sich selbst.
2. Failure Modes sind modellspezifisch. Bei jedem Model-Switch muss neu kalibriert werden.
3. Synthese statt Dump. Lieber 5 präzise Zeilen injizieren als die ganze Doku. Tokens sind teuer.

Loop 2: Das Vent Tool

Der zweite Loop ist der spektakulärere: Der Agent kann seinen Frust per Tool-Call direkt nach Slack posten. Ein zweiter Debug-Agent monitort den Channel und baut bei aktionablen Vents automatisch einen PR.

Zahlen aus dem Lovable-Blog:

• ~20% der Vents sind aktionable
• ~10 gemergte Fixes pro Tag, ohne dass ein Mensch Code schreibt
• False-Positive-Rate der Auto-PRs: ~50% (egal, weil Triage billig ist)
• Kein messbarer Impact auf Cost, Latency oder Output-Qualität

Der wichtigste technische Trick: Sie haben die expliziten Eligibility-Kriterien wieder aus dem System-Prompt rausgenommen und stattdessen mit wenigen Beispielen gearbeitet. Modell-Judgment + Beispiele schlugen jeden Rubric.

Was wir daraus mitnehmen

Drei Patterns, die wir in eigenen Projekten adaptieren:

Pattern	Übertragung
Knowledge-Injection statt System-Prompt-Bloat	Für monday-Agenten: kleine, situativ injizierte Snippets statt 8K-Token-Prompts
Stuck-Detection via LLM-Judge	Externer Judge auf Konversationen, nicht der Agent selbst
Agent-Telemetrie als Feedback-Kanal	Tool-Call, der ins interne Slack postet – nicht Logs, die niemand liest

Wo das in der Anti-McKinsey-Sicht reinpasst

Der klassische Beratungsansatz wäre: "Wir machen ein Quartals-Review der Agent-Performance, identifizieren Verbesserungspotenziale, priorisieren in einem Workshop."

Der Lovable-Ansatz ist das Gegenteil: 10 Fixes pro Tag, automatisch, ohne Workshop. Das ist genau der Builder-Approach – kleine Loops, hohe Frequenz, Compound-Effekt.

Lesetipps

• Lovable Skills – wiederverwendbare Agenten-Anweisungen
• Agent Skills als Industriestandard
• Originalartikel: We Gave Our Agent a Vent Tool
• Alle Lovable-Ressourcen