Pi verstehen

Pi verstehen

0:00 Es gibt inzwischen viele Werkzeuge, die beim Programmieren mit Künstlicher Intelligenz helfen. Warum also noch eines? Genau diese Frage nehmen wir uns in diesem Modul vor. Pi ist ein Coding Agent, der bewusst klein ist — und der gerade dadurch etwas anderes bietet als die großen, fertig ausgestatteten Alternativen. Wir schauen uns an, was Pi überhaupt tut, wie es sich zu Claude Code oder Codex verhält, und wo es im Alltag von Entwicklerinnen und Entwicklern echten Nutzen bringt.

0:27 Am Ende sollen Sie einordnen können, für welche Aufgaben sich dieses Werkzeug lohnt — und für welche nicht.

Pi verstehen — warum noch ein Coding Agent?

0:34 „There are many agent harnesses but this one is yours" — so wirbt das Projekt für sich selbst. Ein selbstbewusster Satz, der schon das ganze Konzept enthält: Pi will nicht das Werkzeug sein, das Ihnen vorgibt, wie Sie arbeiten, sondern das Werkzeug, das sich Ihrer Arbeitsweise anpasst. Dieses erste Modul ist bewusst noch Einordnung, kein Handwerk. Installiert wird ab Modul zwei.

0:56 Hier klären wir die Begriffe und die Erwartungshaltung — denn beides entscheidet später darüber, ob Sie das Werkzeug produktiv nutzen oder enttäuscht wieder weglegen. Vier Fäden ziehen sich durch dieses Modul. Der erste ist der Begriff selbst: Pi versteht sich als schlankes Terminal-Harness, also als knapper Rahmen um ein Sprachmodell.

1:16 Der zweite Faden sind die vier Bausteine — Modelle, Tools, Kontext und Sessions —, die uns durch das ganze Seminar begleiten. Der dritte Faden ist überraschend: Es lohnt sich, über das zu sprechen, was Pi ausdrücklich nicht mitbringt. Und der vierte Faden ist die realistische Erwartung an ein Werkzeug, das in Ihrem Namen Dateien schreibt und Befehle ausführt.

1:37 Das klingt harmlos, ist aber die wichtigste Weichenstellung.

Was Pi von klassischen KI Coding Tools unterscheidet

1:41 Fangen wir mit der Unterscheidung an, die im Alltag am meisten Verwirrung stiftet. Viele Menschen setzen KI-Autocomplete im Editor und einen Coding Agent gleich — beide schreiben ja Code. Der Unterschied liegt aber nicht in der Intelligenz des Modells, sondern darin, was das Werkzeug tun darf. Genau darum geht es in diesem Kapitel.

2:01 Stellen Sie sich zwei Kollegen vor. Der eine sitzt neben Ihnen und vervollständigt Ihre Sätze, während Sie tippen. Der andere bekommt einen Auftrag, geht damit ins Projekt, öffnet Dateien, ändert sie, ruft die Tests auf und kommt mit einem Ergebnis zurück. Der erste ist Autocomplete, der zweite ist ein Agent. Pi ist der zweite Fall: ein Programm, das ein Sprachmodell in einer Schleife laufen lässt und ihm Werkzeuge in die Hand gibt — Lesen, Schreiben, Ändern, Shell.

2:30 Das ist ein qualitativer Sprung, nicht nur eine Komfortstufe. Und es erklärt, warum wir später so viel über Rechte reden. Warum lohnt sich dieser Unterschied? Weil er über die Art der Aufgaben entscheidet, die Sie delegieren können. Ein Vorschlagsgenerator hilft beim Tippen. Ein Agent kann eine Aufgabe über mehrere Dateien und mehrere Schritte tragen — und er sieht dabei das echte Projekt, nicht nur den geöffneten Editor-Puffer.

