Praxisprojekt

Praxisprojekt — der persönliche Coding Agent

0:00 Elf Module Theorie und Handwerk liegen hinter uns. Jetzt kommt der Teil, der darüber entscheidet, ob davon etwas bleibt. Am Ende dieses Moduls steht kein Wissen, sondern eine eingerichtete Umgebung: eine Projektanweisungsdatei, ein Skill, zwei Vorlagen, ein Rechteprofil und ein begründeter Werkzeugkasten — an einem echten Projekt erarbeitet und an einer echten Aufgabe geprüft.

0:22 Das ist ein Werkstattmodul. Jedes Kapitel endet in einem Artefakt, das Sie mitnehmen. Und der letzte Schritt sorgt dafür, dass die Arbeit auch im nächsten Projekt trägt.

Alles zusammenführen

0:33 Acht Kapitel, und sie folgen der Reihenfolge, in der man ein Projekt tatsächlich einrichtet: analysieren, Regeln ableiten, aufschreiben, Bausteine bauen, ausprobieren, aufräumen. Ein Hinweis zur Erwartung: Wir bauen hier nicht das perfekte Setup. Wir bauen ein Setup, das an einer echten Aufgabe geprüft wurde — und das ist deutlich mehr wert.

0:54 Was dabei fehlt, notieren Sie; genau diese Notiz ist die Grundlage für das Schlusskapitel. Nehmen Sie deshalb ein Projekt, mit dem Sie tatsächlich arbeiten. Vier Punkte. Erstens: ein echtes Projekt von der Analyse bis zum eingerichteten Agenten — kein Beispielprojekt, sondern Ihres. Zweitens die Artefakte, die dabei entstehen und die Sie am Ende in der Hand haben. Drittens ein realistischer Durchlauf: eine Aufgabe mit Nachweis, kein Spielzeugbeispiel.

1:22 Und viertens die Übertragbarkeit — die Frage, was projektspezifisch ist und was Sie ins nächste Projekt mitnehmen. Der letzte Punkt entscheidet darüber, ob dieses Seminar in einem Monat noch Wirkung hat.

Ein bestehendes Softwareprojekt analysieren

1:35 Fangen wir mit dem an, was wir in Modul vier geübt haben — jetzt aber mit dem Ziel, daraus Konfiguration abzuleiten. Und bewusst lesend, denn Rechte kommen erst später. Die Analyse liefert die Grundlage für alle späteren Bausteine: Zweck, Struktur, Einstiegspunkte, Build- und Testbefehle, offene Baustellen. Am besten lesend, mit den vier ungefährlichen Werkzeugen. Der Vergleich: Der Handwerker begeht die Baustelle, bevor er Material bestellt.

2:03 Wer diesen Schritt überspringt, richtet den Agenten nach Vermutungen ein — und merkt es erst, wenn die erste Regel nicht greift. Die halbe Stunde hier ersetzt später mehrere Korrekturrunden. Ohne Projektbild sind Regeln geraten statt begründet — der Kern dieses Kapitels. Der Lesemodus heißt: keine Nebenwirkung während der Erkundung, Sie können also frei herumfragen.

2:26 Belege mit Datei und Zeile machen die Analyse überprüfbar; nehmen Sie diese Belegpflicht ernst, sie unterscheidet Analyse von Vermutung. Und ein praktischer Nebeneffekt: Die Ergebnisse dieser Analyse sind schon die Rohfassung Ihrer Projektanweisungen. Sie schreiben also nicht zweimal, sondern ordnen im nächsten Kapitel nur um.

2:46 Erste Übung, und sie hat ein strenges Kriterium: Zu jeder Aussage steht Datei oder Kommando als Beleg. Sie erfassen Zweck, Struktur, Einstiegspunkte sowie Build- und Testbefehl. Klingt nach Fleißarbeit, ist aber in zwanzig Minuten erledigt — und Sie haben danach ein Dokument, das auch Ihren nächsten neuen Kollegen freut.

