Pi: Es gibt viele Coding Harnesses, aber dieser ist meiner

Coding-Agenten sind inzwischen überall.

Und damit meine ich nicht nur die Modelle selbst. Ich meine die ganze Schicht darum herum: Terminal, Tools, Dateizugriff, Bash, Sessions, Kontext, Prompts, Shortcuts, UI, kleine Sicherheitsregeln und all diese Dinge, die aus einem Chatfenster erst ein Werkzeug machen.

Diese Schicht ist ein Coding Harness.

Also nicht die KI selbst, sondern das Geschirr, in das man sie einspannt. Das Modell denkt und schreibt. Das Harness entscheidet, welche Werkzeuge es bekommt, wie es Dateien liest, wie es Shell-Kommandos ausführt, wie Kontext geladen wird, wie Sessions gespeichert werden und wie ich als Mensch dazwischenfunken kann.

Und genau da wird es spannend.

Denn es gibt viele Coding Harnesses.

Aber Pi ist gerade der, der sich für mich am meisten nach meinem eigenen anfühlt.

Warum Pi anders wirkt

Pi beschreibt sich selbst als „minimal terminal coding harness“.

Das klingt erstmal nach Understatement.

In der Praxis ist es aber ziemlich genau der Punkt.

Pi kommt nicht mit der Haltung: „Hier ist dein neuer Workflow, bitte gewöhne dich daran.“ Es kommt eher mit: „Hier ist ein schlanker Kern, bau dir den Rest so, wie du ihn brauchst.“

Standardmäßig bekommt das Modell nur wenige Werkzeuge. Im Kern sind das read, write, edit und bash. Weitere eingebaute Read-only-Tools wie grep, find und ls kann man dazunehmen, aber die Grundidee bleibt: kein überladenes Agenten-Raumschiff, sondern ein Terminal-Harness mit klaren Kanten.

Das mag ich sehr.

Nicht, weil weniger Features automatisch besser sind. Sondern weil weniger fest eingebaute Meinung oft bedeutet, dass ich weniger gegen das Tool arbeiten muss.

Barebones heißt hier nicht schwach

Pi lässt bewusst Dinge weg, die andere Tools direkt einbauen.

Kein eingebauter Plan Mode.

Keine eingebauten Subagents.

Keine eingebauten Todo-Listen.

Keine Permission-Popups als Grundannahme.

Kein MCP als Pflichtschicht.

Das klingt je nach Erwartung erstmal fast frech.

Aber ich verstehe den Ansatz: Pi will nicht entscheiden, _wie_ ich diese Dinge haben möchte. Wenn ich Plan Mode will, kann ich ihn als Extension bauen oder installieren. Wenn ich Subagents will, kann ich sie über Extensions, tmux oder ein Package lösen. Wenn ich Permission Gates brauche, baue ich sie passend zu meinem Setup, statt mich durch generische Popups zu klicken.

Das ist nicht für jeden angenehmer.

Aber für mich ist es genau richtig.

Ich mag Werkzeuge, die eine gute Grundform haben und mir dann aus dem Weg gehen.

Das wirklich Gute: alles ist pluggable

Der wichtigste Punkt bei Pi ist nicht, dass es minimal ist.

Der wichtigste Punkt ist, dass minimal nicht das Ende ist.

Pi lässt sich über TypeScript-Extensions erweitern. Und das ist kein kleines „du kannst die Farbe ändern“-Plugin-System. Extensions können eigene Tools registrieren, Slash-Commands hinzufügen, Events abfangen, Tool Calls blockieren oder verändern, eigene UI-Komponenten einbauen, den Footer umbauen, eigene Provider registrieren, Compaction anpassen oder sogar Dinge wie Subagents und Plan Mode nachrüsten.

Dazu kommen Skills, Prompt Templates, Themes und Pi Packages.

Skills sind für wiederverwendbare Arbeitsweisen gedacht. Prompt Templates sind kleine abrufbare Prompt-Bausteine. Themes ändern das Terminalgefühl. Packages bündeln den ganzen Kram und machen ihn teilbar.

Das ist für mich der Punkt, an dem Pi nicht mehr nur ein Tool ist.

Es ist eher eine Werkbank für Coding-Agenten.

Was ich wirklich nutze

$ pi list

User packages:
  npm:@howaboua/pi-glm-via-anthropic
  npm:@sting8k/pi-vcc
  https://github.com/leandr0ck/pi-find-skills
  npm:@aliou/pi-processes
  npm:pi-mcp-adapter
  npm:pi-web-access
  npm:@tintinweb/pi-subagents
  npm:@marckrenn/pi-sub-bar
  npm:pi-quit
  https://github.com/patriceckhart/pi-btw
  npm:pi-rtk-optimizer
  npm:pi-tool-display
  npm:@marckrenn/pi-sub-core
  https://github.com/muffe/pi-kimi-usage
  npm:@eko24ive/pi-ask
  /opt/pi-ext-sync
  npm:pi-crofai