2:56 Sie bekommen als Ergebnis keine Textwand im Chatfenster, sondern Änderungen im Arbeitsverzeichnis, die Sie mit den Mitteln prüfen können, die Sie ohnehin haben: Diff, Tests, Linter. Das ist der eigentliche Gewinn — Ergebnisse, die überprüfbar sind. Die Logik hinter dieser Gegenüberstellung ist einfach: Je größer die Reichweite eines Werkzeugs, desto größer Ihre Verantwortung dafür.

3:19 Links brauchen Sie nur die Tabulatortaste und Ihr Urteil über eine Zeile. Rechts müssen Sie Rechte vergeben, Ergebnisse lesen und Grenzen setzen. Beide Spalten schließen sich nicht aus — die meisten Teams nutzen beides parallel, für unterschiedliche Aufgaben. Wichtig ist nur, die Erwartung nicht zu verwechseln. Wer von einem Agenten die Bequemlichkeit von Autocomplete erwartet, wird unvorsichtig. Und wer von Autocomplete Projektverständnis erwartet, wird enttäuscht.

3:47 Worauf es hier ankommt, ist nicht die Syntax, sondern eine Reihenfolge: Erst wechseln Sie in das Projekt, dann starten Sie den Agenten. Das Arbeitsverzeichnis ist bei Pi keine Nebensache, es ist der Rahmen, in dem alles passiert. Sie sehen außerdem drei Betriebsarten in nur vier Zeilen: interaktiv arbeiten, ein einzelner Durchlauf für eine konkrete Frage, und die Variante, bei der Sie mit dem At-Zeichen ausdrücklich Dateien in den Auftrag hineinlegen.

4:13 Behalten Sie das At-Zeichen im Kopf — es ist der billigste Präzisionsgewinn, den dieses Werkzeug zu bieten hat.

Das Prinzip eines bewusst schlanken Coding Agents

4:20 Jetzt zum vielleicht eigenwilligsten Teil von Pi. Die meisten Werkzeuge werben mit dem, was sie können. Pi wirbt zusätzlich mit dem, was es weglässt. Das klingt zunächst nach einem Nachteil — und ist bei genauerem Hinsehen eine bewusste Entwurfsentscheidung mit klaren Folgen für Ihre Arbeit. „Primitives, not features" — Grundbausteine statt Funktionen.

4:41 Der Leitsatz des Projekts lautet, man solle Pi an die eigenen Arbeitsabläufe anpassen können, ohne die Innereien zu forken. Denken Sie an eine Werkbank statt an eine Küchenmaschine: Die Maschine hat für alles ein Programm, aber nur für das, was der Hersteller vorgesehen hat. Die Werkbank ist erst einmal leer — Sie hängen die Werkzeuge auf, die Sie wirklich brauchen.

5:03 Bei Pi heißen diese Werkzeuge Extensions, Skills, Prompt Templates, Themes und Packages. Dazu kommen vier Betriebsmodi, von der interaktiven Oberfläche bis zum Einsatz als Bibliothek im eigenen Code. Was gewinnen Sie durch einen kleinen Kern? Vor allem Überschaubarkeit. Was klein ist, können Sie lesen, prüfen und im Zweifel ersetzen.

5:24 Erweiterungen sind TypeScript-Module in Ihrem eigenen Projekt — kein Fork, keine Wartungslast an fremdem Code. Und kein eingebautes Feature drängt Ihrem Team einen Ablauf auf, den es gar nicht will. Der Preis dafür ist Eigenarbeit: Sie müssen entscheiden, was Sie brauchen. Meine Einschätzung: Für Teams mit eigenen Konventionen ist das ein echter Gewinn, für Einzelanwender, die ein fertiges Rundum-Werkzeug erwarten, eher Mehraufwand.

5:50 Diese Liste liest sich zunächst wie ein Mängelbericht — und ist doch das Gegenteil. Das Prinzip dahinter: Jede eingebaute Funktion ist auch eine Vorentscheidung darüber, wie Sie arbeiten. Wo andere Werkzeuge ein Protokoll für externe Tools, Unter-Agenten oder einen Planungsmodus fest verdrahten, lässt Pi die Stelle frei — und Sie füllen sie, wenn Sie sie brauchen.

