Development Workflow

Pi im täglichen Development Workflow

0:00 Die Umgebung steht, die Rechte sind gesetzt — jetzt wird gearbeitet. Dieses Modul ist reines Handwerk: Wie erschließt man ein fremdes Projekt, wie gibt man Kontext, wie entwickelt man ein Feature, wie sucht man einen Fehler, wie baut man um? Der Leitsatz dazu: Der Agent beschleunigt den Weg, aber die Richtung geben Sie vor.

0:19 Sie werden merken, dass die Abläufe denen ohne KI ähnlich sind — nur dass jeder Schritt schneller geht und dass Prüfen dadurch wichtiger wird, nicht unwichtiger. Genau darum endet dieses Modul mit einem Kapitel über Abnahme.

Arbeiten mit Pi

0:32 Acht Kapitel, die einer natürlichen Reihenfolge folgen: erst verstehen, dann verändern, dann prüfen. Am Anfang steht das fremde Repository, am Ende die Abnahme der eigenen Änderung. Zwischendurch die drei Aufgabentypen, die den Entwickleralltag ausmachen — Feature, Bug, Refactoring. Ein Hinweis vorweg: Über den gezielten Umgang mit Kontext sprechen wir hier nur so weit, wie es die Arbeit braucht. Das eigentliche Kontext-Handwerk kommt im nächsten Modul.

1:00 Hier geht es um die Abläufe, in die es sich später einbettet. Vier Ziele. Erstens: von der ersten Minute im fremden Repository zu einer belastbaren Aussage kommen — belastbar heißt, mit einem Kommando bestätigt. Zweitens Kontext gezielt geben, statt den Agenten suchen zu lassen. Drittens Aufgaben so zerlegen, dass jeder Schritt einzeln prüfbar bleibt; das ist die wirksamste Maßnahme gegen große, unübersichtliche Änderungen.

1:26 Und viertens jede Änderung gegen Diff, Tests und Build halten. Diese vier Punkte klingen selbstverständlich — in der Praxis wird gerade der letzte unter Zeitdruck als Erstes geopfert.

Bestehende Projekte mit Pi erschließen

1:38 Beginnen wir mit der Situation, in der ein Agent seinen deutlichsten Vorteil ausspielt: Sie stehen vor einem Projekt, das Sie nicht kennen. Und der erste Prompt sollte eine Frage sein, kein Auftrag. Erschließen heißt: Sie starten den Agenten im Projekt und lassen ihn mit seinen Lese- und Suchwerkzeugen ein Bild erarbeiten — Aufbau, Einstiegspunkte, Build- und Testbefehle.

2:00 Denken Sie an einen neuen Kollegen, der am ersten Tag nicht sofort Code schreibt, sondern erst einmal liest und Fragen stellt. Genau diese Rolle übernimmt der Agent hier, nur schneller. Das Angenehme daran: In dieser Phase verändert er nichts. Sie können also mit der engsten Werkzeugliste arbeiten und trotzdem viel gewinnen.

2:19 Vier Gründe, warum sich das lohnt. Der Agent liest schneller quer, als Sie Dateien öffnen können — das ist kein Intelligenzargument, sondern Geschwindigkeit. Fragen nach Build und Tests liefern Aussagen, die sich in Sekunden überprüfen lassen; ideal für den Vertrauensaufbau. Die beobachteten Werkzeugaufrufe zeigen Ihnen außerdem, wo der Agent nachgesehen hat — Sie sehen also, worauf seine Antwort beruht.

2:43 Und schließlich ist dieser Überblick die Grundlage für alles Weitere: Ohne Projektbild sind alle folgenden Aufträge Raten. Der rote Faden dieser Schritte ist der Weg von der Vermutung zum Beleg. Sie starten im Projekt und entscheiden bewusst über das Projektvertrauen — Sie wissen inzwischen, was das bedeutet und was nicht.

3:03 Dann der Überblick, dann die Frage nach den Kommandos, die Sie sofort ausführen. Zwei Kerndateien schieben Sie ausdrücklich nach, weil gezielt besser ist als vollständig. Und der fünfte Schritt ist der, der aus einer Sitzung dauerhaften Wert macht: das Ergebnis in den Projektanweisungen festhalten. Dazu kommt Modul sechs.

