Stop Waiting, Start Shipping — der offene KI-Stack ist 2026 die erwachsene Wahl

Bei der PyCon DE & PyData 2026 hatte ich Gelegenheit, einen Fireside Chat mit Sebastian Raschka zu führen — Autor von Build a Large Language Model (From Scratch), ehemals Statistik-Professor, heute eine der wenigen Stimmen, die zwischen LLM-Architektur und Anwender-Realität ohne Vereinfachung übersetzt. Was sich im Gespräch herauskristallisiert hat, sind keine Modell-Benchmarks, sondern drei strategische Linien, die für Entscheider relevanter sind als die nächste Release-Welle.

Es gibt kein "Winner takes it all" — und das ist eine Architekturfrage

In den Medien läuft die LLM-Story als Pferderennen: OpenAI gegen Anthropic gegen Google gegen die chinesischen Player. Wer setzt sich durch? Die Frage ist falsch gestellt.

Raschka beschreibt es nüchtern: Modelle werden zunehmend für ihre Harness post-trainiert — also für die spezifische Umgebung, in der sie laufen. Cursor — das US-Coding-Startup, zuletzt mit rund 30 Milliarden Dollar bewertet — setzt im eigenen Agent das Modell Composer ein, im Kern ein post-trainiertes Kimi K 2.5, ein chinesisches Open-Source-Basismodell. Claude Code, Codex und jeder ernsthafte Coding-Agent läuft in einer eigens kontrollierten Harness, in der das Modell speziell für die Tool-Schnittstelle nachtrainiert wurde.

"There's no general model that is gonna do well in all the harnesses." — Sebastian Raschka

Daraus folgt eine Verschiebung in der Build-vs-Buy-Logik. Die Frage "Welches Modell?" ist in den meisten Fällen der falsche Einstieg. Die richtige Frage lautet: Was ist die Harness, die wir bauen — und welches Modell passt in genau diese Umgebung? Wer Modellauswahl ohne Harness-Architektur denkt, zäumt das Pferd von hinten auf.

Europas Allokationsfrage: nicht das nächste Basismodell

Die in Deutschland populärste AI-Strategie-Debatte — "Wir brauchen ein eigenes europäisches Basismodell" — ist aus zwei Gründen problematisch.

Erstens existieren bereits leistungsfähige Open-Weight-Basismodelle: DeepSeek v3 und Qwen 3 (beide aus China), Llama (Meta, USA). Mistral Large 3 — das prominenteste europäische Modell — ist im Kern eine post-trainierte DeepSeek-v3-Architektur. Zweitens entsteht der eigentliche Wettbewerbsvorteil eine Stufe höher: in Post-Training, Tool-Integration, Domänen-Daten und Harness-Design.

Wenn ein CIO mit Budget und Zwölf-Monats-Druck mich fragt, wo der nächste Euro hingehört, ist meine Antwort klar: nicht ins Pre-Training. Sondern in die Schichten, in denen domänenspezifischer, regulatorisch tragfähiger Wert entsteht — und die Datenschutz, On-Premises-Betrieb und Audit-Anforderungen tatsächlich erfüllen können. Genau hier liegt der einzige Hebel, der technologische Souveränität und Compliance gleichzeitig liefert.

Diese Investitionslogik funktioniert nur auf offenen Gewichten — Post-Training auf einer geschlossenen API ist keine echte Option. Open Source ist damit keine Präferenz, sondern Voraussetzung. Einer der am stärksten unterschätzten Gründe, warum selbst die Anbieter so handeln, ist Talent: Auf die Frage, warum Google Gemma oder OpenAI GPT-OSS veröffentlicht, antwortete Sebastian nicht mit Marketing oder Großzügigkeit, sondern mit Hiring:

"If you hire people who never worked on an LLM because there's no LLM you can work on if it's all proprietary, well, you have to train them from scratch." — Sebastian Raschka

Wenn schon die Anbieter selbst offene Gewichte als strukturelle Voraussetzung für ihre eigene Talent-Pipeline behandeln, fließt diese Logik nach unten weiter: Unternehmen, die auf solchen Gewichten aufbauen — und Menschen einstellen, die mit ihnen gearbeitet haben — hängen an genau dieser Voraussetzung.

Agents an der kurzen Leine