6:11 Am deutlichsten wird das bei den Berechtigungs-Popups: Statt einer Nachfrage bei jedem Schritt setzen Sie die Rechte vorher bewusst. Das ist unbequemer, aber ehrlicher — und wir kommen darauf in Modul drei ausführlich zurück. Vier Missverständnisse begleiten dieses Konzept zuverlässig. Das erste ist die Verwechslung von „fehlt" und „kann nicht" — vieles lässt sich nachrüsten, es ist nur nicht vorinstalliert.

6:35 Das zweite ist das Gegenteil: Erweiterungen sammeln, ohne sie zu pflegen. Jede davon ist Code, der mit Ihren Rechten läuft. Das dritte ist die Erwartung, dass das Werkzeug den Arbeitsablauf vorgibt — bei Pi kommt diese Vorgabe von Ihnen. Und das vierte: den kleinen Kern als Sparversion zu lesen. Er ist keine Einschränkung, er ist der Ort, an dem Sie Kontrolle gewinnen.

Pi im Vergleich zu Claude Code, Codex und anderen Agenten

6:58 Kommen wir zur Frage, die in jedem Team gestellt wird: Wie verhält sich Pi zu den bekannten Namen? Ich halte mich hier bewusst an nachprüfbare Unterschiede statt an Ranglisten — denn welches Werkzeug „besser" ist, hängt davon ab, was Sie steuern wollen. Der zentrale Unterschied ist die Modellbindung. Pi ist providerunabhängig und setzt auf eigene Schlüssel: Derselbe Agenten-Loop läuft gegen Modelle verschiedener Anbieter — das Projekt nennt über fünfzehn Provider und Hunderte Modelle, von Anthropic und OpenAI über Google, Azure und Bedrock bis zu Groq, OpenRouter und lokalem Ollama.

7:32 Stellen Sie sich einen Stromadapter vor, der in jede Steckdose passt: Das Gerät bleibt dasselbe, die Quelle wechseln Sie nach Bedarf. Praktisch heißt das: Ein Modellwechsel ist eine Konfigurationsfrage, kein Werkzeugwechsel — und keine neue Einarbeitung. Warum ist das mehr als eine technische Fußnote? Weil Modellauswahl längst eine Kostenfrage ist.

7:53 Wenn Sie zwischen Anbietern wechseln können, verhandeln Sie nicht nur Preise, sondern auch Abhängigkeiten. Die Abrechnung läuft über Ihre eigenen Zugänge, es gibt keine Lizenzgebühr für das Werkzeug selbst. Lokale Modelle sprechen Sie über dieselbe Oberfläche an — interessant, wenn Code das Haus nicht verlassen darf. Und Sie können dieselbe Aufgabe von zwei Modellen bearbeiten lassen und die Ergebnisse vergleichen. Das ist keine Spielerei, sondern eine erstaunlich wirksame Qualitätskontrolle.

8:22 Bitte lesen Sie diese Tabelle nicht als Punktevergabe. Sie beschreibt vier Achsen, auf denen sich Werkzeuge unterscheiden: Wie frei ist die Modellwahl? Wie viel ist eingebaut? Wie weit reicht die Anpassung? Und können Sie den Quellcode überhaupt lesen? Für ein Team mit strengen Datenschutzvorgaben zählt die erste Zeile am meisten.

8:41 Für ein Team, das schnell starten will und keine Lust auf Eigenbau hat, spricht viel für die andere Spalte. Die ehrliche Antwort lautet also: Es hängt davon ab, wie viel Kontrolle Sie brauchen — und wie viel Pflege Sie leisten wollen. Jetzt sind Sie dran. Die Aufgabe klingt harmlos, ist aber unangenehm konkret: Nennen Sie für ein Projekt, das Sie wirklich kennen, drei Kriterien — und entscheiden Sie je Kriterium, welches Werkzeug besser passt.

