MoltBot-Schöpfer: „Ich veröffentliche Code, den ich nicht gelesen habe“
(newsletter.pragmaticengineer.com)- Ein Interview über den Workflow von Peter Steinberger, der mit AI-Agenten allein im Januar mehr als 6.600 Commits verzeichnete
- Moltbot (früher Clawdbot) verzeichnet derzeit das schnellste Star-Wachstum in der Geschichte von GitHub und überholt beim Google-Suchvolumen Claude Code und Codex
- Peter entwickelt, indem er gleichzeitig 5–10 Agenten betreibt und sich statt auf Code-Reviews auf Architekturdiskussionen konzentriert
- Um effektiv mit AI zusammenzuarbeiten, ist es entscheidend, eine Schleife zu entwerfen, in der Agenten selbst kompilieren, linten, testen und validieren können
- Ingenieure, die eher ergebnis- und systemdesignorientiert denken als auf Implementierungsdetails fixiert sind, passen sich besser an AI-native Entwicklung an
Wer ist Peter Steinberger?
- Gründer, der PSPDFKit zu einem globalen Entwickler-Tool-Business ausgebaut hat
- Er ist nach einer dreijährigen Pause zurückgekehrt und stellt diesmal LLMs und AI-Agenten ins Zentrum seines Workflows
- Die Erfahrung, ein Entwicklerteam mit mehr als 70 Personen geführt zu haben, lehrte ihn, Perfektionismus loszulassen – eine Fähigkeit, die heute seine Effizienz bei der Arbeit mit AI-Agenten steigert
- Im Januar 2026 verzeichnete er in nur einem Monat mehr als 6.600 Commits und zeigte damit als Einzelentwickler eine außergewöhnliche Produktivität
- Die gesamte Arbeit geschah an persönlichen Projekten, nicht in einem Unternehmen, und er genießt das Entwickeln selbst
Moltbot und das explosive Wachstum
- Auf GitHub wurde die schnellste Star-Wachstumsrate aller Zeiten verzeichnet; selbst im Vergleich zu Tailwind CSS ist die Wachstumskurve beispiellos
- In der vergangenen Woche lag das Google-Suchvolumen über dem kombinierten Suchvolumen von Claude Code und Codex
- Peters Formulierung: "Anhand der Commits könnte es wie ein Unternehmen wirken, aber in Wirklichkeit bin ich nur eine Person, die zu Hause zum Spaß programmiert"
Zehn zentrale Lehren aus einem AI-Agenten-basierten Workflow
- Perfektionismus aufgeben: Wer akzeptiert, dass Code nicht immer dem eigenen Geschmack entspricht, kann mit Agenten deutlich effizienter arbeiten
- Die Schleife schließen: Das System muss so entworfen sein, dass AI-Agenten selbst kompilieren, linten, ausführen und validieren können
- Pull Requests sind tot, „Prompt Requests“ sind im Kommen: Wichtiger als der Code selbst ist es, den Prompt zu sehen, der den Code erzeugt hat
- Code-Reviews verschwinden und werden durch Architekturdiskussionen ersetzt: Selbst auf Discord diskutiert das Kernteam nicht über Code, sondern nur über Architektur und große Entscheidungen
- 5–10 Agenten gleichzeitig betreiben und so einen „Flow-Zustand“ aufrechterhalten
- Jeder Agent arbeitet parallel an einer anderen Funktion
- Erheblich Zeit in die Planung investieren, mit einer Präferenz für Codex
- Durch wiederholte Gespräche mit dem Agenten wird ein robuster Plan entwickelt
- Den Plan hinterfragen, anpassen und widerlegen; wenn man zufrieden ist, wird ausgeführt und zum Nächsten übergegangen
- Codex kann lange Aufgaben eigenständig bearbeiten, während Claude Code häufig zur Klärung zurückkommt und dadurch ablenkt
- Bewusst weniger konkrete Prompts verwenden, um auch unerwartete Lösungen zu entdecken
- Lokales CI ist besser als Remote-CI: Statt 10 Minuten auf Remote-CI zu warten, führen die Agenten Tests lokal aus
- Der meiste Code ist langweilige Datentransformation: Darauf muss man sich nicht versteifen; die Energie sollte in Systemdesign fließen
- Ingenieure, die sich mehr für Ergebnisse als für Implementierungsdetails interessieren, arbeiten gut mit AI zusammen
- Ingenieure, die gern Algorithmus-Rätsel lösen, tun sich schwerer mit dem Wechsel zu „AI-native“
- Wer gern Produkte ausliefert, passt sich besser an
Sicht auf die Zukunft des Software Engineerings
- AI hat Software Engineering nicht getötet – eher das Gegenteil
- Peter ist ein Softwarearchitekt, der die High-Level-Struktur eines Projekts im Kopf behält
- Er achtet stark auf Architektur, technischen Schuldenstand, Skalierbarkeit und Modularität
- Einer der Gründe für den Erfolg von Moltbot ist seine hervorragende Skalierbarkeit
- Es wurde Energie investiert, damit sich neue Funktionen leicht hinzufügen lassen
- Als „wohlwollender Diktator“ des Projekts wahrt er Konsistenz in Richtung und Stil
Kontext und Grenzen
- Moltbot ist ein experimentelles Projekt mit schneller Iteration als Grundannahme und noch in Arbeit
- „Schnell handeln und Dinge kaputt machen“ ist für solche Projekte die einzige Erfolgsstrategie
- Das lässt sich nicht ohne Weiteres auf jedes Team oder jedes Produkt übertragen
- Trotzdem gilt es als Beispiel dafür, eine Nachfrage entdeckt zu haben, die selbst große AI-Labore nicht erwartet hatten
26 Kommentare
Ich verstehe nicht, warum man eine Vorhersagemaschine ständig mit einer Maschine verwechselt, die denken kann.
Da ein Taschenrechner auf deterministischen Algorithmen basiert, halte ich diese Analogie für unpassend.
Und ich bin nicht gegen den Einsatz von KI an sich, sondern halte die in diesem Artikel vorgestellte Art, KI zu nutzen, für problematisch.
Weil es in der Struktur gebaut wurde, die wir uns vorgestellt haben.
Grundlegend wurde die Art und Weise übernommen, wie Gehirnzellen miteinander verbunden sind, und man kann nicht klar erkennen, über welchen Prozess gedacht wird.
Da wir auch nicht wissen, durch welchen Prozess „Gedanken“ im Gehirn entstehen, sind die Grundform und die Phänomene identisch.
Deshalb wird das menschliche Gehirn als dasselbe wie eine Vorhersagemaschine betrachtet.
Es gibt offenbar auch Bereiche, die davon ausgehen, dass das, was wir Denken nennen, ein mechanisches Phänomen ist und dass deshalb auch Brain Hacking möglich sei.
Beides sind Blackboxes, und die Grundstruktur ist zwar gleich, aber deshalb sollte man nicht vorschnell behaupten, dass sie ähnlich sind.
Es ist nicht vollständig identisch, aber zugleich auch nicht völlig verschieden.
Wenn es ähnlich ist, bedeutet das, dass es gemeinsame Teile gibt,
am Ende hängt es also wohl vom Blickwinkel darauf ab, wie ähnlich es ist, dass Menschen unterschiedlicher Meinung sind.
Man kann es nicht als identisch ansehen, aber ich halte es für ähnlich,
und ich denke, dass das aus der Perspektive von geek12356s Kommentar über Vorhersage und Denken so ist.
Gleichzeitig vertrete ich auch die Sichtweise, dass es sich vom Menschen unterscheidet, weil seine Intelligenz höher ist als die des Menschen.
Lasst uns nicht zu den Seniors werden, die allein mit dem Taschenrechner Zeile für Zeile rechnen, während andere mit einer Excel-Funktion in einer Sekunde Hunderte Zeilen berechnen, und dann sagen: „Benutzt keine Funktionen.“
Der Vergleich mit Excel-Funktionen und einem Taschenrechner scheint mir falsch zu sein.
Wenn ein LLM eine Genauigkeit von 100 % hätte, würde ich das akzeptieren..
Ich verstehe nicht, warum man dagegen ist, keinen Taschenrechner zu benutzen, und dann trotzdem am Abakus herumrechnet.
Also ehrlich: Ein Produkt, das auf diese Weise entwickelt wurde, würde ich nicht nutzen wollen.
Ein derart entwickeltes Fahrzeug oder eine Flugsoftware würde ich erst recht nicht verwenden.
Deshalb nutzen die Menschen in Japan größtenteils immer noch Faxgeräte.
Oberflächlich sieht es zwar beeindruckend aus, aber wenn später Probleme auftreten und man sie beheben muss oder Sicherheitslücken entstehen, dürften die Kosten enorm sein..
Es scheint, als seien bereits mehrere Sicherheitslücken gemeldet worden.
Letztlich werden Menschen wieder wichtiger.
Ich weiß nicht, ob man das positiv oder negativ sehen sollte..
Wahrscheinlich benutzen Sie es bereits bewusst oder unbewusst.
Wenn mit so dahingeschludertem Code Probleme entstehen, wer soll dann bitte am Ende den Schlamassel aufräumen ... Wenn Code auf diese Weise entwickelt wird, wird eines Tages ganz sicher eine solche Hölle kommen.
"Prompt Request" statt Pull Request – das ist schon erstaunlich.
Ich hatte mich vor sehr langer Zeit einmal sehr für MDA interessiert, es dann aber als unrealistisch aufgegeben; und nun wird das auf diese Weise tatsächlich umgesetzt.
Es wäre schön, wenn das auf Plattformen wie GitHub als Funktion angeboten würde.
„Schnell handeln und Dinge kaputtmachen“
Der Satz ist nachvollziehbar
Es ist größtenteils mein Fehler, dass ich versucht habe, von KI geschriebenen Code zu lesen.
Die MoltBots ballern wohl massenhaft Self-Healing-PRs raus, und ich glaube nicht, dass der Ersteller die alle selbst reviewen kann, lol. Dass es ungefähr gleich viele Issues und PRs gibt, liegt wohl daran, dass es ein Problem ist, das man statt ein Issue zu schreiben und zu warten einfach beendet, indem man den MoltBot bittet, einen PR zu erstellen und zu pushen, lol.
Es wirkt nur so, als wäre das, was KI bei der Unterscheidung von Hunden und Katzen gemacht hat, uns ein kleines Stück nähergerückt … ich weiß nicht, ob das darüber hinaus noch einen größeren Wert hat.
Er scheint Codex zu bevorzugen; ich bin neugierig auf seine Konfiguration.
Mit Codex habe ich in 140 Tagen 115 Projekte gemacht und dabei offenbar mehr als 250 Milliarden Tokens verbraucht – link
Das sind ungefähr 75 Millionen Won. Ein einzelner AI-native Entwickler muss wohl erst einmal einen Exit hinlegen und etwas mehr Geld haben ...
2.500 Milliarden Token – ich kann mir die Größenordnung gar nicht vorstellen...