"AI-Optimierung ist 10-mal schneller, aber Handschrift kann tatsächlich 100-mal schneller sein!" Der Autor des beliebtesten Python-Tools: KI-generierte Spam-PRs zerstören die Open-Source-Community

Er hat die Hälfte des Python-Ökosystems mit Rust neu geschrieben – und fühlt sich im Zeitalter der KI-Agenten trotzdem erstickt.

Charlie Marsh, dessen Unternehmen kürzlich von OpenAI für mehrere hundert Millionen Dollar übernommen wurde, sprach kürzlich in einem Technik-Podcast über seine Ängste beim Programmieren.

Charlie ist Gründer von Astral, der Hochgeschwindigkeits-Python-Toolchain zu der Ruff und uv gehören. Heute ist sein Unternehmen Teil des KI-Agenten-Teams (Codex) von OpenAI. Als Top-Ingenieur, der eines der leistungsstärksten Open-Source-Tools entwickelt hat, gibt er offen zu: Er schreibt seit langer Zeit keinen Code mehr selbst im Editor, alles erledigt KI für ihn – er erstellt nur noch Prompts.

Aber das hat einen peinlichen Nebeneffekt: Ein Mitglied seines Teams sagte direkt zu ihm: Charlie, früher haben wir deine Pull Requests mit einem kurzen Blick durchgewunken und genehmigt. Heute müssen wir höchst aufmerksam prüfen – weil der Code von KI automatisch generiert wurde.

Dieses Streben nach Effizienz und besseren Tools durchzieht Charlies gesamte Gründungsgeschichte. Vor der Gründung von Astral war er nur ein einfacher Ingenieur in einem Biotechnologieunternehmen. Genug von der Langsamkeit der ursprünglichen Python-Tools, fasste er den Entschluss, Systemprogrammierung selbst zu lernen. Er gibt zu, dass er die Wahl von Rust fast nur wegen des Hypes getroffen hat – er wusste damals nicht einmal, was Speichersicherheit ist. Aber durch seine minimalistische Logik und seinen Fokus auf maximale Geschwindigkeit wurde sein schneller Analyzer auf Hacker News sofort ein großer Erfolg.

Dass das Unternehmen dieses Jahr von OpenAI übernommen wurde, liegt vor allem daran: Große Modelle bewegen sich immer mehr Richtung praktische Ingenieursarbeit und KI-Agenten, OpenAI braucht dringend die Erfahrung des Teams im Bereich Compiler und schneller Toolchains, um die Grundlagen für die Codegenerierung durch große Modelle zu schaffen.

In dem Gespräch mit Ryan Peterman von The Peterman Pod sprach Charlie über die echten Schwierigkeiten, vor denen Ingenieure im Zeitalter der KI-Agenten stehen: zum Beispiel das versteckte Risiko von unbekannten Abstürzen hinter der automatischen Umschreibung von Codebasen, und der Einfluss von Marketing auf das Überleben von Open-Source-Projekten. Seiner Meinung nach muss sich der Arbeitsschwerpunkt von Programmierern grundlegend ändern, wenn KI massenhaft Code produziert. Im Folgenden sind einige sehr echte Brancheneindrücke, die Charlie auf Basis seiner täglichen Entwicklungserfahrung geteilt hat:

KI senkt die Schwelle für Pull Requests auf null, aber der Prüfaufwand für Menschen bleibt gleich hoch. Früher war das Einreichen von Code durch Neulinge bei Open-Source-Projekten ein Wachstumsprozess: Feedback erhalten, Fehler korrigieren, nächstes Mal besser schreiben. Heute kann jeder mit KI in zwei Sekunden einen funktionierend aussehenden Pull Request erstellen. Der Betreuer muss eine Stunde lang manuell Fehler suchen, während der Einreicher nichts daraus lernt – das zerstört das gesunde Wachstumsvertrag der Open-Source-Community.

Die automatische Neugestaltung einer gesamten Codebase durch KI ist ein Spiel: man tauscht bekannte Fehler gegen unbekannte Abstürze. Auch wenn große Modelle eine riesige Codebase automatisch in eine andere Sprache umschreiben können (zum Beispiel der Wechsel von Bun von Zig zu Rust) und sogar alle Tests bestehen, können Tests immer nur die Korrektheit des Codes unter bestimmten Bedingungen beweisen. Automatische Umschreibungen ändern leicht „implizites Codeverhalten“, das nicht durch Tests abgedeckt ist (Hyrums Gesetz), und am Ende bekommen echte Nutzer die unbekannten Fehler ab.