9:08 Es geht ausdrücklich nicht darum, das Ergebnis „Pi" herauszubekommen. Es geht darum, die Entscheidung begründen zu können, statt sie nach Bekanntheit zu treffen. Wer mag, nimmt die Stretch-Variante und sucht ein Kriterium, das gegen Pi spricht. Genau solche Gegenargumente machen die eigene Entscheidung belastbar.

Modelle, Tools, Kontext und Sessions verstehen

9:27 Jetzt legen wir das Begriffsfundament für alle weiteren Module. Vier Wörter — und wenn Sie diese vier auseinanderhalten können, verstehen Sie später auch, warum ein Agent sich unerwartet verhält und an welcher Stelle Sie eingreifen müssen. Vier Bausteine, vier Zuständigkeiten. Das Modell liefert die Sprachfähigkeit — es formuliert und schließt.

9:47 Die Tools liefern die Handlungsfähigkeit: ohne sie bleibt jede Absicht Text. Der Kontext ist das Projektwissen, das im aktuellen Aufruf sichtbar ist. Und die Session ist das Gedächtnis über die Zeit. Ein Bild dazu: Das Modell ist die Fachkraft, die Tools sind ihr Werkzeugkasten, der Kontext ist der Bauplan auf dem Tisch — und die Session ist das Bautagebuch.

10:09 Fehlt eines davon, merken Sie es sofort, nur eben an unterschiedlichen Symptomen. Diese Zuordnung ist praktisch, weil sie Fehlersuche ermöglicht. Beim Modell regeln Sie Auswahl und Denktiefe — über Kommandos oder Startoptionen. Bei den Tools ist die Liste überschaubar: Lesen, Shell, Ändern, Schreiben, dazu Suchen, Finden und Auflisten.

10:30 Beim Kontext geht es um Dateien und um die Projektanweisungen, die Pi automatisch lädt. Und die Session liegt als Textdatei im Baumformat auf Ihrer Platte, jeder Eintrag mit eigener und mit Elternkennung. Wenn Sie also merken, dass der Agent eine Absprache vergessen hat, wissen Sie schon, welcher der vier Bausteine gemeint ist.

10:51 Der roten Faden dieser fünf Schritte ist: erst rüsten, dann arbeiten, dann sichern. Sie wählen zuerst Modell und Denktiefe passend zur Aufgabe — für eine Umbenennung braucht niemand die höchste Stufe. Dann legen Sie die relevanten Dateien ausdrücklich in den Auftrag, statt zu hoffen, dass der Agent sie findet. Projektregeln schreiben Sie einmal auf, statt sie zu wiederholen.

11:12 Während der Arbeit lesen Sie die Werkzeugaufrufe mit — das ist Ihr Blick in die Werkstatt. Und am Ende geben Sie der Session einen Namen, damit Sie morgen weiterarbeiten können, statt neu zu erklären. Worauf es hier ankommt, ist ein Muster, nicht die Schreibweise: Sie schauen zuerst nach, welche Modelle Ihr Zugang wirklich hergibt — und stellen dann dieselbe Frage zweimal, mit unterschiedlichen Modellen.

11:35 Beachten Sie die Doppelpunkt-Schreibweise, mit der Modell und Denktiefe in einer Angabe zusammenfallen. Das ist im Alltag überraschend nützlich: Sie können dieselbe Aufgabe mit wenig und mit viel Denkbudget laufen lassen und den Unterschied selbst beurteilen. Und die letzte Zeile zeigt, dass Sie zu einer alten Sitzung zurückkehren können — dazu kommt in Modul elf noch viel mehr.

11:56 Diese Übung ist bewusst diagnostisch. Sie bekommen vier typische Beobachtungen aus dem Alltag: Der Agent trifft eine falsche Annahme, er sieht eine Datei nicht, er ignoriert eine Projektregel, oder er hat den Gesprächsstand verloren. Ihre Aufgabe ist, jeweils den verantwortlichen Baustein zu benennen und den passenden Hebel zu nennen.

