Pi Coding Agent: Flexible KI-Tools für echte Workflows entwickeln

Einleitung

Code ist niemals kostenlos. Das ist das zentrale Argument von Mario Zechner, dem Schöpfer von Pi, wenn er über den Stand der KI-gestützten Entwicklung im Jahr 2026 spricht. Während Agenten schnell riesige Mengen an Code generieren können, holen einen die Konsequenzen dieses Codes irgendwann ein. Pi existiert, weil Zechner feststellte, dass bestehende Coding-Agenten nicht zu seinen Workflows passten – anstatt sich anzupassen, baute er ein Tool, das sich stattdessen an ihn anpasst.

Dieses Gespräch behandelt, warum Workflow-Stabilität wichtiger ist als Feature-Geschwindigkeit, wie man tatsächlich mit Coding-Agenten arbeitet, ohne auszubrennen, und warum die Branche mit der spezifikationsgetriebenen Entwicklung möglicherweise einen 30 Jahre alten Fehler wiederholt.

Warum Pi existiert: Workflow-Flexibilität vor Stabilität

Als Claude Code erstmals veröffentlicht wurde, war Zechner zufrieden damit. Mit der Zeit wurde jedoch die hochfrequente Release-Kadenz des Tools zum Problem. Claude Code erhält ein bis drei Updates pro Tag, und mit jedem Release kommen Änderungen an Tool-Definitionen, System-Prompts und dem zugrunde liegenden Verhalten. Für jemanden, der eigene Prompt-Templates, Slash-Befehle und Workflow-Beschreibungen erstellt, führen diese unsichtbaren Änderungen zu Fehlern.

Das Modell selbst schien sich von Tag zu Tag anders zu verhalten, obwohl die Modellversion gleich blieb. Zechner führt dies teilweise auf Änderungen am “Harness” zurück – der Infrastruktur und den System-Prompts, die bestimmen, wie ein Modell reagiert. Die Auswirkungen von Harness-Änderungen auf die Ausgabequalität zu testen ist schwierig, da es keine deterministische Methode gibt, diese zu messen. Das Ergebnis ist, dass sich Entwickler wie Zechner nicht darauf verlassen können, dass das Tool konsistent arbeitet, was den Zweck, eigene Workflows darum aufzubauen, zunichtemacht.

Pi entstand aus dieser Frustration heraus. Es ist ein minimaler, erweiterbarer Coding-Agent, der sich selbst modifizieren kann, um in Ihre Workflows zu passen, anstatt Sie zu zwingen, sich an seine Einschränkungen anzupassen. Die zugrunde liegende Architektur abstrahiert LLM-Anbieter, enthält eine Terminal-Benutzeroberflächen-Bibliothek und bietet allgemeine Agenten-Loop-Abstraktionen. Der entscheidende Unterschied ist jedoch die Kontrolle: Zechner bestimmt das Design und kann es ändern, ohne auf den Release-Zyklus eines Anbieters warten zu müssen.

Wie Pi tatsächlich funktioniert: Parallelverarbeitung und manuelle Überprüfung

Zechners täglicher Workflow mit Pi ist methodisch und bewusst technikarm. Er lässt keine Armee von Agenten parallel laufen. Stattdessen nutzt er einen “Steinzeit-Ansatz”: Er reiht mehrere Sitzungen ein, von denen jede ein anderes Issue aus dem Tracker analysiert, und überprüft und iteriert dann jede einzelne.

Bei Bugfixes und Feature-Implementierungen beginnt der Prozess mit einer Issue-Beschreibung. Zechner füttert das Issue an einen Agenten mit einem benutzerdefinierten Prompt-Template, das besagt: Ziehe alle relevanten Informationen, ignoriere die Analyse im Issue und führe deine eigene Analyse basierend auf dem durch, was wir erreichen wollen. Dieser Analyseschritt dauert etwa fünf Minuten pro Issue. Er öffnet eine zweite Sitzung für das nächste Issue, eine dritte für ein weiteres und schafft so eine parallele Vorverarbeitungspipeline.

Sobald der Agent die Analyse eines Issues abgeschlossen hat, überprüft Zechner die Vorschläge, prüft den Code selbst und reproduziert Probleme bei Bedarf manuell. Er nutzt den Agenten als “Rubber Duck” – einen Denkpartner –, bis er sich selbst über den Implementierungsansatz einig ist. Wenn er dem Agenten sagt, er solle implementieren, enthält der Kontext so viele Leitplanken, dass der Agent genau weiß, welche Schnittstellen zu modifizieren, welche Module anzupassen und wie Tests zu funktionieren haben.

