# Gut genug: das Modell ist selten der Engpass URL: https://www.mikebild.dev/de/blog/gut-genug-modelle/ *Teil 2 der Serie „Von der Session zum System“ – hier geht es [zum Auftakt](https://www.mikebild.dev/de/blog/von-der-session-zum-system-auftakt/).* Ende November, ein Architektur-Review mit einem Team, das ich begleite, zweiter Tag, erste Kaffeepause. Ein Entwickler kommt mit der Tasse in der Hand zu mir und stellt die Frage, die seit zwei Jahren in jedem Teamgespräch und jedem Flurgespräch auf Konferenzen fällt: „Welches Modell nehmt ihr denn?“ Diesmal mit besonderem Nachdruck, denn der November 2025 war verrückt: GPT-5.1 am 12., Grok 4.1 am 17., Gemini 3 am 18., Claude Opus 4.5 am 24. Vier Flaggschiff-Ankündigungen in zwölf Tagen, dazu die üblichen Benchmark-Screenshots, die durch die Timelines wandern. Sein Team, erzählt er, diskutiert seit Wochen, ob man wechseln müsse. Ich habe diese Frage früher ernsthaft beantwortet, mit Modellnamen und Begründung. Jede dieser Antworten war nach sechs Wochen veraltet. Inzwischen antworte ich anders: „Das ist die zweite Frage. Lass uns über die erste reden.“ ## Die Konvergenz, über die niemand gern spricht Nüchtern und ohne Anbieter-Loyalität betrachtet: Für die Aufgaben, die achtzig Prozent meiner Arbeit mit KI ausmachen, sind die großen Modelle 2025 konvergiert. Code lesen und erklären, ein Refactoring vorschlagen, Tests entwerfen, ein Konzeptpapier gegenlesen, eine API-Dokumentation zusammenfassen, einen Migrationspfad skizzieren – das können GPT-5, Claude Sonnet 4.5 und Gemini in einer Qualität, die ich für nicht möglich gehalten hätte, bevor ich es selbst ausprobiert habe. Und zwar alle. Natürlich sind sie nicht identisch. Jedes Modell hat einen eigenen Ton, eigene Vorlieben, eigene Schwächen. In Coding-Benchmarks liegen zwischen den Spitzenmodellen ein paar Prozentpunkte, und die Reihenfolge ändert sich mit jedem Release. Aber genau das ist der Punkt: Ein paar Prozentpunkte, die alle paar Wochen neu gemischt werden, sind keine Grundlage für eine Architekturentscheidung. Sie sind Rauschen an der Spitze einer Kurve, die für den Alltag längst flach geworden ist. Das erzähle ich in solchen Runden ungern als Erster, weil es die Diskussion abkühlt, auf die sich alle gefreut haben. Der Modellvergleich ist unterhaltsam, er fühlt sich nach Ingenieursarbeit an, und er hat den Charme, dass man dabei nichts an der eigenen Arbeitsweise ändern muss. Aber er beantwortet die falsche Frage. ## Das Rauschen im Alltag ist größer als der Unterschied zwischen Modellen Wenn bei mir eine Session mit Claude oder ChatGPT schiefgeht, dann liegt das fast nie am Modell. Es liegt daran, dass ich die Aufgabe unklar gestellt habe. Dass das Modell den Kontext nicht kannte, der für die Lösung entscheidend war – die Architekturentscheidung von vor zwei Jahren, die ungeschriebene Konvention im Team, den Grund, warum dieser eine Service anders aufgebaut ist als alle anderen. Oder daran, dass ich das Ergebnis nicht geprüft habe und der Fehler erst im Review auffiel. Ein Beispiel aus einem Teamgespräch in einem großen Konzern, anonymisiert wie immer: Zwei Kollegen, dasselbe Modell, dieselbe Aufgabe – ein Stück Legacy-Code verstehen und einen Umbau vorschlagen. Der eine bekam einen brauchbaren, konkreten Plan. Der andere bekam generischen Lehrbuch-Text. Der Unterschied war nicht das Modell, nicht einmal der Prompt im engeren Sinne. Der eine hatte dem Modell die relevanten Dateien, die Testfälle und die Randbedingungen mitgegeben. Der andere hatte eine Frage in ein leeres Fenster getippt. Die Varianz innerhalb eines Modells – je nachdem, was ich ihm mitgebe und wie ich prüfe – ist um ein Vielfaches größer als die Varianz zwischen den Spitzenmodellen. Solange das so ist, verschwinden Benchmark-Unterschiede im Alltagsrauschen aus unklaren Aufgaben, fehlendem Kontext und fehlender Prüfung. Wer seine Ergebnisse verbessern will, findet den Hebel dort, nicht im Modellwechsel. ## Wer auf das beste Modell wettet, wettet auf eine Commodity Damit zur These, die ich für die wichtigste dieses Beitrags halte: Wer seine Arbeitsweise oder gar sein Produkt auf „das beste Modell“ baut, wettet auf eine Commodity, die er nicht besitzt. Die Modelle gehören einer Handvoll Anbieter. Ich miete Zugriff über einen API-Schlüssel oder ein Abo, genau wie mein Wettbewerber, genau wie jedes andere Team. Ich kann nicht steuern, wann eine Version abgekündigt wird, wann sich das Verhalten nach einem Update leise verschiebt, wann der Preis fällt oder das nächste Modell die Rangliste umwirft. Der November hat das vorgeführt: Wer im Oktober seine Wahl auf einen Benchmark-Vorsprung gestützt hat, sah diesen Vorsprung innerhalb von zwei Wochen dreimal den Besitzer wechseln. Was ich dagegen besitzen kann, ist die Schicht um das Modell herum. Das ist keine Plattform und kein Produkt, sondern schlicht alles, was ich selbst in der Hand habe, bevor und nachdem das Modell rechnet: - der Zuschnitt der Aufgaben, also die Fähigkeit, Arbeit so zu zerlegen, dass ein Stück davon delegierbar wird - der Kontext, den eine Session am Anfang bekommt, statt dass das Modell meine Realität erraten muss - das Wissen des Teams in abrufbarer Form, von Konventionen bis zu den Gründen hinter alten Entscheidungen - der Prozess, der regelt, wann die KI arbeitet, wann ein Mensch prüft und was in den Main-Branch darf - die Prüfung selbst, also verlässliche Wege festzustellen, ob ein Ergebnis stimmt, bevor es etwas bewirkt Diese Schicht ist das Gegenteil einer Commodity. Sie ist spezifisch für mein Team, meine Codebasis, meine Domäne. Niemand kann sie mir durch ein Release wegnehmen, und der Wettbewerber kann sie nicht einfach mitmieten. Vor allem aber: Sie überlebt Modellwechsel. Eine Stunde, die ich in bessere Aufgabenbeschreibungen, in eine gepflegte CLAUDE.md oder AGENTS.md, in Review-Kriterien investiere, zahlt sich auch mit dem übernächsten Modell noch aus. Eine Stunde Benchmark-Studium ist beim nächsten Release entwertet. Es gibt einen angenehmen Nebeneffekt, den ich aus der Architektur-Arbeit kenne: Wer die Schicht besitzt, für den sinken die Wechselkosten. Wenn Aufgabenzuschnitt, Kontext und Prüfung sauber stehen, ist das Modell dahinter austauschbar wie eine Abhängigkeit hinter einer klaren Schnittstelle. Dann kann ich sogar gelassen wechseln, wenn es einen echten Grund gibt – weil mein eigentliches Kapital nicht am Modellnamen hängt. ## Wo die Modellwahl doch zählt Ehrlichkeit gehört dazu, sonst wird aus der These ein Dogma. Es gibt Situationen, in denen die Modellwahl eine echte, messbare Rolle spielt. Drei begegnen mir regelmäßig. Erstens die Spezialfälle. Wer mit exotischen Sprachen oder Nischen-Frameworks arbeitet, stark multimodale Aufgaben hat oder aus Datenschutzgründen on-premises bleiben muss, landet schnell bei kleineren offenen Modellen – und dort sind die Qualitätsunterschiede real und die Abwägungen andere. „Gut genug“ gilt für die großen Frontier-Modelle bei Alltagsaufgaben, nicht für jede Modellklasse bei jeder Aufgabe. Zweitens Kosten und Latenz. Sobald Modelle nicht mehr interaktiv, sondern in Volumen laufen – Klassifikation in einer Pipeline, Autovervollständigung im Editor, Verarbeitung tausender Dokumente –, werden Preis pro Token und Antwortzeit zu harten Kriterien. Da liegen zwischen den Modellen Faktoren, nicht Prozentpunkte, und es lohnt sich zu messen. Drittens lange, agentische Aufgaben. Hier trennen sich die Modelle Ende 2025 tatsächlich noch spürbar: wie lange sie an einer mehrstufigen Aufgabe fokussiert bleiben, wie zuverlässig sie Werkzeuge bedienen, wie sie mit eigenen Fehlern umgehen. Nicht zufällig wurden Claude Sonnet 4.5 im September und Opus 4.5 im November genau über diese Fähigkeit beworben. Wer ganze Arbeitspakete delegiert statt einzelner Fragen, darf bei der Modellwahl wählerisch sein. Aber – und das ist mir wichtiger als die drei Ausnahmen selbst – all das ist die zweite Frage. Sie lässt sich erst dann seriös beantworten, wenn die erste beantwortet ist. Ohne klaren Aufgabenzuschnitt und ohne verlässliche Prüfung kann ich Modelle nämlich gar nicht vergleichen; ich vergleiche dann nur Bauchgefühle an unterschiedlichen Tagen. Erst wenn die Schicht steht, wird die Modellwahl zu dem, was sie sein sollte: eine Optimierung mit Messwerten, ungefähr so aufregend wie die Wahl eines Datenbank-Index. Und wie dort gilt: gelegentlich neu bewerten, Versionen bewusst festhalten, Verhaltensänderungen nach Updates ernst nehmen. „Gut genug“ heißt weder „alle gleich“ noch „für immer“ – es heißt nur: nicht der Engpass. ## Die erste Frage Zurück in die Kaffeepause. Bleibt bei dem Modell, das ihr habt, habe ich ihm gesagt, und steckt die Diskussionsenergie eures Teams in die Fragen davor und danach. Woran erkennt ihr, dass ein Ergebnis stimmt? Was müsste eine Session über euer System wissen, um nicht zu raten? Welche eurer Aufgaben sind überhaupt so geschnitten, dass man sie abgeben kann? Wer diese drei Fragen gut beantwortet, holt aus jedem der aktuellen Modelle mehr heraus als der Nachbar mit dem Benchmark-Sieger und leerem Kontextfenster. Er war sichtlich unzufrieden – die Antwort ist weniger glamourös als ein Modellvergleich, und sie macht Arbeit. Aber sie hat eine Konsequenz, die mich seither beschäftigt und die den Rest dieser Serie trägt: Wenn das Modell selten der Engpass ist, dann macht irgendetwas anderes den Unterschied zwischen der Session, die liefert, und der, die Zeit verbrennt. Bei mir läuft es jedes Mal auf die Umgebung hinaus, in der das Modell arbeitet – wie viel sie ihm zeigt, was sie ihm erlaubt und wogegen sie seine Ergebnisse hält. Genau dort geht es in der nächsten Folge weiter. ## Weiterführende Quellen - [Anthropic: Introducing Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5) - [Google: Gemini 3 – das bislang leistungsfähigste Modell von Google](https://blog.google/products/gemini/gemini-3/) - [Simon Willison: Claude Sonnet 4.5 is probably the best coding model in the world (at least for now)](https://simonwillison.net/2025/Sep/29/claude-sonnet-4-5/) - [Anthropic Engineering: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)