12:15 Das klingt nach Trockenübung, zahlt sich aber sofort aus: Wer die Symptome zuordnen kann, sucht nicht am falschen Ende — und spart sich viele Prompts, die ohnehin nichts geändert hätten.

Wo Pi im Entwicklungsalltag echten Nutzen bringt

12:26 Nach der Theorie die Nüchternheit: Wo lohnt sich der Einsatz wirklich? Nicht alles, was möglich ist, ist auch sinnvoll. In diesem Kapitel geht es um die Aufgaben, bei denen der Aufwand-Nutzen-Vergleich klar zugunsten des Agenten ausfällt. Der Nutzen liegt dort, wo viel Projektkontext gebraucht wird und die Ausführung billig ist.

12:45 Code erschließen, Zusammenhänge erklären, Änderungen vorbereiten, die begleitenden Kommandos ausführen — und das alles im Verzeichnis des Projekts. Denken Sie an einen neuen Kollegen, der schnell liest und keine Scheu hat, in jede Datei zu schauen. Genau das ist die Stärke. Die Grenze ist ebenso klar: Wo fachliche Entscheidungen gefragt sind, die niemand aufgeschrieben hat, hilft auch schnelles Lesen nicht weiter.

13:10 Der häufigste erste Erfolg ist die Einarbeitung. „Fasse dieses Repository zusammen und zeig mir, wie die Checks laufen" — dieser eine Satz ersetzt oft eine Stunde Herumklicken. Der zweite Gewinn ist Wiederholbarkeit: Was Sie einmal erarbeitet haben, halten Sie als Skill oder als Prompt Template fest, statt es neu zu erklären.

13:29 Der dritte Punkt ist unauffällig, aber wichtig: Die Werkzeuge und Konventionen Ihres Projekts sind über die Shell erreichbar. Und weil das Ergebnis aus Dateien und Ausgaben besteht, ist es überprüfbar — der Unterschied zwischen Behauptung und Beleg. Der Zweck dieser fünf Schritte ist, in kurzer Zeit von null auf belastbares Projektwissen zu kommen.

13:49 Sie starten im Projekt und entscheiden bewusst über das Projektvertrauen — nicht wegklicken, das ist eine echte Entscheidung. Dann lassen Sie sich einen Überblick geben und fragen sofort nach Build und Tests, weil sich diese Aussagen in Sekunden überprüfen lassen. Zwei oder drei Kerndateien schieben Sie ausdrücklich nach. Und dann kommt der Schritt, den die meisten überspringen: das Ergebnis im Projekt festhalten.

14:13 Was Pi behauptet, gilt erst, wenn ein Kommando es bestätigt hat.

Typische Einsatzszenarien für Entwickler und Teams

14:17 Aus der Einzelnutzung wird schnell Teamarbeit. Und dann stellt sich die Frage, in welcher Betriebsart Sie den Agenten überhaupt einsetzen. Pi bietet dafür vier Wege — und die Wahl hat handfeste Folgen für Prüfbarkeit und Risiko. Vier Muster begleiten den Alltag: Sie arbeiten interaktiv im Terminal, Sie lassen einen einzelnen Durchlauf laufen und verarbeiten die Ausgabe weiter, Sie betreiben Pi als Dienst, den ein anderes Programm anspricht, oder Sie binden es als Bibliothek in eigenen Code ein.

14:46 Wichtig ist: Dieselbe Aufgabe kann in verschiedenen Mustern sinnvoll sein — und in einem davon gefährlich. Je weiter Sie nach hinten wandern, desto weniger Menschen schauen zu. Halten Sie diesen Zusammenhang im Kopf, er kommt im Sicherheitsmodul mit voller Kraft zurück. Interaktiv arbeiten Sie, solange die Aufgabe unscharf ist und ausgehandelt werden muss.