Tausende großartige Open-Source-Projekte verrotten in der Ecke von GitHub, weil die Entwickler keine Ahnung von Marketing haben. Viele Programmierer denken arrogant: „Guter Code setzt sich von selbst durch.“ Aber in Wirklichkeit leben wir in einer Zeit extrem knapper Aufmerksamkeit: Du hast nur 10 Sekunden, um Leser auf deiner README-Seite zu begeistern. Gute Tools ohne gutes Entwicklermarketing bleiben zwangsläufig unentdeckt.

Warum ist die Python-Toolchain nicht so schnell wie die von JS?

Moderator: Wie sah der Bereich aus, als du angefangen hast, diese Entwicklertools zu bauen? Warum hast du gedacht, dass es viel besser gehen könnte?

Charlie Marsh: Vor der Gründung von Astral habe ich in einem rechenbiologischen Unternehmen gearbeitet und war dort der zweite Ingenieur. Ich habe keinen Hintergrund in Biologie oder Maschinellem Lernen, also war ich für den Aufbau der gesamten Softwareinfrastruktur für das ML verantwortlich. Damals war fast alles Python, also habe ich Python in diesem Prozess gelernt.

Später haben wir auch Go und Rust verwendet. Ich habe also viele verschiedene Ökosysteme kennengelernt. Damals hatten wir als kleines Team viele Projekte umzusetzen. Unsere Codebase ist zwar nicht mit den riesigen Codebasen großer Unternehmen vergleichbar, aber für unsere Verhältnisse war sie schon ziemlich groß – und es gab nur wenige Ingenieure, die die Software schreiben und das ganze Team unterstützen. Die anderen Teammitglieder waren meist ML-Forscher oder Wissenschaftler.

Also habe ich viele verschiedene Ökosysteme kennengelernt und viele Tools gesehen, damals arbeitete ich gerade mit Python. Wir haben immer versucht, so viel Hebelwirkung wie möglich aus den Tools herauszuholen – egal ob es sich um Typprüfer, Linter oder Paketmanager handelt. Mit wachsendem Projektumfang und kleinem Team wollten wir sehr gute statische Analyse und eine sehr gute Toolchain haben, aber wir sind immer wieder an Grenzen gestoßen.

Ich finde, damals wirkte das Python-Ökosystem für mich irgendwie anders als andere Ökosysteme, vor allem das Web-Ökosystem. Dort passierten viele ziemlich verrückte Dinge, und man legte mehr Wert auf Leistung. Zuerst kam ESBuild, geschrieben in Go; dann SWC mit Rust, dann Bun, Deno und eine ganze Reihe weiterer Tools. Also hat sich die Idee „JavaScript kann eine native Toolchain haben“ immer mehr durchgesetzt – vor allem weil Anwendungen immer größer werden und man immer mehr Aufgaben lokal auf dem Gerät erledigt.

Aber so etwas hat im Python-Bereich nie wirklich stattgefunden. Für mich war also die Kernfrage: Warum kann Python das nicht auch? Ich habe gesehen, was in der Web-Welt passiert ist, ich habe selbst Rust und Go geschrieben, ich weiß, wie diese Toolchains funktionieren und wie sie aus Nutzersicht funktionieren.

Und wenn ich dann auf Python zurückschaue, gab es viel weniger Tools, viele interessante Ideen aus anderen Ökosystemen fehlten hier komplett. Und fast alle Tools waren selbst in Python geschrieben. Also war das für mich eine sehr spannende Frage.

Das war praktisch die erste Frage, die ich mir am Anfang gestellt habe. Als Ruff zum ersten Mal veröffentlicht wurde, lautete der Titel meines Blogposts etwa „Python-Toolchain könnte viel viel schneller sein“. Für mich war das eher eine Hypothese: Kann die Python-Toolchain viel schneller werden? Ich habe einen Prototyp gebaut, und der Prototyp hat die Antwort gegeben: Ja, das geht auf jeden Fall.

Moderator: Du hast damals einen Artikel veröffentlicht, in dem du MyPy untersucht und Ergebnisse dazu veröffentlicht hast. Nur neun Tage später hast du dann den eben genannten Artikel veröffentlicht, in dem du sagtest, dass Python-Tools viel schneller sein können.