3:22 Worauf es hier ankommt, sind drei verschiedene Arten von Eingaben. Die erste ist eine offene Frage — bewusst breit, um ein Bild zu bekommen. Die zweite ist ein Ausrufezeichen-Befehl: Damit führen Sie selbst eine Shell-Zeile aus, ohne den Agenten dazwischenzuschalten. Und die dritte legt mit dem At-Zeichen zwei konkrete Dateien in den Auftrag. Beachten Sie den Rhythmus: fragen, prüfen, präzisieren.

3:46 Das ist genau die Reihenfolge, die verhindert, dass Sie auf einer falschen Annahme aufbauen — und sie kostet keine zwei Minuten.

Dateien und Verzeichnisse als Kontext verwenden

3:54 Jetzt zum wichtigsten Handgriff im Alltag. Es gibt eine einfache Regel: Zeigen ist besser als beschreiben. Und dafür gibt es genau ein Zeichen, das Sie sich merken müssen. Mit dem At-Zeichen nehmen Sie Dateien in den Prompt auf — auf der Kommandozeile genauso wie im Editor. Zusätzlich lädt Pi Kontextdateien von selbst: eine Anweisungsdatei aus dem persönlichen Verzeichnis, aus übergeordneten Verzeichnissen und aus dem Arbeitsverzeichnis.

4:21 Auch die von anderen Werkzeugen bekannte Variante wird gelesen — bestehende Dateien passen also weiter. Das Bild: Sie legen dem Kollegen die richtigen Unterlagen auf den Tisch, statt ihm den Aktenschrank zu zeigen. Zwei präzise Dateien wirken stärker als zehn ungefähre. Genannte Dateien sind garantiert im Kontext — gesuchte nur wahrscheinlich. Das ist der ganze Punkt.

4:44 Zwei präzise Dateien schlagen deshalb ein breites Angebot, und sie kosten weniger Kontextbudget. Projektregeln aus der Anweisungsdatei gelten ohnehin in jeder Sitzung, Sie müssen sie nicht wiederholen. Und wer wirklich am Verhalten drehen will, kann den Systemprompt ersetzen oder ergänzen — mit einer eigenen Datei im Projekt.

5:03 Das ist ein starker Hebel, den man sparsam einsetzen sollte, aber es ist gut, ihn zu kennen. Die Logik dieser Tabelle ist eine Frage nach der Haltbarkeit. Was für jede Änderung gilt, gehört in die Projektanweisungen. Was nur für Sie persönlich gilt, gehört in die globale Variante — Ihr Team interessiert Ihr Antwortstil nicht.

5:23 Was nur für diese eine Aufgabe zählt, kommt per At-Zeichen in den Prompt und verschwindet danach wieder. Und wer das Rollenverhalten selbst verändern will, nimmt die Systemprompt-Datei. Die Regel dahinter: Je dauerhafter eine Regel gilt, desto weiter oben gehört sie hin — und desto seltener müssen Sie sie sagen.

Terminalbefehle durch den Agenten ausführen lassen

5:42 Jetzt zur Shell. Wir haben im Sicherheitsmodul über ihre Risiken gesprochen — hier geht es um ihren Nutzen. Und der ist größer, als man zunächst denkt, weil Ausführen und Überprüfen dasselbe sind. Über das Shell-Werkzeug führt der Agent Kommandos im Projekt aus — Tests, Linter, Build, Versionskontrolle. Sie selbst nutzen im Editor das Ausrufezeichen für denselben Zweck.

6:05 Beides läuft mit den Rechten des Prozesses, das wissen Sie inzwischen. Der entscheidende Gedanke: Ein Agent, der Befehle ausführen kann, kann seine eigenen Behauptungen überprüfen. Das ist ein qualitativer Unterschied. Ohne Shell erzählt er Ihnen, wie das Projekt vermutlich funktioniert. Mit Shell zeigt er es — und Sie sehen die Ausgabe selbst.

6:27 Vier Punkte. Der Agent kann seine Aussagen belegen lassen, statt sie zu behaupten. Fehlermeldungen kommen direkt in den Kontext zurück, was die Fehlersuche enorm beschleunigt. Wiederholbare Schritte gehören ins Projekt und nicht in den Prompt — ein Skript oder ein Prüfbefehl ist wertvoller als eine gut formulierte Anweisung.