15:07 Der einmalige Durchlauf mit maschinenlesbarer Ausgabe ist die Wahl für skriptbare Analysen, deren Ergebnis weiterverarbeitet wird. Dienst- und Bibliotheksbetrieb machen Pi zu einem Baustein in Ihren eigenen Werkzeugen. Und für Teams zählt vor allem der letzte Punkt: geteilte Projektanweisungen, Skills und Templates im Repository — statt privater Prompt-Sammlungen auf einzelnen Rechnern.

15:29 Wissen, das im Repository liegt, überlebt Personalwechsel. Wissen im Chatverlauf tut das nicht. Das Prinzip dieser Tabelle steckt in der rechten Spalte. Zu jedem Szenario gehört ein Prüfpunkt — die Frage, woran Sie erkennen, dass das Ergebnis brauchbar ist. Beim Erschließen sind es Kommandos, die die Aussagen bestätigen. In der Automatisierung sind es Rückgabewert und Ausgabeformat.

15:53 Beim eigenen Werkzeug sind es die Tests des umgebenden Programms. Und bei Teamregeln ist es das Review der Datei im Repository. Merken Sie sich diese Kopplung: Je unbeaufsichtigter der Modus, desto wichtiger der Prüfpunkt — und desto enger die Umgebung, in der der Agent laufen sollte. Hier wird es konkret für Ihre Situation. Nehmen Sie eine Aufgabe, die in Ihrem Team wirklich wiederkehrt, und wählen Sie dafür einen Modus.

16:19 Der eigentliche Lernwert steckt in zwei Zusatzforderungen: Nennen Sie den Prüfpunkt — und begründen Sie, warum die anderen drei Modi nicht passen. Diese Begründung ist der Punkt, an dem sich Bauchgefühl von Entscheidung trennt. Und sie ist gleichzeitig eine gute Vorlage für das Gespräch mit Kolleginnen und Kollegen, die dem Thema skeptisch gegenüberstehen.

Grenzen und sinnvolle Erwartungen an Coding Agents

16:40 Jetzt kommt das Kapitel, das ich für das wichtigste dieses Moduls halte. Wir sprechen über Grenzen — nicht um das Werkzeug schlechtzureden, sondern damit Sie es mit offenen Augen einsetzen. Und eine dieser Grenzen wird Sie überraschen. Pi bringt keinen eingebauten Sandkasten mit. Die Dokumentation sagt das erfreulich klar: Die eingebauten Werkzeuge lesen, schreiben und ändern Dateien und führen Shell-Befehle aus — mit den Rechten des Prozesses.

17:07 Und das Projektvertrauen, das beim Start abgefragt wird, ist ausdrücklich nur ein Ladeschutz: Es verhindert, dass ein Repository still Ihre Konfiguration verändert. Es schützt nicht Ihr Dateisystem. Anders gesagt: Sie leihen dem Agenten Ihr Benutzerkonto. Das ist keine Schwäche des Werkzeugs, sondern eine ehrliche Angabe — und der Grund für das nächste Modul.

17:29 Vier Konsequenzen ergeben sich daraus. Erstens: Der Agent kann alles, was Ihr Konto kann — nicht mehr, aber eben auch nicht weniger. Zweitens: Erweiterungen sind Module mit genau denselben Rechten, fremder Code also mit vollem Zugriff. Drittens empfiehlt die Dokumentation für unbeaufsichtigte Läufe ausdrücklich Container, virtuelle Maschine oder eine kontrollierte Sandbox.

17:52 Und viertens, der Punkt, der leicht untergeht: Sprachmodelle irren plausibel. Eine überzeugend formulierte Aussage ist kein Beleg. Sicherheit vor Bequemlichkeit — dieser Satz trägt hier ausnahmsweise wörtlich. Diese vier Fehler passieren nicht aus Nachlässigkeit, sondern aus Routine. Man klickt Projektvertrauen weg, weil man es zehnmal am Tag sieht.