Die Implementierung dauert weitere 10 bis 30 Minuten. Wenn der Agent den Abschluss signalisiert, öffnet Zechner einen Diff-Viewer und kommentiert einzelne Zeilen mit Feedback. Er klickt auf Fertig, das Feedback fließt automatisch zurück in den Agenten, und die Iteration geht weiter, bis der Code gut ist. Bei Kernmechaniken überprüft er jede Änderung, wie er es bei einem Menschen tun würde. Bei anderen Teilen genehmigt er ohne tiefe Inspektion.

Dieser Workflow funktioniert, weil Zechner über mehr als 10 Jahre Erfahrung in Codebasen verfügt. Er weiß, was funktioniert und was nicht. Für neue Entwickler oder solche ohne diese Erfahrung wäre der Ansatz anders – und riskanter.

Die Realität der spezifikationsgetriebenen Entwicklung

Die Branche wiederholt einen 30 Jahre alten Fehler. Wasserfall-Entwicklung erwies sich bereits vor Jahrzehnten als ineffektiv, doch mit KI-Agenten sind wir zurück beim Hyper-Wasserfall: detaillierte Spezifikationen schreiben und Agenten diese implementieren lassen. Der einzige Unterschied ist, dass man die Spezifikation jetzt nicht einmal mehr selbst schreibt – man gibt einem Agenten per Vibe-Prompt den Auftrag, eine sehr detaillierte Spezifikation zu schreiben, die dann ein anderer Agent implementiert.

Das Problem ist fundamental. Eine vollständige Spezifikation ist im Grunde das Programm selbst. Wenn man eine Spezifikation in natürlicher Sprache verfasst, lässt man Lücken. Der Agent füllt diese Lücken mit Mustern, die er aus 20 Jahren Code im Internet gelernt hat – von denen vieles Müll ist. Das Ergebnis ist eine Codebasis, die wie Vibe-Coding-Software aussieht, weil sie es ist.

Es gibt ein Gegenargument: Code ist jetzt billig und die Iteration ist schnell. Früher konnte die Implementierung einer Wasserfall-Spezifikation Monate dauern. Jetzt dauert es vielleicht einen Tag. Man kann sich manuell durchtesten. Aber Zechner hat noch keine Beweise dafür gesehen, dass dies für Produktionssoftware tatsächlich funktioniert. Er vermutet, dass Entwickler irgendwann nachts aufwachen und feststellen, dass alles kaputt ist.

Dennoch gibt es Rahmenbedingungen, unter denen agentengestützte Entwicklung sinnvoll ist. Der Rewrite von Bun von Zig auf Rust funktionierte, weil das Projekt eine umfangreiche Testsuite hatte. Der Agent konnte seine Arbeit bis zu einem gewissen Grad selbst verifizieren. In solchen Fällen sind Tools wie dieses wirklich nützlich. Aber für die meisten Softwareprojekte ist der Ansatz riskant.

Open Source im großen Maßstab verwalten: Das Clanker-Problem

Vor den Agenten erhielt ein erfolgreiches Open-Source-Projekt vielleicht ein oder zwei Pull Requests pro Woche. Pi erhält jetzt 50 bis 60 Pull Requests pro Tag – alle von Agenten (Zechner nennt sie “Clanker”). Jeder PR hat eine Beschreibung wie ein ganzes Harry-Potter-Buch und umfasst 10 bis 1.000 Dateiänderungen.

Die Standardposition ist, jeden von Agenten generierten PR als Müll zu deklarieren und automatisch zu schließen. Aber Zechner fand eine Lösung: Er verlangt von den Leuten, dass sie zuerst ein Issue in ihrer eigenen Stimme schreiben, nicht länger als ein Bildschirm, in dem sie genau erklären, was sie tun wollen und warum. Wenn das Issue gut ist, genehmigt er es und die Person kann einen PR senden. Das beweist, dass sie Menschen sind, das Problem verstehen und die Lösung begreifen.

Sobald sie genehmigt sind, kommen sinnvolle PRs durch. Die Clanker-PRs hören auf zu erscheinen. Issues fluten zwar weiterhin herein, aber Zechner triagiert sie manuell. Er liest täglich 30 bis 60 geschlossene Issues durch und identifiziert, welche legitim sind und welche Müll. Bei seinem letzten Triage-Durchlauf kamen 50 Issues rein und 2 überlebten. Es dauert etwa 30 Minuten, da die meisten schnell als Rauschen identifiziert werden können.