Charlie Marsh: Das ist ziemlich lustig, ich habe gar nicht gemerkt, dass die beiden Ereignisse so nah beieinander liegen.

Moderator: Wurde der Proof of Concept in diesen neun Tagen gebaut?

Charlie Marsh: Genau. Mein Blogbeitrag handelte damals von „Großskalige Typ-Prüfung“, ich wollte Dinge teilen, die ich gelernt habe und über die kaum jemand schreibt. Dann habe ich beschlossen, zuerst einen Linter zu bauen, weil ich dachte, das ist einfacher. Ich denke das auch heute noch: Es ist tatsächlich viel einfacher als einen Typprüfer zu bauen. Wir bauen jetzt auch einen Typprüfer, und haben schon einen fertig, also kann ich mit Sicherheit sagen: Einen Typprüfer zu bauen ist viel schwerer.

Aber ich habe zuerst mit dem Linter angefangen, weil ich damit viele gleiche Ideen in einer kleineren Form testen kann. Ob als Startup oder als Tool-Entwickler, du willst so schnell wie möglich ein produktiv nutzbares Produkt, das seinen Wert beweist, an die Nutzer bringen; gleichzeitig willst du auch schnelle Iterationen ermöglichen.

Seltsamerweise hat sich der Linter am Ende zu einer fast perfekten Produktform entwickelt. Der Kern ist einfach, aber es kann unzählige Regeln geben, richtig? Also ist es in vielen Dimensionen erweiterbar, und Nutzer bekommen schnell Wert durch einen kleinen Kern plus Regeln.

Also haben wir das Produkt schnell veröffentlicht, dann immer weiter iteriert, mehr Regeln und mehr Funktionen hinzugefügt. Nutzer können es auch zusammen mit anderen Tools verwenden. Es war fast sofort nützlich, das finde ich besonders wichtig. Im Gegensatz dazu ist ein Typprüfer ein gutes Gegenbeispiel: Ein Typprüfer, der nur zu 75 % fertig ist, ist praktisch nutzlos. Das gilt auch für Paketmanager.

Diese Dinge müssen meist – ich will das nicht absolut sagen, es gibt viele Ausnahmen – aber der Punkt ist, dass diese Produktarten schwieriger in einer „durchgehend nutzbaren“ Form iteriert und veröffentlicht werden können. Aber genau diese Fähigkeit ist meiner Meinung nach eine der wichtigsten Eigenschaften, um Momentum aufzubauen, egal ob du ein Tool oder etwas anderes baust.

Moderator: Welche Resonanz gab es, nachdem du den Artikel veröffentlicht hast?

Charlie Marsh: Der Blogbeitrag selbst kam auf die Startseite von Hacker News, wurde auf Twitter oft geteilt, es gab wirklich viel Begeisterung und Interesse.

Ich habe viele Gedanken zu so etwas – vor allem wenn es auf die Startseite von Hacker News kommt. Es ist teilweise Glück, teilweise Können. Es hilft natürlich, aber es ist auf keinen Fall eine notwendige Bedingung für Erfolg. Umgekehrt bedeutet ein Platz auf der Hacker-News-Startseite auch nicht, dass du automatisch Erfolg hast. Es ist natürlich toll, wenn es klappt, aber es gibt sehr viel Zufall dabei.

Aber ich finde ein paar Dinge sind wirklich wichtig. Erstens: Nachdem das passiert ist, fangen Leute an, das Projekt wirklich wahrzunehmen. Ich habe sehr hart gearbeitet, um diese Aufmerksamkeit zu nutzen, und war sehr aktiv dabei. Wenn jemand ein Issue erstellt, habe ich immer versucht, das Problem so schnell wie möglich zu bestätigen, zu beheben und eine neue Version zu veröffentlichen. Wenn du diesen Kreislauf innerhalb eines Tages abschließen kannst, ergibt das eine extrem starke Feedback-Schleife. Andere werden zu Unterstützern deines Projekts und bringen mehr Momentum.

Außerdem haben einflussreiche Personen aus dem Ökosystem das Projekt entdeckt, zum Beispiel Sebastian Ramirez – er hat FastAPI und viele andere Projekte gebaut. Er war von Anfang an ein großer Unterstützer unseres Projekts. Schon früh sagte er: „Oh, das klingt interessant, ich probiere es aus.“ Dann habe ich mich immer gefragt: Was muss ich tun, damit er es wirklich nutzt? Und ich habe alles dafür getan. Also haben wir das Momentum wirklich gut genutzt.

