Am 1. Juni 2026 wurde bestätigt: Microsoft und Google steigen mit eigenen KI-Coding-Modellen ein und greifen Anthropic und OpenAI direkt an. Das Modell, das euren Code am besten schreibt, ist damit kein fixer Punkt mehr — sondern ein Ziel, das sich verschiebt. Wer alles auf einen Anbieter setzt, verliert dieses Rennen automatisch.
Vier Anbieter, ein direkter Wettbewerb
Am 1. Juni 2026 bestätigten Berichte, dass Microsoft und Google eigene KI-Coding-Modelle auf den Markt bringen — um Anthropic und OpenAI anzugreifen, deren Claude Code und Codex den Bereich der KI-gestützten Softwareentwicklung bislang dominiert haben. Damit ist das Feld der Modelle, die Software-Entwicklungsagenten antreiben, voll besetzt: Anthropic, OpenAI, Microsoft und Google konkurrieren jetzt direkt.
Das ist mehr als eine weitere Produktankündigung. Es markiert den Moment, in dem das Schreiben von Code zur umkämpften Kernkategorie der vier grössten KI-Akteure der Welt wird. Coding ist kein Nebenschauplatz mehr, auf dem sich zwei Labore einen Vorsprung teilen. Es ist die Disziplin, in der alle vier ihre stärksten Modelle ins Rennen schicken.
Und das verändert die Dynamik grundlegend. Wenn zwei Anbieter konkurrieren, gibt es eine gewisse Stabilität: Man wählt einen, der andere schliesst langsam auf, man bleibt eine Weile gut bedient. Wenn vier Giganten mit tiefen Taschen und kurzen Release-Zyklen gegeneinander antreten, entsteht etwas anderes — ein permanentes Überholmanöver.
Klingt interessant?
Das beste Modell ist jetzt ein bewegliches Ziel
Die entscheidende Erkenntnis aus dem 1. Juni ist nicht, wer gerade führt. Es ist, dass die Führung nicht mehr stillsteht.
Bis vor Kurzem konnte ein CTO eine vertretbare Entscheidung treffen: "Wir bauen auf Claude Code" oder "wir setzen auf Codex". Diese Entscheidung hielt eine Weile, weil das Feld überschaubar war. Mit vier Anbietern, die sich alle paar Monate gegenseitig überholen, gilt das nicht mehr. Das Modell, das im ersten Quartal die besten Pull Requests produziert, kann im dritten Quartal auf Platz drei liegen — nicht weil es schlechter geworden ist, sondern weil drei Konkurrenten nachgelegt haben.
Wer sein gesamtes Entwicklungs-Setup auf das Coding-Modell eines einzigen Anbieters verdrahtet, hat damit nur zwei mögliche Zustände. Entweder ist man an ein Modell gebunden, das nicht mehr das beste ist — und akzeptiert stillschweigend schlechtere Ergebnisse als die Konkurrenz, die gewechselt hat. Oder man steht vor einer Migration: Prompts neu schreiben, Tooling anpassen, Eval-Suites neu kalibrieren, Workflows umbauen. Beides ist teuer. Das eine kostet Qualität, das andere kostet Zeit.
Der eigentliche Gewinner dieses Rennens ist deshalb nicht Microsoft, Google, OpenAI oder Anthropic. Es ist derjenige, der zu jedem Zeitpunkt das beste Modell für die jeweilige Aufgabe einsetzen kann — ohne sein Tooling neu bauen zu müssen.
Vier Modelle heisst auch: vier Stärken-Profile
Es geht nicht nur darum, welches Modell insgesamt "am besten" ist. Coding ist keine einzelne Aufgabe. Ein Modell kann hervorragend in der Generierung von Boilerplate sein, ein anderes im Refactoring grosser Legacy-Codebasen, ein drittes im Schreiben präziser Tests, ein viertes im Umgang mit langen Kontextfenstern über viele Dateien hinweg.
Mit vier ernsthaften Anbietern wird die Vorstellung eines einzigen "besten" Modells endgültig zur Illusion. Es gibt das beste Modell für diese Aufgabe, zu diesem Zeitpunkt, zu diesem Preis. Wer nur einen Anbieter nutzt, lässt diese Differenzierung ungenutzt — und zahlt sie, ohne es zu merken, in jeder einzelnen Entwicklungsaufgabe.
Was das für CTOs und Tech-Leads bedeutet
Drei Konsequenzen, die ich für relevant halte:
Erstens: Die Modellwahl ist keine einmalige Entscheidung mehr. Sie war es nie wirklich, aber bei zwei Anbietern liess sich diese Fiktion aufrechterhalten. Bei vier nicht. Wer heute einen Anbieter "auswählt", trifft de facto die Entscheidung, in sechs Monaten entweder zurückzuliegen oder zu migrieren. Beide Optionen sollten bewusst gewählt sein — nicht durch Trägheit entstehen.
Zweitens: Lock-in ist jetzt ein Performance-Problem, nicht nur ein Risiko-Problem. Früher war Single-Vendor-Bindung vor allem eine Frage der Ausfallsicherheit und der Preisverhandlung. Jetzt kommt eine direkte Wettbewerbsdimension dazu: Wer fixiert ist, arbeitet schlicht mit schlechterem Code als der Wettbewerber, der flexibel ist. Der Vorsprung der anderen ist keine Theorie — er ist die Differenz zwischen dem Modell von gestern und dem von heute.
Drittens: Die Kosten des Wechsels entscheiden alles. Wenn ein Modellwechsel ein Quartalsprojekt ist, wird man nie wechseln und immer hinterherhinken. Wenn er eine Konfigurationsänderung ist, kann man das beste verfügbare Modell jederzeit nutzen. Die Architektur, nicht das Modell, bestimmt, ob das Wettrüsten der vier Giganten euer Vorteil oder euer Risiko ist.
Und genau hier kommt nopex ins Spiel
Der 1. Juni bestätigt, was wir seit Längerem sagen: Sich an das Coding-Modell eines einzelnen Anbieters zu binden, ist keine Architekturentscheidung — es ist eine Wette darauf, dass dieser Anbieter dauerhaft führt. In einem Feld mit vier Giganten, die sich alle paar Monate überholen, ist das eine Wette, die man auf lange Sicht verliert.
nopex ist genau dafür gebaut. Wir kombinieren agentenbasierte Softwareentwicklung mit einer Infrastruktur, die Entwicklungsarbeit über verschiedene Coding-Modelle hinweg routet. Die Anwendungslogik kennt den konkreten Anbieter nicht — ihr nutzt für jede Aufgabe das jeweils beste Modell, ohne Prompts neu zu schreiben, Tooling umzubauen oder eine Migration zu fahren. Europäische Rechenzentren, offene Modelle wo möglich, proprietäre Frontier-Modelle wo sinnvoll — und der Wechsel zwischen ihnen ist eine Konfigurationssache, kein Projekt.
Genau das ist der Sinn: Das Wettrüsten der vier Giganten wird zu eurem Vorteil statt zu eurem Risiko. Während andere überlegen, ob sich eine Migration lohnt, reitet ihr einfach die jeweils beste Option. Das beste Coding-Modell wird sich weiter verschieben — die einzige offene Frage ist, ob ihr bei jeder Verschiebung gewinnt oder verliert.