3:05 Wenn der Agent bei einer Aussage keinen Beleg liefern kann, ist das der interessanteste Fund des Tages. Genau dort liegt nämlich das implizite Wissen Ihres Projekts.

Projektregeln und Kontext definieren

3:16 Jetzt machen wir aus Beobachtung Vorgabe. Und wir halten uns an einen Maßstab, den Sie aus Modul sechs kennen: Nur aufschreiben, was prüfbar ist. Regeln entstehen aus dem, was im Projekt tatsächlich gilt: Prüfbefehl, Ordnerkonventionen, erlaubte Bibliotheken, Freigabepflichten. Und der Kontext entscheidet, welche davon dauerhaft gelten und welche pro Aufgabe mitgegeben werden.

3:40 Der Vergleich: Sie schreiben die Hausordnung aus dem, was ohnehin gelebt wird — nicht aus dem, was Sie sich wünschen. Regeln, die Ihr Team nicht befolgt, befolgt auch der Agent nicht dauerhaft; sie erzeugen nur Reibung im Review. Dauerhaftes gehört in Dateien, Aufgabenbezogenes in den Prompt — die Trennung aus Modul fünf. Jede Regel braucht eine prüfbare Formulierung, sonst ist sie Dekoration.

4:04 In Monorepos verteilen Sie Regeln auf Wurzel und Pakete, damit sie nah am Code liegen. Und der vierte Punkt ist die Sparsamkeitsregel: Was nicht gilt, wird nicht geschrieben. Ballast kostet Kontext in jeder Sitzung — bei einer Datei, die jeder Aufruf mitschickt, ist das ein dauerhafter Preis. Der rote Faden: bestimmen, notieren, prüfen, aussortieren, ordnen. Sie bestimmen den Prüfbefehl und führen ihn aus — das ist die wichtigste Einzelinformation.

4:33 Dann notieren Sie drei Struktur- und drei Stilregeln, nicht mehr. Bei jeder Regel stellen Sie die Testfrage: Wie merkt man den Verstoß? Nicht prüfbare Regeln streichen oder umformulieren. Und sortieren Sie nach Wichtigkeit, nicht nach Entstehung. Die Fußnote nennt den Maßstab: Fünf gute Regeln wirken mehr als zwanzig gut gemeinte.

Individuelle AGENTS.md erstellen

4:55 Jetzt entsteht das erste Artefakt. Eine Seite, die trägt — nicht mehr. Und der Prüfbefehl gehört an den Anfang, weil er am häufigsten gebraucht wird. Die Projektanweisungsdatei bündelt die Regeln aus dem vorigen Kapitel in einer knappen, gruppierten Form — Befehle, Struktur, Standards, Qualität. Sie liegt im Projekt, damit Pi sie in jeder Sitzung automatisch lädt.

5:18 Denken Sie an das Blatt an der Maschine, von dem wir bei den Skills gesprochen haben — nur dass dieses Blatt immer sichtbar ist und nicht erst bei Bedarf. Deshalb die Gruppierung: Was man täglich braucht, gehört nach oben. Gruppierung macht die Datei lesbar und wartbar; ohne sie wird sie in drei Monaten zur Halde. Der Prüfbefehl gehört an den Anfang.

5:39 Persönliches bleibt in der globalen Variante, damit Ihr Team im Review nicht über Ihren Antwortstil diskutiert. Und das Ziel ist eine Bildschirmseite, nicht ein Handbuch — diese Grenze ist eine gute Sollbruchstelle. Wenn Sie sie überschreiten, prüfen Sie, was in einen Skill wandern kann. Ein seltener Ablauf gehört nicht in eine Datei, die jeder Aufruf bezahlt.