Aber ich denke auch oft an etwas anderes: Ich denke sehr oft über „Entwicklermarketing“ nach. Das Wort klingt irgendwie nach einem schmutzigen Wort, nicht besonders seriös. Viele Ingenieure wünschen sich, dass technische Produkte und Tools nur durch ihre eigene Stärke gewinnen. Als ob die beste technische Lösung sich automatisch durchsetzt und automatisch wächst.

Aber ich habe eine einfache Annahme: Es gibt wahrscheinlich tausende großartige Projekte auf GitHub, die nur nicht wissen, wie sie sich vermarkten sollen, also werden sie nie entdeckt und gehen nie an die Öffentlichkeit. Ich bin nicht sicher, ob das stimmt, aber ich habe dieses Gefühl bei vielen technischen Projekten.

Also wenn ich überlege, was ich in einen Blog oder eine README schreibe, denke ich nicht daran, hundert Emojis oder hundert Screenshots einzufügen. Das Wichtigste ist: Wenn jemand auf diese Seite kommt, habe ich nur etwa 10 Sekunden, um ihn für meine Arbeit zu begeistern und ihm zu erklären, warum das etwas mit ihm zu tun hat und warum es nützlich ist. Das ist praktisch der Kern meiner Überzeugung bei allem, was ich mache.

Klar, das ist irgendwie deprimierend, weil es bedeutet, dass ich nur 10 Sekunden habe – aber es ist eben so, Menschen haben nicht viel Aufmerksamkeit. Es ist die Aufmerksamkeitsökonomie, richtig? Das gilt auch für Blogs. Zufälligerweise habe ich früher bei Spring, als wir an biologischer ML gearbeitet haben, auch Inhalte veröffentlicht, um zu erklären, was wir machen. Wir hatten viele interessante Erkenntnisse, und wir haben die Blogbeiträge von OpenAI angesehen, vor allem die frühen Artikel zu DALL·E. Wir dachten damals: Wow, das sind wirklich tolle Blogbeiträge, denn auch wenn du keinen einzigen Absatz liest, verstehst du trotzdem was sie machen, und es beeindruckt dich trotzdem. Auch wenn jemand zufällig auf die Seite kommt, geht er mit einem Eindruck und einem Verständnis wieder weg. Das fand ich damals wirklich beeindruckend.

Also denke ich heute beim Schreiben von Blogs: Wenn jemand zufällig auf die Seite kommt, muss ich vorbereitet sein, denn die meisten Leute lesen nur die Zusammenfassung, oder das erste Bild, oder nur die Überschrift. Natürlich gibt es auch Leute, die den ganzen Artikel lesen. Also sollte ich jedes Wort und jeden Satz sorgfältig verfeinern, aber die meisten Leute lesen fast nichts.

Also nochmal, es tut mir leid, das klingt deprimierend. Aber ich finde es wirklich lohnenswert, sich Gedanken über dein Publikum zu machen und ehrlich zu erklären, warum sie sich für deine Arbeit interessieren sollten. Es ist keine Täuschung, es ist kein Betrug, aber du musst dir überlegen, wie du in kurzer Zeit vermittelst, warum dein Projekt wichtig ist.

Moderator: Kannst du ein Beispiel aus deiner Arbeit nennen?

Charlie Marsh: Für Ruff haben wir ein sehr gutes Benchmark-Diagramm in den Blog eingefügt, das sich dann auf Twitter verbreitet hat. Grundsätzlich ist dieses Diagramm unbezahlbar – ich meine nicht unbezahlbar im Geldsinn, sondern es ist unersetzlich wenn es darum geht, Aufmerksamkeit zu gewinnen. Denn jeder erkennt sofort, was hier passiert.

Ich finde Benchmark-Diagramme sind sehr stark. Natürlich ist jeder Benchmark in gewisser Weise unperfekt und hat Fehler, also gibt es dazu viel zu sagen. Aber ich finde es wirklich gut, wenn du einen visuellen Aufhänger hast, der schnell klar macht, warum man sich für das Projekt interessieren sollte, was es ist, kombiniert mit einem starken