Wem gehört die Werkbank

Ein Satz von Hacker News bleibt mir seit gestern Abend im Kopf, seit ich die Nachricht von OpenAIs Astral-Übernahme las. Der Satz lautet: „OpenAI and Anthropic are making plays to own the means of production in software.“ Die Produktionsmittel. Eine dieser Wendungen, die beim ersten Lesen etwas übertrieben klingen, und dann denkst du nach, und nochmals, und am Ende merkst du, dass sie es vielleicht nicht genug sind.

Astral ist die Firma hinter uv, Ruff und ty — drei Werkzeugen, die in wenigen Jahren zur täglichen Infrastruktur von Millionen Python-Entwicklern wurden. uv hat das Problem der Umgebungs- und Dependency-Verwaltung mit einer Eleganz und Geschwindigkeit gelöst, die pip nie hatte. Ruff hat Linting und Formatting so schnell gemacht, dass sie unsichtbar wurden, und ty tut dasselbe für Type Checking. Werkzeuge in Rust geschrieben, alle Open Source, alle mit permissiver Lizenz. Und seit gestern alle im Besitz von OpenAI, das sie in das Codex-Team integriert — den Coding-Agenten, der bereits zwei Millionen wöchentlich aktive Nutzer überschritten hat.

Vor drei Monaten, im Dezember, hatte Anthropic einen ähnlichen Schritt gemacht und Bun gekauft, die JavaScript-Runtime von Jarred Sumner. Claude Code, ihr agentisches Coding-Tool, das in sechs Monaten eine Milliarde Dollar annualisierten Umsatz erreicht hat, läuft als Bun-Executable. Sumner sagte es in seinem Ankündigungspost mit fast brutaler Klarheit: „If Bun breaks, Claude Code breaks.“ Anthropic hat also die Infrastruktur gekauft, auf der sein Milliarden-Produkt steht.

Zwei Akquisitionen in drei Monaten von den beiden Firmen, die sich den Markt der KI-gestützten Coding-Tools teilen. Einzeln betrachtet hat jede ihre Logik. Zusammen ist das Muster eindeutig.

Das Muster: die Bauer von Sprachmodellen kaufen Stück für Stück die Toolchain, auf der diese Modelle operieren. Nicht Cloud, nicht Chips, nicht Rechenzentren. Die Werkzeuge zwischen Modell und Code. Den Package Manager. Den Linter. Die Runtime. Den Type Checker. Alles, was ein KI-Agent braucht, um nicht nur Code zu erzeugen, sondern ihn auszuführen, zu testen, zu validieren und in Produktion zu setzen.

Das ist keine Open-Source-Philanthropie. Es ist Infrastrukturstrategie.

Fünfundneunzig Prozent sind Kontext

Um zu verstehen, was passiert, hilft eine oft unterschätzte Tatsache: Sprachmodelle erzeugen für sich genommen Code. Aber Code zu erzeugen ist nicht Software zu entwickeln. Das weiß, wer einem Agenten ein ganzes Projekt schreiben ließ und sich mit etwas wiederfand, das kompiliert, aber nicht funktioniert, oder funktioniert, aber Repo-Konventionen verletzt, oder die Konventionen einhält, aber drei unvorhergesehene Tests bricht. Die Generierung sind 5 % der Arbeit. Die übrigen 95 % sind Kontext: Abhängigkeiten auflösen, Linter passieren, Typen handhaben, Tests laufen lassen, in den CI/CD-Flow integrieren, Code im Lauf der Zeit pflegen, wenn Bibliotheken sich aktualisieren und Anforderungen sich ändern.