6:01 Zweite Übung, zweites Artefakt. Sie schreiben die Datei, gruppiert nach Themen — und belegen in einer neuen Sitzung an zwei Beispielen, dass die Regeln greifen. Dieser Nachweis ist der eigentliche Inhalt der Aufgabe. Wer mag, nimmt die Stretch-Variante und lässt eine Regel bewusst verletzen, um die Reaktion zu sehen. Das ist erstaunlich lehrreich: Sie merken, welche Ihrer Regeln wirklich verstanden werden und welche zu abstrakt formuliert sind.

Geeignete Skills auswählen oder entwickeln

6:27 Drittes Artefakt: ein Skill. Und ich sage bewusst „ein" — lieber einer, der tatsächlich geladen wird, als drei Entwürfe, die im Ordner liegen. Sie halten genau den Ablauf als Skill fest, der in Ihrem Projekt am häufigsten wiederkehrt — mit gültigen Kopfdaten, Auslösewörtern in der Beschreibung und Ablauf samt Nachweis im Text.

6:48 Die Auswahl folgt der Häufigkeit, nicht der Eleganz. Der Vergleich: Sie bauen die Vorrichtung für das Werkstück, das ständig auf Ihrer Werkbank liegt — nicht für das interessanteste. Interessante Aufgaben macht man ohnehin gern selbst; die langweiligen wiederkehrenden sind die, bei denen ein Skill Zeit spart. Häufigkeit entscheidet, nicht Eleganz — das ist der Auswahlmaßstab.

7:11 Die Beschreibung ist der Auslöser und braucht echte Formulierungen aus Ihrem Alltag; das haben wir in Modul acht ausführlich behandelt. Die Ablage im Projekt macht den Skill zum Teamgut, statt zu Ihrem privaten Werkzeug. Und der letzte Satz ist mir wichtig: Ein getesteter Skill ist mehr wert als drei ungetestete. Drei ungetestete Skills mit überlappenden Beschreibungen sind sogar schlechter als keiner.

7:35 Dritte Übung mit einem anspruchsvollen Kriterium: Der Skill wird ohne ausdrücklichen Skill-Aufruf geladen — allein durch eine alltägliche Formulierung. Damit prüfen Sie Ihre Beschreibung unter realistischen Bedingungen. Und er muss den Ablauf vollständig durchführen, nicht nur beginnen. Wenn das nicht klappt, liegt es in neun von zehn Fällen an der Beschreibung.

7:55 Probieren Sie dann die Formulierung aus, die Sie einem neuen Kollegen gegenüber verwenden würden — genau die gehört in die Beschreibung.

Wiederkehrende Aufgaben als Templates abbilden

8:03 Viertes Artefakt: zwei Vorlagen. Review und Fehlersuche reichen als Start — sie sind die beiden Abläufe, die in jedem Projekt vorkommen. Prompt-Vorlagen halten die wiederkehrenden Formulierungen Ihres Projekts fest, typischerweise Review und Fehlersuche — mit Parametern für Fokus, Datei oder Testbefehl und einem Standardwert je Parameter.

8:24 Der Aufwand ist minimal: zwei Textdateien. Und weil sie reiner Text sind, brauchen Sie niemanden um Erlaubnis zu fragen und riskieren nichts. Deshalb stehen sie hier als vierter Schritt: Sie sind das Artefakt mit dem besten Verhältnis von Aufwand zu Wirkung im ganzen Modul. Templates sind Text: kein Risiko, sofort nutzbar.

8:43 Standardwerte machen den Aufruf ohne Argumente sinnvoll — mein wichtigstes Kriterium, weil eine Vorlage, die Argumente erzwingt, im Alltag ungenutzt bleibt. Der Argumenthinweis erklärt die Bedienung in der Autovervollständigung, also genau dort, wo Sie ihn brauchen. Und achten Sie auf Doppelungen zur Anweisungsdatei: Was dort steht, gehört nicht in die Vorlage. Zwei Wahrheiten laufen irgendwann auseinander.