6:45 Und die Rechte dafür haben Sie in Modul drei bewusst gesetzt; falls Sie mit der engen Werkzeugliste arbeiten, merken Sie hier genau, warum Sie sie an dieser Stelle wieder öffnen wollen. Diese Übung ist kurz und ausgesprochen lehrreich. Nehmen Sie drei Aussagen des Agenten über Ihr Projekt und übersetzen Sie jede in ein Kommando, das sie bestätigt oder widerlegt.

7:06 Das Erfolgskriterium verlangt außerdem, abweichende Aussagen zu korrigieren. Erfahrungsgemäß sind zwei von drei Aussagen präzise und eine ist eine plausible Vereinfachung — und genau diese eine hätte man ohne Prüfung übernommen. Wenn Sie eine Gewohnheit aus diesem Seminar mitnehmen, nehmen Sie diese: erst belegen, dann bauen.

Code analysieren und Zusammenhänge verstehen

7:26 Jetzt kommt der Bereich mit dem besten Aufwand-Nutzen-Verhältnis im ganzen Werkzeug: Analyse. Sie verändert nichts, sie kostet wenig — und sie beantwortet genau die Fragen, für die man sonst Stunden im Editor verbringt. Analyse heißt hier: Aufrufwege, Datenflüsse und Abhängigkeiten rekonstruieren. Der Agent nutzt dafür Suche und Dateisuche über den Baum, liest gezielt und erklärt die Zusammenhänge in eigenen Worten.

7:51 Das ist wie ein Kollege, der Ihnen an der Kaffeemaschine erklärt, wie eine Anfrage durch das System läuft — nur dass Sie sofort nach Datei und Zeilennummer fragen können. Und weil dabei nichts verändert wird, ist das der ideale Einsatzfall für den Lesemodus aus dem Sicherheitsmodul. Suchen über viele Dateien ist maschinell schneller und vollständiger als manuell — das ist unstrittig.

8:14 Erklärungen deckenzudem eigene Wissenslücken auf: Man merkt beim Zuhören, welche Annahme man selbst falsch hatte. Wichtig ist die dritte Regel: Belege einfordern. Datei und Zeilennummer statt „irgendwo im Service-Layer". Und der vierte Punkt macht dieses Kapitel so bequem — Analyse verändert nichts. Sie können also mit minimalen Rechten arbeiten und trotzdem den größten Teil des Verständnisgewinns einfahren.

8:40 Der Zweck dieser fünf Schritte ist kalibriertes Vertrauen. Sie benennen einen Startpunkt — eine Route, ein Kommando, ein Ereignis. Dann lassen Sie den Weg bis zur Datenschicht erklären. Der dritte Schritt ist der wichtigste: je Schritt einen Beleg mit Datei und Zeile. Und dann lesen Sie zwei dieser Belege selbst nach. Nicht alle — zwei genügen, um ein Gefühl für die Zuverlässigkeit zu bekommen.

9:03 Zum Schluss sichern Sie das Ergebnis als Notiz im Projekt, damit die nächste Person nicht wieder von vorn anfängt.

Features strukturiert entwickeln

9:11 Jetzt wird verändert. Und hier zeigt sich, dass Pi keinen Planungsmodus hat — was zunächst wie ein Nachteil klingt, aber zu einer klaren Arbeitsweise zwingt: kleine Schritte mit Abnahmekriterium. Feature-Arbeit funktioniert in Schritten, die je ein Abnahmekriterium haben: Anforderung formulieren, Änderung auf wenige Dateien begrenzen, Test oder Kommando als Nachweis — dann der nächste Schritt.

9:34 Denken Sie an einen Umbau im Haus: Sie reißen nicht alle Wände gleichzeitig auf, sondern arbeiten raumweise, damit man abends noch schlafen kann. Genau diese Bewohnbarkeit zwischen den Schritten ist der Punkt. Nach jedem Schritt existiert ein Zustand, den Sie committen und im Notfall behalten können. Kleine Diffs sind reviewbar, große sind es nicht — das ist die nüchternste Begründung für diese Arbeitsweise, und sie gilt unabhängig von KI.

10:00 Nach jedem Schritt existiert ein lauffähiger Zustand, was Fehler lokal hält und den Rückweg offen lässt. Und die Abnahmekriterien im Prompt ersetzen den fehlenden Planungsmodus: Sie schreiben ohnehin auf, woran „fertig" erkennbar ist. Ich finde diesen Zwang produktiv — er macht sichtbar, wie oft Aufträge im Alltag ohne jedes Kriterium vergeben werden.