Hier ist der Punkt. Ein KI-Agent, der diese 95 % machen will, muss die Werkzeuge besitzen — oder zumindest steuern —, aus denen sie bestehen. Es reicht nicht zu wissen, dass uv existiert. uv muss auf die Bedürfnisse des Agenten reagieren, für seine Workflows optimiert sein, sich in die Richtung entwickeln, die den Agenten effektiver macht. Dasselbe gilt für Ruff, ty, Bun. Wenn OpenAI in seiner Ankündigung schreibt, das Ziel sei „move beyond AI that simply generates code and toward systems that can participate in the entire development workflow“, ist das kein Marketing. Es ist exakt der Grund, warum Astral gekauft wurde.

Ich sehe es täglich in meiner Arbeit. Ich nutze Claude Code in Laravel-Projekten, manage CI/CD-Pipelines mit GitHub Actions, und der Unterschied zwischen einem Agenten, der eine Datei generiert, und einem, der den Kontext begreift, in dem die Datei leben soll, ist der Unterschied zwischen Werkzeug und Spielzeug. Wenn der Agent meine Linter-Regeln kennt, weiß, wie meine Abhängigkeiten strukturiert sind, meinen Deployment-Flow versteht, dann wird er wirklich Mitarbeiter. Und um diese Art Mitarbeiter zu sein, muss er die Sprache der Werkzeuge sprechen, die ich benutze. Wenn der Agentenbauer auch diese Werkzeuge besitzt, ist der Wettbewerbsvorteil enorm.

Ein Lock-in neuer Art

Aber genau hier wird es interessant — und etwas beunruhigend. Denn was hier entsteht, ist ein neuer Typus von Vendor-Lock-in, anders als alles bisher Gesehene.

Das alte Lock-in war explizit: du wähltest einen Cloud-Anbieter, eine proprietäre Datenbank, und irgendwann kostete Migration zu viel. Du wusstest es, du rechnetest, du entschiedst. Das neue Lock-in ist anders. Es ist implizit. Du merkst nicht, dass es geschieht, weil jedes einzelne Stück Open Source, frei, neutral wirkt. uv ist noch unter MIT. Bun ist noch unter MIT. Du kannst forken, du kannst sie ohne Codex oder Claude Code nutzen, du kannst alles tun. Aber die Frage ist eine andere: in zwei Jahren, wenn 80 % der uv-Entwicklung von Codex’ Anforderungen gelenkt wird, wenn die priorisierten Features für OpenAIs Agenten gebaut sind und nicht für dich, der uv im Terminal nutzt — wird der Fork dann noch eine praktikable Option sein? Simon Willison, einer der klarsten Köpfe im Ökosystem, schrieb gestern, das Worst-Case-Szenario habe die Form von „fork and move on“. Aber er fügte ehrlich hinzu, OpenAI habe noch keinen Track Record im Pflegen übernommener Open-Source-Projekte. Und eine Akquisition, die als Produkt + Talent beginnt, könne sich mit der Zeit in eine reine Talent-Akquisition verwandeln.

Das ist ein Punkt, zu dem ich immer wieder zurückkehre. Der Code bleibt offen, die Richtung wird geschlossen. Eine Form von Kontrolle, die keine Lizenz verletzt, kein explizites Versprechen bricht, und doch Macht stark konzentriert. Jemand auf Hacker News beschrieb die Dynamik treffend: „As they gobble up previously open software stacks, how viable is it that these stacks remain open?“ Die technische Praktikabilität bleibt, die praktische erodiert.

Ich schreibe es und höre die Einwände, die ich mir selbst gemacht habe. „Aber die Anreize sind ausgerichtet“, sagen viele. „Anthropic braucht, dass Bun für alle gut funktioniert, nicht nur für Claude Code, weil breite Adoption Netzwerkeffekte schafft.“ Stimmt, zumindest heute. „Die MIT-Lizenz schützt die Community“, sagen andere. Stimmt auch — zumindest in der Theorie. Aber ich habe in meiner Karriere genug Akquisitionen gesehen, um zu wissen, dass Versprechen vom Tag der Ankündigung ein nicht geschriebenes Verfallsdatum haben. Jarred Sumners Post war ehrlich: „No one can guarantee how motives, incentives, and decisions might change years down the line.“ Und ich würde hinzufügen: die Anreize einer Startup mit null Umsatz und vier Jahren Runway sind sehr verschieden von denen einer Sparte in einer Firma, die für jeden Umsatzdollar zwei Dollar fünfzig verbrennt und jede Akquisition vor Investoren rechtfertigen muss, die auf einen Börsengang warten.