9:09 Vierte Übung. Zwei Vorlagen im Projekt, mit und ohne Argument aufrufbar, je ein brauchbares Ergebnis am echten Projekt. Nehmen Sie ausdrücklich Ihr Projekt, nicht ein Beispiel — nur dann merken Sie, ob die Parameter richtig geschnitten sind. Erfahrungsgemäß ändern Sie nach dem ersten echten Einsatz noch zwei Formulierungen, und danach bleiben die Vorlagen monatelang unverändert.

9:32 Genau dieser Moment, in dem eine Vorlage „fertig" wird, ist ein gutes Zeichen.

Erweiterungen sinnvoll integrieren

9:37 Fünftes Artefakt, und es darf auch eine Ablehnung sein. Wir wenden das Raster aus Modul sieben an: so wenig wie möglich, so viel wie nötig. Integration heißt: den konkreten Bedarf benennen, einen Kandidaten projektlokal erproben, Rechte und Verhalten sichten — und dann entscheiden. Übernehmen, projektlokal halten oder entfernen. Alle drei Ergebnisse sind legitim.

10:00 Der Vergleich: Sie nehmen ein Werkzeug zur Probe mit auf die Baustelle, statt es gleich für den ganzen Betrieb zu bestellen. Und wenn es nach einer Woche in der Tasche geblieben ist, geben Sie es zurück, statt es mitzuschleppen. Bedarf vor Angebot: erst die Lücke, dann das Paket — das schützt vor der langen Liste interessanter Erweiterungen.

10:21 Jede läuft mit den Rechten des Prozesses; der Satz aus Modul drei gilt bis zum Ende dieses Seminars. Die Verwaltungsbefehle für Auflisten und Entfernen gehören zur Einführung dazu, nicht erst zum Aufräumen. Und eine dokumentierte Ablehnung ist ein gutes Ergebnis — sie beantwortet die Frage für das ganze Team und muss nicht in drei Monaten neu diskutiert werden.

10:42 Fünfte Übung. Eine Notiz im Projekt nennt je Erweiterung Zweck, Rechte und Entscheidung — und mindestens eine Erweiterung ist begründet abgelehnt. Diese Notiz ist kein Papierkram: Sie ist die einzige Chance, in einem halben Jahr noch zu wissen, warum etwas installiert ist und warum etwas anderes nicht. Und sie ist das Dokument, das Sie einem Sicherheitsverantwortlichen vorlegen können, wenn die Frage kommt, was Ihr Entwicklungswerkzeug eigentlich alles darf.

Einen realistischen Development Workflow durchführen

11:09 Jetzt der Höhepunkt des Moduls: der Durchlauf. Alles, was Sie eingerichtet haben, kommt an einer echten Aufgabe zusammen — und zeigt, wo noch etwas fehlt. Der Durchlauf führt Bausteine und Handwerk zusammen: eine echte Aufgabe im Projekt — Feature oder Bugfix — mit Kontextauswahl, Zerlegung, Nachweis je Schritt und Abnahme über Diff und Tests.

11:31 Der Vergleich: die Probefahrt nach der Inspektion. Sie diskutieren nicht mehr über die Einstellung, Sie fahren. Und alles, was dabei klappert, notieren Sie — genau dafür ist eine Probefahrt da. Nehmen Sie eine Aufgabe, die Sie ohnehin erledigen müssen; dann ist das Ergebnis echter Code. Erst im Durchlauf zeigt sich, ob Regeln und Skills tragen — vorher ist alles Vermutung.

11:55 Fehlende Bausteine fallen genau dort auf, wo sie fehlen, und das ist die präziseste Diagnose, die Sie bekommen können. Nachweise machen den Erfolg unstrittig; Sie müssen nicht argumentieren, dass es funktioniert. Und das Ergebnis ist echter Code, keine Übung — was für die Motivation im Seminar mehr bringt als jedes konstruierte Beispiel.