Das sieht auf den ersten Blick natürlich erstmal nach recht viel aus.

Wenn man allerdings bedenkt, wie pi nackt aufgestellt ist, habe ich mit dieser Handvoll Extensions den Harness an genau dem Punkt, wo ich ihn haben will.

Nicht weniger, nicht mehr.

Und dank der guten Dokumentation sind die selbstgemachten Extensions nur dadurch entstanden, dass ich ein Prompt geschrieben hab, à la

Bau mir eine Extension für dich selbst, die xyz macht.

Nicht weniger, nicht mehr.

Der kurze System-Prompt ist kein Zufall

Ein Detail, das ich an Pi besonders mag: Der Default-System-Prompt ist erstaunlich kurz.

Er sagt im Kern: Du bist ein Coding-Assistent in Pi, du kannst Dateien lesen, Kommandos ausführen, Code editieren und neue Dateien schreiben. Dann listet er die verfügbaren Tools, ein paar Guidelines wie „sei kurz“ und „zeige Dateipfade klar“, plus Projektkontext, Skills und relevante Pi-Doku, wenn es um Pi selbst geht.

Das war es fast schon.

Natürlich wächst der Prompt dynamisch, wenn Projektregeln, Skills oder Extensions dazukommen. Aber Pi startet nicht mit einem Roman darüber, wie der Agent gefälligst zu denken hat.

Ich finde das wichtig.

Viele Agentenprobleme entstehen nicht nur durch das Modell, sondern durch zu viel Harness-Meinung im Prompt. Zu viele Regeln, zu viele Rituale, zu viele implizite Produktentscheidungen. Pi fühlt sich an der Stelle leichter an.

Nicht dümmer.

Leichter.

Was ich im Alltag daran mag

• Es läuft im Terminal. Genau da, wo meine Projekte ohnehin sind.
• Es speichert Sessions sauber. Inklusive Branching, Forking und Tree-Navigation, wenn man zurückspringen will.
• Es unterstützt viele Provider. Subscription-Logins und API-Key-Provider sind nicht auf einen Anbieter verengt.
• Es ist offen für eigene Modelle und Provider. Lokale Modelle, Proxies oder eigene APIs sind nicht sofort ein Sonderfall.
• Es kann interaktiv, als Print/JSON, über RPC und per SDK laufen. Das macht Pi nicht nur zu einer App, sondern zu einer Schicht, die man auch einbetten kann.
• Es fühlt sich ehrlich an. Wenn etwas nicht eingebaut ist, ist das meistens eine bewusste Entscheidung, kein vergessenes Feature.

Gerade zusammen mit kleinen Tools wie RTK ergibt das für mich eine sehr angenehme Agenten-Umgebung: weniger Lärm, weniger Produktmagie, mehr Kontrolle.

Welche Modelle ich dafür gerade am liebsten einspanne, habe ich bewusst ausgelagert: Meine LLMs für Pi. Die Modellfrage ist nämlich schnell ein eigener kleiner Zoo.

Was Pi nicht für dich übernimmt

Pi ist kein weich gepolsterter Agenten-Freizeitpark.

Wenn du willst, dass ein Tool dir jede Entscheidung abnimmt, überall Best Practices einbaut, jeden gefährlichen Befehl mit Popups abfedert und direkt eine komplette Projektmanagement-Philosophie mitliefert, ist Pi vielleicht nicht der bequemste Einstieg.

Pi vertraut dir mehr.

Das ist schön, wenn du weißt, was du willst.

Und gefährlich, wenn du eigentlich ein Geländer gesucht hast.

Ich würde Pi deshalb nicht jedem als erstes Agentenwerkzeug empfehlen. Aber ich würde es sehr schnell den Leuten empfehlen, die nach zwei Wochen mit anderen Tools denken: „Kann ich das nicht einfach anders haben?“

Würde ich Pi empfehlen?

Ja.

Für mich ist Pi aktuell das Coding Harness, das am besten zu meiner Art zu arbeiten passt.

Nicht, weil es alles eingebaut hat.

Sondern weil es bewusst nicht alles einbaut.

Es gibt mir Terminal, Modell, Tools, Kontext, Sessions und eine sehr offene Erweiterungsschicht. Den Rest darf ich selbst entscheiden.

Und genau deshalb ist Pi für mich gutes Zeug.

Es versucht nicht, mein Agentenworkflow zu werden.

Es lässt mich meinen eigenen bauen.