Der Kampf um den Workflow

Es gibt einen weiteren Aspekt, der mich trifft: wie diese Akquisitionen den Wettbewerb neu definieren. Bis gestern lief der Kampf zwischen OpenAI und Anthropic über Modellqualität. Wer besser argumentiert, wer saubereren Code generiert, wer mehr Kontextlänge hat. Heute verlagert er sich auf eine andere Ebene: wer mehr Fläche des Entwickler-Workflows kontrolliert. Es geht nicht mehr nur um „mein Modell ist besser“. Es geht um „mein Modell lebt in einem Ökosystem, das mir gehört und jede Stufe optimiert“. Code-Generierung wird zur Commodity, der Wert wandert zur Orchestrierung des gesamten Zyklus. Wer Linter, Package Manager, Runtime und Coding-Agent besitzt, hat einen strukturellen Vorteil, den kein Benchmark abbildet.

Die Frage, die ich mir stelle und die noch keine klare Antwort hat, ist, was das für jene bedeutet, die mit anderen Stacks als Python und JavaScript arbeiten. Die Welt vieler Teams hat (noch) keine solche Konzentration erlebt — denken Sie an andere Ökosysteme. Aber das Muster ist klar und wird sich ausbreiten. Heute Python und JavaScript, weil das die Sprachen von KI und Web sind. Morgen jedes Ökosystem, in dem Coding-Agenten zuverlässige Werkzeuge brauchen, um autonom zu operieren. Der Wettlauf, die Bausteine der Entwicklungsinfrastruktur zu kaufen, hat eben begonnen.

Eine vielleicht etwas erzwungene Analogie hilft mir beim Denken. Jahrzehntelang war Erdöl der Treibstoff der Industriewirtschaft, und wer Raffinerien und Pipelines kontrollierte, hatte mehr Macht als die Förderer. In der Software sind Sprachmodelle das Rohöl. Sie liefern Output. Aber der echte Wert liegt in der Raffinerie: in den Werkzeugen, die diesen Output in funktionierende, getestete, konforme, deployte Software verwandeln. Die KI-Firmen haben das verstanden und kaufen die Raffinerien.

Eine politische Entscheidung

Und wir stehen mitten in diesem Übergang, ohne ihn gewählt zu haben. Wir nutzen uv, weil es das beste verfügbare Werkzeug ist. Wir nutzen Bun, weil es schnell ist und reale Probleme löst. Unsere Entscheidungen sind rational und individuell. Aber der aggregierte Effekt von Millionen rationaler, individueller Entscheidungen ist die Konzentration infrastruktureller Macht in den Händen weniger Firmen, die diese Werkzeuge nicht gebaut, sondern gekauft haben.

Ich weiß nicht, wohin das alles führt. Vielleicht bleiben die Anreize lange genug ausgerichtet, um keine Probleme zu erzeugen. Vielleicht erweist sich die MIT-Lizenz als ausreichender Schutz. Vielleicht bleibt der Markt wettbewerbsfähig genug, um Missbräuche zu verhindern. Vielleicht aber nicht. Vielleicht bauen wir eine Abhängigkeit, die wir erst dann als solche erkennen, wenn es zu spät ist, sie elegant zu verlassen.

Was ich weiß: die Wahl deines Package Managers, deiner Runtime, deines Linters war nie eine rein technische. Heute ist sie, ob du willst oder nicht, auch eine politische. Und wie alle politischen Entscheidungen verdient sie, mit offenen Augen getroffen zu werden.