Google, OpenAI und Anthropic überbieten sich derzeit fast im Wochentakt. Neue Modellversion, neue Benchmarkzahl, neue Pressemitteilung. Und ich sitze bei jedem dieser Releases da und frage mich dasselbe: Was hätte Steve Jobs dazu gesagt? Meine These ist unbequem, gerade weil sie gegen den aktuellen Branchenreflex läuft: Er hätte das Wettrüsten verweigert und stattdessen konsequent weniger gemacht, nicht mehr. Nach der Lektüre etlicher Jobs-Biografien und Jahren in der KI-Beratung für EPU und KMU in der DACH-Region weiß ich, was das für deine Modellwahl konkret bedeutet, nämlich fast immer das Gegenteil von dem, was gerade jede Pressemitteilung suggeriert. Schauen wir uns an, warum.
Meine eigene Nähe zu Apple ist dabei kein Zufall, sondern reicht bis zum Macintosh SE/30 zurück, meinem ersten eigenen Apple-Rechner. Bis heute stehen bei mir im Büro iMacs, dazu kommen MacBook Air, iPhone Pro Max, Apple Watch und iPad im täglichen Einsatz. Diese Verbundenheit ist der Grund, warum mich die Frage, wie Jobs auf die aktuelle KI-Schlacht reagiert hätte, nicht als akademisches Gedankenspiel interessiert, sondern als reale Messlatte für meine eigene Beratungsarbeit.
Bevor ich einsteige, kurz zwei Begriffe, die ich im Text brauche. Ein Frontier-Modell ist die jeweils leistungsstärkste Modellgeneration eines Anbieters, also aktuell etwa Claude Opus, ChatGPT Atlas oder Gemini 3. Klumpenrisiko meint in diesem Zusammenhang die Abhängigkeit eines Geschäftsprozesses von genau einem Anbieter oder einem einzigen Modell, ohne Ausweichmöglichkeit.
Warum die Wochentakt-Schlacht bei deinen Kunden ankommt, nicht bei dir
Ich beobachte das regelmäßig in meiner Beratungsarbeit: Für mich als Berater ist die permanente Modellflut Alltag, ich teste ja laufend. Für den Handwerksbetrieb, mit dem ich letzte Woche über seine Textautomatisierung gesprochen habe, ist sie schlicht Lärm. Er will wissen, ob sein Prozess funktioniert, nicht ob Modell X in einem neuen Reasoning-Benchmark drei Prozentpunkte vor Modell Y liegt.
Genau hier setzt meine These an: Die aktuelle Modellschlacht ist ein Innovationstheater für Fachpublikum, aber sie löst für den Enduser kein einziges Problem, das er tatsächlich hat. Sie schafft neue. Jede neue Modellgeneration bringt neue Namen, neue Preisstufen, neue Limitierungen, und der Kunde muss das alles wieder neu einordnen, obwohl sein Geschäftsprozess sich seit Monaten nicht verändert hat.
Jobs hätte diese Dynamik vermutlich sofort als das erkannt, was sie ist: ein Symptom von Führungslosigkeit im Produktmanagement, nicht ein Zeichen von Innovationskraft. Sein Grundsatz war nie „mehr Features schneller ausliefern“, sondern das genaue Gegenteil. Ich habe an anderer Stelle bereits beschrieben, warum das Ende der Hype-Zyklen längst begonnen hat, und genau dieses Muster wiederholt sich hier: Geschwindigkeit wird mit Fortschritt verwechselt, dabei sind das zwei völlig verschiedene Dinge.
Die Vier-Quadranten-Lektion: Was Jobs 1997 tatsächlich getan hat
Als Jobs 1997 zu Apple zurückkam, war das Unternehmen fast pleite und produzierte über siebzig verschiedene Produkte und Produktvarianten, ein wilder Wildwuchs aus Macintosh-Modellen, die sich kaum voneinander unterschieden. Jobs stellte sich vor ein Whiteboard, zeichnete eine simple Zwei-mal-zwei-Matrix, Consumer und Pro auf der einen Achse, Desktop und Portable auf der anderen, und strich alles, was nicht in eines der vier Felder passte. Über siebzig Prozent des bestehenden Portfolios waren damit weg, selbst Projekte, die laut Jobs selbst „ziemlich gut“ waren.
Das ist keine Anekdote, das ist dokumentiert, unter anderem in einer ausführlichen Rekonstruktion der Führungsprinzipien von Jobs an der Arizona State University, in der Jobs selbst den Satz sagt, der für mich den Kern der ganzen Geschichte trifft: „Deciding what not to do is as important as deciding what to do.“ Übertrage das auf die heutige Modellwahl bei OpenAI, Google oder Anthropic, wo jeder Anbieter parallel fünf bis zehn Varianten anbietet, mini, pro, flash, thinking, non-thinking, und du siehst sofort, wie weit sich die Branche von diesem Prinzip entfernt hat. Kein Anbieter traut sich aktuell, siebzig Prozent seines eigenen Portfolios zu streichen, weil jede Variante irgendeine Nutzergruppe oder ein Preissegment bedient. Wirtschaftlich nachvollziehbar. Für den Enduser trotzdem eine Zumutung.
Was mich an dieser Episode bis heute fasziniert: Jobs traf diese Entscheidung, ohne vorher eine Marktforschung abzuwarten oder Fokusgruppen zu befragen. Er verließ sich auf sein eigenes Urteil darüber, was ein kohärentes Produkt ausmacht, und stand dazu auch gegen internen Widerstand von Teams, die jahrelang an den gestrichenen Projekten gearbeitet hatten. Diese Bereitschaft, unbequeme Entscheidungen ohne Absicherung durch Zahlen zu treffen, fehlt mir persönlich am meisten, wenn ich mir aktuelle Produktentscheidungen bei den großen KI-Laboren ansehe.
Warum das Interface selbst schon zu kompliziert ist
Ein Punkt, der in der ganzen Debatte um Modellqualität fast untergeht: Jobs hätte sich vermutlich nicht nur an der Update-Frequenz gestört, sondern schon am Interface selbst. Ein leeres Textfeld, in das man erst lernen muss, was man hineinschreibt, wäre für ihn ein Zeichen von unfertigem Design gewesen, nicht von Flexibilität. „Prompt Engineering“ als eigenes Fachgebiet gäbe es in seiner Logik gar nicht, weil ein gutes Produkt seinem Nutzer die Bedienungsanleitung erspart, statt sie ihm als Kompetenz abzuverlangen.
Dazu kommt die Modellvielfalt selbst: Bei jedem der drei großen Anbieter gibt es aktuell mehrere Varianten parallel, mit unterschiedlichen Preisen, Kontextfenstern und Fähigkeiten, die sich für Laien kaum unterscheiden lassen. Ich habe genau diese Verwirrung in meinem großen LLM-Vergleich für 2026 im Detail durchgearbeitet, und die Rückmeldung meiner Kunden ist fast immer dieselbe: Sie wollen nicht verstehen, warum es fünf Varianten gibt, sie wollen wissen, welche einzige davon für sie passt. Genau diese Entscheidung abzunehmen, statt sie an den Kunden weiterzureichen, wäre für Jobs die eigentliche Designaufgabe gewesen, nicht die Modellarchitektur dahinter.
Warum „das neueste Modell“ der falsche Reflex ist
Und jetzt kommt der Teil, der viele meiner Kunden überrascht, wenn ich ihn zum ersten Mal anspreche: Immer das neueste Modell einzusetzen ist nicht vorausschauend, es ist tatsächlich das genaue Gegenteil von dem, was Jobs getan hätte. Sein Perfektionismus bedeutete oft jahrelanges Warten, bis eine Technologie tatsächlich reif für die Masse war, nicht das hektische Nachrüsten jeder neuen Version.
Ein Beispiel, das ich in der Beratung inzwischen fast wöchentlich bringe: Am 12. Juni 2026 hat die US-Regierung Anthropic angewiesen, den Zugang zu den frisch veröffentlichten Modellen Fable 5 und Mythos 5 auszusetzen. Wer seinen Workflow drei Tage vorher auf genau diese Modelle aufgebaut hatte, stand am 12. Juni um 17:21 Uhr Eastern Time plötzlich still. Ich habe den Fall damals ausführlich analysiert, und die Lehre daraus ist für mich eindeutig: Das Risiko liegt nicht im Modell selbst, sondern im Klumpenrisiko, das entsteht, wenn du deinen gesamten Prozess an die jeweils neueste, noch nicht ausreichend erprobte Version bindest.
Ich bin mir da nicht ganz sicher, ob dieser Vergleich hundertprozentig trägt, aber er trifft für mich den Kern trotzdem gut: Jobs hätte niemals ein Produkt an Kunden ausgeliefert, das intern noch nicht bis zur letzten Konsequenz durchdacht war, egal wie sehr die Konkurrenz gerade drängte. Genau das passiert aktuell bei den Frontier-Laboren, wenn sie im Wochentakt neue Versionen herausbringen, die teils Tage später schon wieder zurückgezogen oder eingeschränkt werden. „Never change a running system“ ist in diesem Licht keine Bequemlichkeit, sondern gelebte Jobs-Philosophie: Stabilität schlägt Neuheit, solange die Neuheit keinen konkreten, geprüften Mehrwert für den tatsächlichen Anwendungsfall bringt.
Was das für deine KI-Strategie als EPU oder KMU bedeutet
Was heißt das jetzt praktisch, wenn du kein Frontier-Labor bist, sondern ein Einpersonenunternehmen oder ein kleiner Betrieb in Salzburg, Wels oder sonst wo in Österreich? Drei Dinge, die ich in jeder Beratung wiederhole, hab ich mittlerweile fast schon automatisiert im Kopf.
Erstens: Die Frage ist nie „welches ist gerade das beste Modell“, sondern „welches Modell erfüllt meinen konkreten Anwendungsfall zuverlässig“. Ich beschreibe diesen Ansatz ausführlicher in meinem Artikel zur maßgeschneiderten KI-Beratung, und die Kernaussage bleibt: Ein Werkzeug allein löst kein strukturelles Problem, wenn der Prozess dahinter nicht passt.
Zweitens: Wechsle nicht, nur weil ein neues Modell existiert, sondern nur, wenn du geprüft hast, dass es deinen Use Case tatsächlich besser abdeckt als die laufende Lösung. Das setzt voraus, dass du überhaupt einen Überblick hast, welches Tool bei welchem Prozess im Einsatz ist, eine simple Liste reicht dafür oft schon.
Drittens: Baue dort, wo es wirklich zeitkritisch oder sicherheitsrelevant ist, bewusst eine Abstraktionsschicht ein, die einen Anbieterwechsel in kurzer Zeit ermöglicht. Das schaut auf den ersten Blick nach Mehraufwand aus, ist aber genau die Art von Vorsorge, die Jobs‘ Prinzip „Nein sagen zu fast allem“ im Kern gemeint hat. Nicht Innovationsverweigerung, sondern Disziplin bei der Auswahl dessen, worauf du dich wirklich verlässt.
Viertens, und das unterschätzen die meisten meiner Kunden am Anfang völlig: Lege einen fixen Rhythmus fest, in dem du bestehende Lösungen gegen den aktuellen Stand der Technik prüfst, statt nur zu reagieren, wenn ein Problem auftaucht. Ein Quartal reicht in den meisten Fällen völlig. Das ist kein Widerspruch zu „never change a running system“, im Gegenteil: Es macht aus einer Bauchentscheidung eine geprüfte, und genau darin liegt für mich der eigentliche Unterschied zwischen Beratung und bloßem Tool-Verkauf.
Am Ende bleibt für mich diese Frage stehen, die ich mir bei jedem neuen Modell-Release selbst stelle: Löst das gerade ein echtes Problem, oder bediene ich nur meine eigene Neugier auf das Neue? Bei mir persönlich, zugegeben, ist das oft Letzteres, ich teste einfach gerne. Bei einem Kundenprozess ist die Antwort so gut wie immer die erste Frage, und genau da würde Jobs ansetzen. Du kannst jedem neuen Release hinterherlaufen. Oder du fragst zuerst, was dein Prozess wirklich braucht, und entscheidest danach.