Für Projekte in der Größenordnung von OpenClaw funktioniert dieser manuelle Ansatz nicht. Peter Steinbergers Token-Verbrauch erreichte 1,3 Millionen Dollar pro Monat, teilweise weil die Automatisierung der Issue- und PR-Filterung in diesem Maßstab eine ausgeklügelte Infrastruktur erfordert. Zechner schrieb einige Visualisierungstools, um ähnliche Issues zu gruppieren, aber selbst das reichte nicht aus. Das Volumen ist um Größenordnungen größer.

Lokale Inferenz und die Zukunft kleinerer Modelle

Zechner ist optimistisch, was das Ausführen leistungsfähiger KI-Modelle lokal auf Consumer-Hardware angeht. Für sein Roboterprojekt – ein Spielzeug mit einem Smartphone als Mikrocontroller, auf dem ein Coding-Agent läuft – verwendet er Gemma 4 und Qwen 3.6, kleinere Mixture-of-Experts-Modelle. Sie sind mehr als ausreichend für einen Chatbot mit Motor- und Kamerasteuerung, und sie sind schnell.

Das Setup ist erschwinglich. Speech-to-Text mit Parakeet benötigt etwa 10 Gigabyte Unified Memory. Text-to-Speech mit Qwen TTS benötigt weitere 10 Gigabyte. Qwen 3.6 benötigt 4 Gigabyte. Insgesamt: 14 Gigabyte Unified Memory auf macOS oder einem äquivalenten NVIDIA-Setup unter Windows. Das ist für viele Menschen erschwinglich – nicht für die ganze Welt, aber für einen bedeutenden Teil.

Denise Asaves von DeepMind hat vorgeschlagen, dass aktuelle riesige Modelle nicht alle ihre Parameter benötigen und auf viel kleinere Modelle destilliert werden können, ohne viel Ausgabequalität zu verlieren. Zechners Hoffnung ist, dass die Zukunft darin besteht, große Modelle in kleinere zu destillieren, die die meisten Fähigkeiten beibehalten, anstatt spezialisierte Modelle für spezifische Aufgaben zu trainieren. Antirez von Redis hat begonnen, an einer benutzerdefinierten Inferenz-Engine für DeepSeek V4 namens ds4 zu arbeiten, die auf einem 128-Gigabyte-Laptop läuft. Es ist ein wirklich leistungsfähiges Modell, das 60 bis 70 Prozent der Issues bewältigen könnte, die Zechner mit Pi bearbeitet.

Die Kosten von Code und die Disziplin des Handwerks

Zechner hat gesehen, wie Leute innerhalb einer Woche 500.000 Zeilen Code durch Agenten generieren ließen. Das Ergebnis ist immer das gleiche: Katastrophe. Code ist niemals kostenlos, weil die Konsequenzen einen irgendwann einholen. Wenn Sie glauben, dass irgendeine Menge an Code jetzt gut ist, haben Sie die Strafe nur aufgeschoben.

Der eigentliche Flaschenhals in der Softwareentwicklung ist nicht die Tippgeschwindigkeit oder die Code-Generierung. Es ist das Denken, Entwerfen und Erkunden des Lösungsraums. Agenten sind für diese Phase wirklich nützlich – man kann mehreren Agenten sagen, dass sie verschiedene Ansätze erkunden sollen, und die Ergebnisse schneller sehen. Aber das Ergebnis dieser Erkundungen ist nicht automatisch wiederverwendbar. Man muss es immer noch verstehen, refactoren und warten.

Für Zechner kommt die größte Produktivitätssteigerung durch Agenten aus der asynchronen Art der Arbeit. Er kann einem Agenten eine Aufgabe geben, zu einem Meeting gehen und zu Ergebnissen zurückkehren. Aber er glaubt nicht, dass das parallele Ausführen von 10 Agenten seinen Output verzehnfachen wird. Allein das Kontext-Switching ist erschöpfend. Er hat es ein- oder zweimal im Monat gemacht, 30 Issues an einem Tag bearbeitet, und sein Gehirn war danach Matsch.

