Der Instinkt ist, dass mehr Modelle bessere Antworten bedeuten. Ein Tab mehr, eine Perspektive mehr, trianguliere dich zur Wahrheit. Es funktioniert bis etwa drei Modelle und dreht sich dann hart um. Danach kostet dich jedes Modell, das du hinzufügst, mehr in Abstimmung als es in Erkenntnis bringt, und das erste, das sich verschlechtert, ist nicht deine Geschwindigkeit. Es ist dein Urteil darüber, welche Antwort richtig war.
Wichtigste Erkenntnisse: Ein Modell zwingt zu klarem Denken. Zwei oder drei kaufen dir eine echte zweite Meinung. Danach orchestrierst du nicht mehr Modelle, du leitest ein Komitee, das sich nicht merken kann, worauf es sich vor zehn Minuten geeinigt hat.
Ich habe diese Kurve nach einem Monat gezogen, in dem ich sechs Modelle mehr oder weniger dauerhaft offen hatte, mich extrem produktiv fühlte und merklich schlechtere Arbeit lieferte.
Sechs offene Modelle kosteten mich einen Tag bei einer Redirect-Map
Im schlimmsten Fall hatte ich Opus 5 bei einem Architektur-Problem, Codex auf halbem Weg durch die Implementierung, Composer live im Editor, Grok zur zweiten Lektüre offen, und Qwen und Kimi in zwei weiteren Tabs geparkt, weil jemand auf X sagte, dass sie darin gut sind. Es fühlte sich wie ein Cockpit an. Es war ein Gruppen-Chat, bei dem niemand das Briefing gelesen hatte.
Die Kosten zeigten sich in einer Redirect-Map. Ich konsolidierte ein paar hundert alte URLs auf einer großen programmatischen Website – die Art von Job, bei dem 95 Prozent richtig ein Desaster sind, weil die 5 Prozent stillschweigend Revenue in eine Wand 301en. Ich fragte drei Modelle und bekam drei vertretbare Antworten zur Trailing-Slash-Kette. Statt mich für eine zu entscheiden und sie durchzudenken, verschmolz ich sie. Die Mischung war schlechter als jede der drei einzeln, weil jede in sich konsistent war und die Verschmelzung nicht. Ein Tag zum Auseinandernehmen, völlig selbstverschuldet.
Ein Modell zwingt dich zum klaren Denken
Die unterschätzte Eigenschaft eines einzelnen Modells ist, dass es die Spezifikation auf dich zurückverlagert. Mit genau einer Frage musst du ein echtes Briefing schreiben: die Eingabe, was die Ausgabe erfüllen muss, was außerhalb des Umfangs liegt, was „fertig" bedeutet. Dieser Schreibprozess ist das meiste Engineering. Ich habe mehr Design-Fehler beim Schreiben eines Prompts gefunden als in irgendeiner Code Review.
Mit sechs Modellen offen verdunstet diese Disziplin leise. Du hörst auf, Briefs zu schreiben, und fängst an, Umfragen durchzuführen, und eine vage Frage an sechs Modelle zurückgeworfen ergibt sechs selbstsichere Antworten. Selbstsicherheit ist kein Beweis, sondern nur das, wie diese Systeme klingen. Fast der ganze Wert meines Claude-Code-Workflows sitzt upstream vom Modell.
Zwei oder drei Modelle ist die tatsächliche Sweet Spot
Der Grund, warum drei funktionieren, ist, dass die Modelle unterschiedliche Jobs machen, statt den gleichen Job parallel. Arbeitsteilung ist additiv. Verdopplung ist nicht. Ein Modell hält den Plan, eines schreibt den Code, eines liest ihn dir kalt vor. Keiner stimmt ab.
In dem Moment, in dem zwei Modelle den gleichen Job machen, hast du keine Redundanz gekauft. Du hast einen Entscheidungsgleichstand gekauft, den nur du auflösen kannst, und du bist der am wenigsten ausgeruhte Teilnehmer im Gespräch.
Wenn ein Spezialisten-Modell sich seinen Tab tatsächlich verdient
Spezialisten lohnen sich, wenn sie strukturell unterschiedlich sind, nicht nur anders vermarktet. Mein Test ist einfach: widerspricht es den anderen auf eine Weise, von der ich lernen kann? Ein Modell, das allem zustimmt, ist ein sehr teurer Jasager.
Codex verdient sich seinen Tab bei der Implementierung, besonders bei langen mechanischen Änderungen über viele Dateien hinweg, wo ich ein Diff statt eines Gesprächs will. Composer 2.5 verdient ihn im Editor, wo der Wert Latenz ist, nicht Tiefe. Grok verdient ihn bei Produkt- und Positioning-Fragen, weil es mir gerne sagt, dass die Idee langweilig ist. Qwen und Kimi verdienen es, wenn ich eine andere Training-Verteilung will statt einer weiteren Abstimmung aus derselben Gegend. Ich habe Kimi in ein UI-Audit-Skript verdrahtet, genau weil es das sieht, worüber die anderen gelernt haben, höflich zu sein.
Diese letzte Unterscheidung ist das Wesentliche. Meistens, wenn Menschen ein fünftes Modell hinzufügen, suchen sie nicht nach einer weiteren Meinung, sondern nach einer weiteren Bestätigung. In dem Moment fühlen sich diese identisch an, und sie sind das Gegenteil.
Die versteckte Kosten ist Abgleich, nicht der Wechsel
Kontextwechsel ist die Kosten, die jeder nennt, und sie ist real: Du liest dieselbe Datei zum vierten Mal durch, weil Du nicht mehr weißt, welchem Tab Du die Einschränkung mitgeteilt hast. Aber es ist nicht die teure.
Die teure ist, dass Du selbst zum Merge-Konflikt wirst. Zwei Modelle geben Dir einen Dissens zur Entscheidung. Drei geben Dir drei. Sechs geben Dir fünfzehn paarweise Disagreements, und jeder einzelne möchte eine Entscheidung von demselben erschöpften Menschen. Nichts in Deinem Stack macht diesen Abgleich für Dich. Du bist die Integrationsschicht, die am Ende des Tages läuft, bei einem Problem, von dem Du nun sechs leicht unterschiedliche Formulierungen gelesen hast.
Und die Modelle können Dir hier nicht helfen, denn keines von ihnen weiß, was die anderen gesagt haben. Du bist der Einzige, der den vollständigen Kontext hält, was genau die Position ist, aus der Du dich herausdelegieren wolltest.
AI-Orchestration ist normalerweise ein menschliches Problem
Wenn Menschen sagen, dass sie bessere Orchestration brauchen, meinen sie meist, dass sie einen klareren Auftrag brauchen. Wenn drei Modelle Dir drei wirklich unterschiedliche Antworten geben, ist das selten eine Kapazitätslücke. Es ist fast immer Mehrdeutigkeit in der Frage, und keine noch so gute Routing-Logik behebt ein unterbestimmtes Problem. Sie verteilt es nur.
Die Diagnose, die ich jetzt nutze: Wenn ich nicht in zwei Sätzen aufschreiben kann, was eine richtige Antwort erfüllen müsste, ist das Öffnen eines weiteren Modells Prokrastination mit einer Fortschrittsleiste. Schreib zuerst die zwei Sätze. Manchmal sind die zwei Sätze schon die Antwort und ich schließe alle Tabs.
Der Workflow, den ich heute wirklich laufe
Opus 5 zum Denken. Architektur, Tradeoffs, die unbequeme Frage, ob das Ding überhaupt gebaut werden sollte. Hier investiere ich Prompt-Aufwand, denn eine schlechte Entscheidung hier ist nicht durch besseren Code später zu beheben.
Codex zur Implementierung. Sobald die Form feststeht, übergib ihm die Spezifikation und lass ihn arbeiten. Ich überprüfe das Diff, nicht die Begründung.
Composer 2.5 zur Codierungsunterstützung. Im Editor, schnell, kleiner Umfang. Es ist ein besseres Autocomplete, kein Kollege, und wer es als Kollegen behandelt, bekommt 400 Zeilen, die man nicht verlangt hat.
Grok für alternative Perspektiven. Bewusst nicht auf dem kritischen Pfad. Ich gehe dort hin, wenn ich den Verdacht habe, dass ich mich selbst in etwas hineingeredet habe.
Qwen oder Kimi, wenn ich eine andere Meinung statt einer weiteren Bestätigung will. Selten. Mit Absicht.
Das Wichtigste ist nicht die Liste. Es ist, dass diese fast nie gleichzeitig offen sind. Eine Sequenz, kein Cockpit: Denken, dann Implementierung, dann Review, ein Modell hält an jedem Stadium den Stift. Das Diagramm erreicht drei, weil drei die Anzahl der wirklich aktiven Stadien an einem guten Tag ist. Ich habe zwei davon verglichen: Claude Code vs Cursor.
Bessere Prompts schlagen mehr Reiter
Ein gut spezifiziertes Problem, das einem guten Modell übergeben wird, schlägt ein vages Problem, das sechs Modellen übergeben wird, und zwar deutlich. Mehr Modelle fühlen sich besser an, weil einen Tab zu öffnen sofort geht und ein Brief zu schreiben ist Arbeit. AI-FOMO ist der Glaube, dass das nächste Modell das Denken übernimmt, das man vermieden hat. Es wird nicht. Es wird zum falschen Problem artikulierter sein.
Disziplin ist unglamourös und verzinst sich. Die Menschen, die ich kenne und die die beste Arbeit mit diesen Tools abliefern, verwenden nicht die meisten Modelle. Sie verwenden zwei oder drei, mit Absicht, mit klarer Arbeitsteilung und schriftlicher Spezifikation, und ihnen ist die Diskussion ums Modell der Woche langweilig.
Eine Sache, die heute zu tun ist
Schließe jeden AI-Reiter außer einem. Nimm die Aufgabe, an der du gerade arbeitest, und schreib zwei Sätze: Was der Input ist und was ein korrekter Output erfüllen müsste. Gib diese zwei Sätze dem einen Modell, das du offen gelassen hast. Wenn die Antwort gut ist, war dein Engpass nie die Modellkapazität. Wenn sie schlecht ist, weißt du jetzt, welcher der zwei Sätze falsch war – eine Sache, die sechs Modelle dir nicht hätten sagen können.
FAQ
Wie viele KI-Modelle sollte ich gleichzeitig nutzen?
Zwei oder drei, die unterschiedliche Aufgaben erfüllen: eines zum Durchdenken des Problems, eines zur Umsetzung und optional eines zur Überprüfung oder als Gegenstimme. Über drei hinaus wächst der Aufwand, widersprüchliche Antworten abzustimmen, schneller als der Nutzen der zusätzlichen Perspektive, denn du bist der einzige Teilnehmer, der weiß, was alle von ihnen gesagt haben.
Ist es schlecht, mehrere KI-Modelle für dieselbe Aufgabe zu nutzen?
Zwei Modelle auf die identische Aufgabe anzuwenden ist normalerweise Verschwendung. Es bringt keine Redundanz, es bringt einen Tie-Break, den nur du entscheiden kannst. Mehrere Modelle helfen, wenn sie unterschiedliche Rollen haben, etwa Planung versus Umsetzung, und schaden, wenn sie sich duplizieren.
Was sind die echten Kosten beim Wechsel zwischen KI-Modellen?
Die offensichtlichen Kosten sind die Wiederherstellung des Kontexts und das erneute Lesen derselben Dateien. Der größere Kostenblock ist die Abstimmung: Bei sechs Modellen hast du fünfzehn paarweise Meinungsverschiedenheiten zu klären, und nichts in deinem Stack macht das für dich. Du wirst zur Integrations-Schicht.
Helfen spezialisierte Modelle wie Codex, Grok, Qwen oder Kimi wirklich?
Ja, wenn sie strukturell unterschiedlich sind statt nur anders vermarktet, und wenn sie eine definierte Aufgabe haben. Der Test ist, ob das Modell in einer Weise mit den anderen nicht übereinstimmt, von der du lernen kannst. Wenn es meistens übereinstimmt, zahlst du für Bestätigung, nicht für Einsicht.
Dazu passend: mein Claude Code Workflow für die Single-Model-Disziplin, die dies nahelegt, und die Einstellung eines Claude Code Entwicklers, wenn dir das lieber jemand anders abnehmen würde.