12:15 Der rote Faden fasst vier Module zusammen. Aufgabe und Abnahmekriterium in je einem Satz — aus Modul vier. Kontext gezielt setzen und Vorlage oder Skill nutzen — aus den Modulen fünf, acht und neun. In Schritten arbeiten mit Nachweis je Schritt. Diff vollständig lesen und Annahmen gegenlesen. Und der fünfte Schritt ist der, der zum letzten Kapitel führt: notieren, was in der Einrichtung gefehlt hat.

12:41 Diese Notiz ist die Arbeitsgrundlage für das Aufräumen. Sechste Übung, und die mit dem konkretesten Ergebnis: Die Änderung ist in mindestens zwei Commits erfolgt, Tests und Prüfbefehl sind grün, und der Diff ist gelesen und erklärbar. Das letzte Kriterium ist das anspruchsvollste — erklärbar heißt, Sie könnten die Änderung im Review vertreten, ohne auf den Agenten zu verweisen.

13:04 Das ist der Maßstab, den ich Ihnen für die tägliche Arbeit mitgeben möchte. Was Sie nicht erklären können, sollten Sie nicht mergen.

Die eigene Pi Konfiguration für zukünftige Projekte optimieren

13:12 Zum Abschluss sortieren wir. Was bleibt im Projekt, und was kommt mit ins nächste? Diese Trennung entscheidet darüber, ob die Arbeit dieses Moduls einmalig war oder dauerhaft wirkt. Am Schluss wird sortiert: Was ist projektspezifisch und bleibt im Repository — und was ist dauerhaft persönlich und wandert in Ihr Pi-Verzeichnis: Einstellungen, globale Skills, Vorlagen, Modellstandards.

13:36 Der Vergleich: Nach dem Auftrag räumen Sie die Werkstatt auf und packen die eigene Tasche. Das Baustellenmaterial bleibt, das eigene Werkzeug kommt mit. Wer das nicht trennt, hat beim nächsten Projekt entweder nichts dabei — oder das Falsche. Persönliche Ausstattung soll im nächsten Projekt sofort verfügbar sein, ohne Nachbau. Projektgebundenes gehört ins Repository, damit das Team es bekommt und pflegen kann.

14:01 Ungenutztes wird entfernt, nicht mitgeschleppt — die Aufräumregel aus Modul sieben. Und eine kurze Notiz hält fest, warum etwas so eingerichtet ist; das ist die Version Ihres Wissens, die auch in sechs Monaten noch lesbar ist. Zwei Sätze genügen dafür, aber sie müssen geschrieben werden. Der rote Faden: auflisten, einordnen, übertragen, teilen, gegenprüfen. Sie listen alle entstandenen Artefakte auf — es sind mehr, als man denkt.

14:28 Dann ordnen Sie jedes ein: Projekt, persönlich oder verwerfen. Persönliches überführen Sie und testen es, denn ein globaler Skill, der nur im Projektkontext funktioniert, ist eine Enttäuschung. Projektbezogenes committen Sie und kündigen es im Team an. Und der letzte Schritt ist der ehrlichste: in einem zweiten Projekt gegenprüfen, ob die Basis wirklich trägt.

Ihr persönlicher Coding Agent

14:51 Damit sind wir am Ende. Aus einer Analyse sind Regeln geworden, aus den Regeln eine Projektanweisungsdatei. Skills, Vorlagen und Erweiterungen sind bewusst gewählt, getestet und begründet — auch die abgelehnten. Und der Durchlauf hat die Einrichtung an echter Arbeit geprüft, nicht an einem Beispiel. Was Sie mitnehmen, ist kein fertiges Setup, sondern eine Arbeitsweise: klein anfangen, prüfen, nachschärfen.

15:16 Pi bleibt dabei ein bewusst schlankes Werkzeug — und genau deshalb ist es am Ende Ihres, nicht das des Herstellers.