Der kollaborative Aspekt ist das, was er am meisten schätzt. Einen Agenten als Pair-Programming-Partner zu haben – Fragen stellen, Optionen vorschlagen, Code erklären –, ist wie ein Fahrrad für den Geist. Es hilft ihm, Probleme besser zu durchdenken, als alleine dazusitzen. Aber das erfordert Disziplin: nicht alles an die Maschine zu delegieren, denn jedes Mal, wenn er das tut, landet er in einer Ecke und weint, weil nichts mehr gut ist und alles auseinanderfällt.

Pi refactoren: Für die Zukunft bauen

Pi hat historischen Ballast angesammelt. Teile davon stammen aus der Zeit vor Zechners Nutzung von Agenten und sind solide. Andere Teile, wie der HTML-Export, hat er sich nie angesehen und sie sind ihm egal, solange sie gerendert werden. Einige Teile sind Vibe-coded.

Die Refactoring-Bemühungen haben mehrere Ziele. Erstens: Einfacher in andere Arten von Benutzeroberflächen expandieren – Web, nativ, was auch immer –, ohne bestehende Erweiterungen zu zerstören. Zweitens: Remote-Fähigkeit ermöglichen: eine Pi-Sitzung auf einer Maschine ausführen und sich von einer anderen aus verbinden, mit ordentlicher Dauerhaftigkeit und Beobachtbarkeit. Drittens: Pi’s SDK auf Cloudflare Workers, Vercel und anderen Umgebungen bereitstellbar machen, nicht nur auf lokalen Computern mit Bash.

Zechner refactort auf dem Main-Branch, weil ihn Stabilität im traditionellen Sinne nicht interessiert. Er macht es Stück für Stück, beginnend mit den untersten Paketen, die mit LLM-Anbietern kommunizieren. Der Coding-Agent selbst wird immer noch gleich aussehen und funktionieren, aber die gesamte zugrunde liegende Infrastruktur wird sauber und wiederverwendbar sein. Er hofft, diese Phase in ein oder zwei Wochen abzuschließen und dann ein paar weitere Wochen in den neuen Erweiterungsmechanismus zu investieren, bei dem Erweiterungen serverseitige und UI-seitige Komponenten haben.

Warum Pi standardmäßig im YOLO-Modus läuft

Pi bittet nicht um Erlaubnis, bevor es Code ausführt. Das ist beabsichtigt. Indem er den Leuten sagt, dass der YOLO-Modus gefährlich ist und sie darüber nachdenken sollten, bringt Zechner die Leute tatsächlich dazu, über Sicherheit nachzudenken. Er möchte, dass sie in sich selbst nach Sicherheitsbewusstsein suchen und entscheiden, wie sie agentische Arbeit in ihrer eigenen Umgebung absichern.

Die Antwort ist meist Containerisierung. Wenn Sie nicht möchten, dass der Agent Ihren Computer beschädigt, containerisieren Sie den Agenten oder die Tools, die er verwendet – Datei-Lese-/Schreibzugriffe, Bash, was auch immer. Das löst das Problem. Aber Zechner kann das nicht für Sie entscheiden. Er könnte Anthropic’s Sandbox oder Bubble Wrap bündeln, aber das sind unvollständige Lösungen. In einer Unternehmensumgebung mit spezifischen Infrastruktureinschränkungen funktioniert eine eingebaute Sandbox möglicherweise überhaupt nicht.

Was in Claude Code existiert, ist größtenteils Sicherheitstheater. Claude Code fragt jetzt ein LLM, ob ein Bash-Befehl sicher ist, bevor es ihn im Auto-Modus ausführt. Zechner hält das nicht für gut. Ein LLM kann nicht zuverlässig bestimmen, ob ein Befehl sicher ist – es kann nur basierend auf Mustern raten.

Fazit

Pi repräsentiert eine andere Philosophie: Tools bauen, die Entwickler besitzen und modifizieren können, nicht Tools, die Entwickler besitzen. Der Erfolg von Pi wird nicht an Features oder Benchmarks gemessen, sondern daran, ob Zechner ein kleines Team am Leben erhalten und weiterhin Anwendungen agentischer Arbeit erforschen kann – vom Programmieren über Robotik bis hin zur lokalen Inferenz.

Die breitere Lektion ist, dass Workflows wichtiger sind als Hype. Stabilität, Vorhersehbarkeit und die Fähigkeit, Ihre Tools anzupassen, sind mehr wert als das neueste Feature. Und Code ist niemals kostenlos – die Konsequenzen Ihres Handelns werden Sie irgendwann einholen.