18:14 Man lässt Zugangsdaten im Home-Verzeichnis liegen, weil sie dort immer lagen. Man übernimmt eine Änderung, weil sie plausibel klingt und die Zeit drängt. Und man verlässt sich darauf, dass ein fehlendes Feature — etwa ein Planungsmodus — schon Fehler verhindert hätte. Der gemeinsame Kern: Gewohnheit ersetzt Prüfung. Deshalb lohnt es sich, sich die Prüfschritte als festen Bestandteil des Ablaufs anzugewöhnen, nicht als Ausnahme.

18:40 Diese Übung trainiert genau diese Haltung. Nehmen Sie eine Aussage des Agenten über Ihr Projekt und zerlegen Sie sie in belegbare und unbelegte Anteile. Für zwei Anteile bringen Sie den Beleg selbst bei — mit einem Kommando, dessen Ausgabe Sie sehen. Mindestens eine Aussage markieren Sie als unbelegt. Das ist ausdrücklich kein Misstrauensvotum gegen das Werkzeug, sondern normale Ingenieursarbeit.

19:04 Und wenn kein Kommando zur Hand ist, hilft die Fallback- Variante: Lassen Sie die Aussage im Team gegenlesen.

Vom Chatbot zum aktiv arbeitenden Entwicklungswerkzeug

19:12 Zum Abschluss ziehen wir die Linie zusammen. Was macht aus einem Chatfenster ein Werkzeug, mit dem man wirklich entwickelt? Es sind drei Dinge — und alle drei begleiten uns durch die restlichen elf Module. Der Sprung entsteht durch Werkzeugzugriff im Projekt, durch dauerhaft hinterlegten Kontext in einer Projektanweisungsdatei — und durch Sessions, die Arbeit über Tage tragen, samt Verzweigen in Alternativen.

19:36 Stellen Sie sich den Unterschied zwischen einem Telefonat und einem gemeinsamen Werkstattbuch vor: Das Telefonat ist weg, sobald Sie auflegen. Das Werkstattbuch können Sie morgen aufschlagen, und ein Kollege versteht, was Sie gestern probiert haben. Genau diesen Unterschied machen Kontextdateien und Sessions. Was heißt das praktisch? Antworten werden zu Diffs, zu Kommandos und zu prüfbaren Ergebnissen. Wissen wandert vom privaten Prompt ins Repository, wo es reviewt und geteilt wird.

20:04 Arbeitsstände bleiben wiederauffindbar, statt im Verlauf zu verschwinden. Und selbst lange Sitzungen bleiben handhabbar, weil Pi älteren Verlauf zusammenfasst statt ihn abzuschneiden. Der eigentliche Fortschritt gegenüber einem Chatbot ist damit weniger Intelligenz als Beständigkeit — und Beständigkeit ist das, was im Projektalltag zählt.

20:25 Zum Schluss der Fahrplan. Modul zwei richtet die Umgebung ein: installieren, Modelle anbinden, Standards setzen. Modul drei behandelt Rechte, Vertrauen und Isolation — nach allem, was wir gerade gehört haben, an genau der richtigen Stelle. Die Module vier und fünf sind Handwerk: Entwicklungsalltag und der gezielte Umgang mit Kontext.

20:45 Danach folgen die Bausteine, mit denen Sie Pi zu Ihrem Werkzeug machen: Projektanweisungen, Packages, Skills, Templates und eigene Erweiterungen. Und die letzten zwei Module bringen Session-Management und Ihr eigenes Praxisprojekt. Ab Modul zwei wird gearbeitet, nicht mehr eingeordnet.

Pi ist ein Werkzeug, das Sie formen

21:03 Halten wir vier Dinge fest. Pi hat einen kleinen Kern und vier klare Bausteine: Modelle, Tools, Kontext, Sessions. Was fehlt, fehlt mit Absicht — und lässt sich über Erweiterungen nachrüsten, wenn Sie es wirklich brauchen. Volle Rechte bedeuten, dass Sie diese Rechte bewusst setzen müssen; genau davon handelt das nächste Modul.

21:24 Und alle Angaben in diesem Foliensatz stammen aus der offiziellen Dokumentation, Stand August 2026 — was dort nicht steht, haben wir hier auch nicht behauptet.