Lovable Model-Routing: Warum sich der Output für Builder schlechter anfühlt

Was sich geändert hat

Lovable schickt Chat-Anfragen nicht mehr an ein Modell, sondern routet je nach Aufgabe auf unterschiedliche Systeme – ein kleineres für Routine-Edits, ein größeres für komplexe Refactors, vermutlich noch weitere für Planung und Tool-Use. Plattform-seitig ist das nachvollziehbar: schneller, günstiger, skalierbarer.

Aus Builder-Sicht – also als jemand, der jeden Tag mehrere Stunden im Lovable-Chat arbeitet – ist der Output dadurch in drei Bereichen spürbar schlechter geworden.

1. Verständnis der Aufgabe

Früher konntest du einen halbgaren Prompt schicken („mach das hier konsistenter mit dem Rest der Seite") und das Modell hat den Kontext aus den letzten Nachrichten und dem Codebase zusammengezogen. Heute ist das Trefferquoten-Glücksspiel:

• Bei kleinen Edits landet die Anfrage offenbar auf einem leichteren Modell, das den impliziten Kontext nicht mehr verlässlich auflöst.
• Mehrdeutige Prompts werden häufiger wörtlich genommen statt interpretiert.
• Rückfragen kommen seltener und an den falschen Stellen – statt nach dem fehlenden Detail wird nach Trivialem gefragt.

Konsequenz für den Workflow: Builder müssen ihre Prompts wieder explizit machen, die das Modell vorher selbst erschlossen hat.

2. Effektives Kontext-Window

Das nominelle Kontext-Window ist groß. Das effektiv genutzte fühlt sich kleiner an als noch im Frühjahr:

• Verweise auf Dateien, die zwei, drei Nachrichten zurückliegen, werden öfter „vergessen".
• Bei längeren Threads schlägt das Modell Lösungen vor, die in derselben Session bereits verworfen wurden.
• Cross-File-Konsistenz (z. B. „benenne das überall um") bricht früher als vorher.

Der wahrscheinliche Grund: das Routing schiebt Folgeanfragen nicht zwangsläufig auf dasselbe Modell. Jeder Modellwechsel ist ein de-facto Kontextverlust, weil interne Caches und Tool-State nicht 1:1 wandern.

3. AI-Empfehlungen im Chat

Der Punkt, der am meisten weh tut: die proaktiven Vorschläge im Chat.

• Vorher: „Du hast gerade X gemacht – willst du gleich Y mitnehmen, sonst bricht Z?" – konkret, codebase-aware, oft genau der nächste Schritt.
• Jetzt: generischere Hinweise, häufig auf Best-Practices-Niveau, ohne Bezug auf das, was tatsächlich gerade im Repo passiert.

Für Builder, die Lovable als Pair-Programmer nutzen, war das einer der Hauptwerte. Wenn die Empfehlungen austauschbar werden, sinkt das Tool zur Ausführungsmaschine ab – schade, weil die Planungs-Schicht der teurere Hebel ist.

Warum Routing trotzdem Sinn ergibt

Fair bleiben: Multi-Model-Routing ist kein Fehler, sondern Stand der Technik. Wir haben selbst im Sakana Fugu-Artikel und in der Agent-Harness-Kategorie beschrieben, warum Orchestratoren strategisch unausweichlich sind. Kosten und Latenz lassen sich anders kaum kontrollieren, und für 80 % der Anfragen ist ein kleineres Modell schlicht ausreichend.

Das Problem ist nicht dass geroutet wird, sondern wie transparent es passiert und wie viel Kontext dabei verloren geht.

Was Builder konkret tun können

Bis die Plattform nachzieht, hilft hauptsächlich Disziplin:

1. Prompts explizit machen. Was früher impliziter Kontext war, gehört jetzt in den Prompt – referenzierte Datei, gewünschte Konvention, Abgrenzung zu Nachbarcode.
2. Reflexions-Satz anhängen. Ein Tipp aus der Reddit-Community, der bei uns reproduzierbar Qualität bringt: jede nicht-triviale Anfrage mit „Bitte überprüfe die Anfrage und den Code gründlich und gib bei Bedarf Vorschläge und stelle Fragen." abschließen. Zwingt das Modell in einen Review-Modus, bevor es Code schreibt – fängt einen Großteil der Halluzinationen und Fehlannahmen ab.
3. Threads kurz halten. Bei jedem Thema neu starten, statt eine Mega-Session über Stunden zu führen. Kontext-Drift wird so kleiner.
4. Wichtige Entscheidungen ins Repo schreiben. Memory-Files, READMEs, kurze Kommentare – alles, was den Kontext über den Chat hinaus persistiert, gewinnt an Wert.
5. Tools modellbewusst wählen. Für komplexe Refactors lohnt es sich, parallel mit Claude Code oder einem anderen Harness gegenzuprüfen – siehe unseren Vergleich der Agent Harnesses.

Was wir uns von Lovable wünschen

• Modell-Hinweis im Chat. Welches Modell hat geantwortet? Optional, klein, aber sichtbar.
• „Stick to model"-Toggle. Für Builder, die innerhalb eines Threads Konsistenz wollen, auch wenn es teurer ist.
• Bessere Kontext-Übergabe zwischen Routing-Hops. Damit ein Modellwechsel nicht jedes Mal als Memory-Reset wirkt.
• Wieder schärfere proaktive Empfehlungen. Lieber seltener, dafür wieder codebase-spezifisch.

Fazit

Multi-Model-Routing ist die richtige Architektur – aber die aktuelle Implementierung kostet Builder spürbar Output-Qualität. Verständnis, effektives Kontext-Window und AI-Empfehlungen waren vor wenigen Monaten besser. Solange das so bleibt, gehört „expliziter prompten" zur neuen Builder-Hygiene.

Quellen & weitere Erfahrungsberichte

• Blink Blog: Lovable's Creative Engine Update – Multi-Model Routing (Mai 2026) – ordnet das Multi-Model-Routing als Plattform-Shift ein.
• Facebook-Gruppe „Lovable AI": Anyone noticed lovable being 'dumber' lately? – Builder-Diskussion zur gefühlten Output-Verschlechterung.
• socialanimal.dev: Lovable App Limitations – 15+ Components Break – dokumentiert Kontext-Drift und Regressionen in längeren Sessions.
• Lovable Changelog, Opus 4.6, GPT-5.5 Early Access – Primärquellen zu den Modellen, die das Routing speist.
• Reddit r/lovable: Lovable is burning through credits and failing on simple tasks – Community-Thread mit dem oben empfohlenen Reflexions-Satz als Workaround.

Update-Watch

Wir beobachten das Thema aktiv und schreiben ein Follow-up, sobald sich Verständnis, Kontext-Window und Chat-Empfehlungen wieder auf dem alten Niveau anfühlen. Aus unserer Sicht ist das nur eine Frage der Zeit – Multi-Model-Routing ist die richtige Wette, die Tuning-Phase braucht nur ein paar Iterationen. Wenn du eigene Beobachtungen hast: gib uns Bescheid.