Die zweite Welle der Coding-Agents ist im Mainstream angekommen. Raschka erwähnt einen Bekannten, dessen Startup-Codebasis im Wesentlichen mit Claude Code entstanden ist — eine Arbeit, die vorher zwei Jahre und ein dreißigköpfiges Team gekostet hätte. Das ist die optimistische Lesart.

Die andere: In großen Codebasen — Raschka und ich sprachen über das Beispiel der New Yorker Finanzhäuser — wächst die Codemenge plötzlich um den Faktor zehn. 25.000 Zeilen werden zu 250.000. Auf einmal fehlen Senior-Reviewer, die das Ganze in einer regulierten Industrie absegnen können. Der Bottleneck wandert vom Schreiben zum Reviewen.

Erfahrene Ingenieure und Data Scientists werden in dieser Welt nicht weniger wichtig, sondern wertvoller.

Meine Handlungsempfehlung ist deshalb unverändert: Agents sind großartig, aber man muss sie an der kurzen Leine halten. Konkret heißt das: nicht die End-to-End-Automatisierung als Ziel setzen, sondern die existierende Arbeit verbessern. Raschka bringt es auf den Punkt:

"Making your work better rather than replacing it." — Sebastian Raschka

Die Anwendungsfälle, die in regulierten Kontexten skalieren, folgen genau diesem Muster: bestehende Tests durch Agent-Vorschläge anreichern, statt Tests komplett generieren lassen. Code-Reviews um ein zweites Augenpaar erweitern, statt sie zu automatisieren. Dokumentation durchsuchbar machen, statt Reports vollautomatisch produzieren zu lassen.

Die Ersatzdebatte ist die falsche Debatte

In der öffentlichen Wahrnehmung dominiert die Ersatz-Frage: Welche Jobs verschwinden? Welche Aufgaben übernimmt die KI? Sebastians Perspektive aus der Forschung dreht das Argument um. Was Doktoranden früher tagelang erledigt haben — Hyperparameter-Tuning, Batch-Skripte aufsetzen, Logs parsen, Ergebnisse plotten — diese mühsame Arbeit, in der ML-Community augenzwinkernd graduate student descent genannt (eine Anspielung auf gradient descent), lässt sich heute weitgehend automatisieren.

"The students now actually get to do science instead of doing busy work." — Sebastian Raschka

Das ist nicht Ersatz, sondern Freisetzung. Die kreative Kapazität der Doktoranden — Hypothesen formulieren, Experimente konzipieren, Ergebnisse interpretieren — wird durch die Automatisierung des Mühsamen erst freigespielt. Dasselbe Muster greift in der Industrie: Wer ein Team mit KI-Agents ausstattet, ersetzt nicht Köpfe, sondern entlastet sie von dem Anteil, der ohnehin keine menschliche Urteilskraft verlangt. Der Wertbeitrag verschiebt sich nach oben, nicht weg.

Konsequenzen für die Praxis

Drei Handlungsempfehlungen, die ich aus dem Gespräch mitnehme und in laufenden Mandaten ohnehin schärfe:

Erstens: Harness vor Modell

Verschieben Sie die Modellauswahl-Diskussion ans Ende der Architekturfrage, nicht an den Anfang. Klären Sie zuerst die Harness — Tool-Schnittstellen, Daten-Anbindung, Sicherheitsgrenzen, Audit-Trail. Welches Modell darin läuft, ist die letzte, nicht die erste Entscheidung.

Zweitens: Investitionen in Post-Training, nicht in Pre-Training

Eigene Basismodelle wären für 99 Prozent der europäischen Unternehmen verschwendetes Kapital. Investitionen in Post-Training-Kompetenz, MLOps, Daten-Pipelines und Harness-Engineering sind dagegen der Hebel, an dem sich Domänen-Wert tatsächlich aufbaut. Wer Souveränität ernst meint, baut nicht das nächste GPT — sondern die Schichten, in denen Domänen-Wert verteidigt wird.

Drittens: Experimentieren statt warten

Raschkas finaler Rat ist auch meiner — lieber drei kleine Experimente diese Woche als ein großer Plan im nächsten Quartal.

"If you plan something very thoroughly it is probably irrelevant tomorrow." — Sebastian Raschka

Warten ist keine Option. Unstrukturiertes Tun aber auch nicht. Der Unterschied liegt in der Disziplin, mit der Experimente eingerahmt werden — kleine Modelle, sandboxierte Umgebungen, klar abgegrenzte Use Cases — und im Reflex, das Gelernte sofort in die nächste Architekturentscheidung zu gießen.