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.

Gemeint ist also das Geschirr, in das man die KI einspannt, und nicht die KI selbst. 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 da wird es interessant.

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 trifft es die Sache aber ziemlich genau.

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 ein Terminal-Harness mit klaren Kanten statt eines überladenen Agenten-Raumschiffs.

Das mag ich sehr.

Weniger Features sind nicht automatisch besser. Aber weniger fest eingebaute Meinung bedeutet meistens, 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 Subagents, keine Todo-Listen. Permission-Popups sind keine Grundannahme, MCP ist keine 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

Minimal ist bei Pi der Ausgangspunkt und nicht das Ergebnis.

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.

Spätestens da ist Pi für mich weniger ein Tool und mehr 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 einen 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 angenehm 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, ohne dabei dümmer zu wirken.

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. Damit ist Pi auch eine Schicht, die man einbetten kann, und nicht nur eine App.
• 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 vorgefertigte Regeln 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.

Und zwar gerade, 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 deshalb ist Pi für mich gutes Zeug: Es lässt mich meinen eigenen Agentenworkflow bauen, anstatt selbst einer sein zu wollen.