10:21 Der rote Faden: Ziel und Nachweis zuerst, Code danach. Sie formulieren Ziel und Abnahmekriterium in je einem Satz — wenn das nicht gelingt, ist die Aufgabe noch nicht verstanden. Dann benennen Sie die betroffenen Dateien ausdrücklich. Die erste Änderung prüfen Sie als Diff, bevor irgendetwas weiterläuft. Dann laufen die Tests, und Abweichungen gehen zurück an den Agenten. Und der letzte Schritt ist eine Disziplinfrage: committen, bevor der nächste Schritt beginnt.

10:49 Wenn dieser Ablauf sich wiederholt, wird später ein Skill daraus. Diese vier Fehler kosten regelmäßig einen halben Tag. „Baue das Feature" ohne Abnahmekriterium — niemand kann prüfen, ob es stimmt, auch Sie nicht. Zehn Dateien in einem Durchgang ändern lassen: Der Diff wird unlesbar, und damit entfällt Ihre wichtigste Kontrolle.

11:09 Zwischenstände nicht committen und dadurch den Rückweg verlieren — besonders bitter, wenn Schritt vier den funktionierenden Schritt zwei kaputt macht. Und Tests erst am Ende laufen lassen, wenn niemand mehr weiß, welche der zwanzig Änderungen die Ursache war.

Bugs systematisch untersuchen

11:24 Fehlersuche ist die Disziplin, in der ein Agent glänzen oder gründlich in die Irre führen kann. Der Unterschied liegt in der Reihenfolge — und die ist dieselbe wie ohne KI. Erst der reproduzierbare Fall, dann die Ursache. Fehlersuche mit Pi folgt der klassischen Ordnung: reproduzieren, eingrenzen, Ursache belegen, Korrektur mit Test absichern.

11:46 Neu ist nur die Arbeitsteilung — der Agent liefert Hypothesen und führt die Kommandos aus, Sie entscheiden, welche Hypothese verfolgt wird. Ein Bild: Der Agent ist der Assistent, der schnell Messungen macht. Er ist nicht der Arzt, der die Diagnose verantwortet. Wer diese Rollen vertauscht, bekommt plausible Erklärungen für Fehler, die es gar nicht gibt.

12:08 Ein reproduzierbarer Fall macht jede Hypothese prüfbar — ohne ihn diskutieren Sie Meinungen. Hier lohnt sich die höhere Denktiefe wirklich, weil verschachtelte Ursachen abgewogen werden müssen; das ist ein anderer Fall als das Umbenennen von Variablen. Praktisch angenehm: Der Agent liest Logs und Stacktraces vollständig, nicht nur die erste Zeile — genau die Stelle, an der man selbst gern abkürzt.

12:31 Und der letzte Punkt ist unverhandelbar: Ein Test, der vorher rot war, ist der einzige belastbare Beweis, dass der Fehler weg ist. Der Zweck dieser Schrittfolge ist, die Reihenfolge gegen Ungeduld zu verteidigen. Erst reproduzieren und das Kommando festhalten. Dann erwartetes gegen tatsächliches Verhalten notieren — dieser Satz klingt trivial und verhindert die meisten Irrwege.

12:54 Zwei bis drei Hypothesen bilden und einzeln prüfen, nicht alle gleichzeitig ändern. Die Ursache mit Datei und Zeile belegen lassen. Und dann der Schritt, den man unter Zeitdruck streicht: erst den Test schreiben, der den Fehler zeigt, dann korrigieren. Danach ist der Beweis automatisch da.

Refactoring mit einem Coding Agent durchführen

13:12 Refactoring ist die Aufgabe, bei der Agenten am meisten Zeit sparen — und am meisten Schaden anrichten können. Der Grund ist derselbe: Sie ändern viele Stellen konsequent. Refactoring ändert die Struktur, nicht das Verhalten. Mit einem Agenten heißt das: vorher ein grünes Testfeld, dann mechanische Umbauten in kleinen Schritten, nach jedem Schritt dieselben Tests.

13:34 Der Vergleich: Sie stellen Möbel um, ohne die Wohnung anders zu nutzen. Wenn hinterher der Kühlschrank im Schlafzimmer steht, war es kein Refactoring mehr. Und weil ein Agent konsequent ist, verteilt er auch einen Denkfehler konsequent über dreißig Dateien. Deshalb ist das Sicherheitsnetz hier keine Formalität. Der Agent ändert viele Stellen konsistent — auch die falschen. Diesen Satz sollten Sie sich merken, er ist die ganze Begründung für dieses Kapitel.

14:01 Grüne Tests vor dem Umbau sind der Vergleichspunkt danach; ohne sie ist der Erfolg Behauptung. Ein Schritt je Commit hält den Rückweg offen, was bei Massenänderungen doppelt zählt. Und die vierte Regel ist die wichtigste: Struktur- und Verhaltensänderung nie im selben Schritt. Sonst können Sie nicht mehr unterscheiden, ob der neue Fehler vom Umbau oder von der Funktion kommt.

14:23 In dieser Übung bauen Sie um — aber mit Netz. Die Kriterien sind bewusst mechanisch: Tests vorher grün, mindestens zwei Commits, Tests danach unverändert grün. Wer noch keine belastbare Testabdeckung hat, nimmt die Fallback-Variante und begrenzt den Umbau auf eine einzige Datei. Das ist keine Ausrede, sondern gutes Handwerk: Ohne Netz kleiner Radius.

14:45 Und wenn Sie beim Aufräumen merken, dass Ihnen Tests fehlen — dann ist das das eigentliche Ergebnis dieser Übung.

Ergebnisse prüfen statt KI Code blind zu übernehmen

14:52 Das letzte Kapitel ist das, das den Unterschied zwischen produktivem Einsatz und technischer Schuld macht. Es geht um die Abnahme — und darum, dass sie kein Nachgedanke sein darf. Prüfen heißt: Diff lesen, Tests laufen lassen, Annahmen hinterfragen. Pi bringt dafür keine eingebaute Review-Instanz mit — die Qualitätssicherung bleibt bei Ihnen und bei den Werkzeugen des Projekts.

15:15 Das ist konsequent zur Philosophie des kleinen Kerns, aber es heißt eben auch: Es gibt keine Instanz, die Sie rettet. Der ehrlichste Satz zu diesem Thema lautet: Sprachmodelle irren plausibel. Eine gut formulierte Erklärung ist kein Qualitätssignal — sie ist nur eine gut formulierte Erklärung. Vier Punkte. Formulierung ist kein Qualitätsmerkmal, das gilt für Menschen wie für Modelle.

15:39 Ein Diff zeigt, was tatsächlich passiert ist, nicht was behauptet wurde — deshalb lesen, nicht überfliegen. Tests, Linter und Typprüfung sind die objektiven Kriterien, die Sie ohnehin haben. Und ein praktischer Tipp: Pi kann eine Sitzung exportieren und teilen. Das ist nützlich, wenn Sie im Review erklären wollen, wie eine Änderung entstanden ist — Nachvollziehbarkeit statt „die KI hat das gemacht".

16:05 Der rote Faden dieser Abnahme ist: vom Mechanischen zum Fachlichen. Zuerst den Diff vollständig lesen — ausdrücklich auch die Dateien, die Sie nicht erwartet haben; dort stecken die Überraschungen. Dann Tests, Linter, Typprüfung. Dann eine bewusste Entscheidung über neue Abhängigkeiten und generierte Dateien, weil beides gern unbemerkt mitreist. Zwei fachliche Annahmen im Code gegenlesen.

16:29 Und erst dann committen, mit einer eigenen Commit-Nachricht. Die Faustregel dazu: Was Sie nicht erklären können, sollten Sie nicht mergen.

Der Agent arbeitet, Sie verantworten

16:38 Drei Dinge nehmen wir mit. Kontext gezielt geben, Aufgaben klein halten, Nachweise einfordern — das sind die drei Handgriffe, die den Alltag tragen. Feature, Bug und Refactoring haben je eine feste Schrittfolge, und diese Reihenfolge verteidigt man am besten gegen sich selbst. Und Prüfen ist Teil des Workflows, nicht die Kür am Ende.

16:57 Im nächsten Modul schauen wir uns genauer an, was eigentlich im Kontextfenster passiert — und warum guter Kontext oft mehr bringt als ein längerer Prompt.