Praxisprojekt: Vom Auftrag zum Ergebnis

Praxisprojekt: Vom Auftrag zum Ergebnis

0:00 Elf Module lang haben wir Bausteine gesammelt: Kontext bereitstellen, Regeln verankern, planen, delegieren, prüfen, absichern. In diesem letzten Modul setzen wir sie zusammen — an einer einzigen, echten Anforderung, von der ersten Zeile im Ticket bis zum zusammengeführten Ergebnis. Es geht dabei ausdrücklich nicht um ein Lehrbuchbeispiel. Die Anforderung, mit der wir starten, ist so unvollständig, wie Anforderungen im Alltag nun einmal ankommen.

0:27 Genau diese Unvollständigkeit ist der Gegenstand der Übung.

Praxisprojekt — Vom Auftrag zum Ergebnis

0:31 Acht Kapitel, die einem vollständigen Durchlauf folgen: Anforderung schärfen, Kontext analysieren, Regeln vorbereiten, planen, schrittweise delegieren, implementieren und testen, reviewen — und am Ende aus alldem ein eigenes Verfahren ableiten. Das letzte Kapitel ist das wichtigste, denn ein einzelner gelungener Durchlauf ist noch keine Arbeitsweise.

0:51 Die Teilnehmenden arbeiten dabei am eigenen Projekt; unser kanuverleih dient nur als durchgehendes Beispiel.

Eine Anforderung formulieren

0:58 Beginnen wir am Anfang jeder Entwicklungsarbeit: bei dem, was ankommt. Selten ist das eine saubere Spezifikation. Meist sind es zwei, drei Sätze aus einem Ticket, die eine Absicht beschreiben und ein Dutzend Fragen offenlassen. Sehen wir uns so eine Anforderung an — und was sie alles nicht sagt. Ausgangspunkt ist eine fachliche Anforderung, wie sie tatsächlich ankommt — als Satz aus einem Ticket, nicht als fertige Spezifikation.

1:24 Die Lücken darin sind kein Mangel der Übung, sondern ihr eigentlicher Gegenstand. Das ist eine wichtige Feststellung. In Schulungen wird gern mit sauber formulierten Aufgaben gearbeitet, und dann funktioniert alles. Im Alltag ist die Formulierung unvollständig — und die Fähigkeit, das zu erkennen und zu klären, ist die eigentliche Leistung.

1:45 Drei Zeilen aus einem Ticket. Ein Kunde möchte eine Buchung auch dann noch stornieren können, wenn er sie erst gestern abgeschlossen hat. Das klingt klar. Die Fußzeile sagt, was daran wirklich klar ist: Drei Zeilen, mindestens fünf offene Fragen. Genau das ist der Normalfall. Und die Versuchung ist groß, diese drei Zeilen direkt an den Agenten weiterzureichen — er wird auch etwas liefern. Nur eben etwas, das auf fünf ungeprüften Annahmen beruht.

2:13 Vier der offenen Fragen. Ab wann genau ist eine Stornierung möglich — gestern, oder innerhalb von 48 Stunden, oder bis 24 Stunden vor Beginn? Was gilt für bereits bezahlte Buchungen? Wird etwas erstattet, und wenn ja, wie viel? Und was passiert mit Gruppenbuchungen? Jede dieser Fragen hat eine fachliche Antwort, die nicht im Code steht und die kein Modell erraten kann.

2:37 Ein Agent wird sie trotzdem beantworten — plausibel, konsistent und möglicherweise falsch. Für diese Übung brauchen Sie eine echte Anforderung aus Ihrem Projekt. Der Hinweis begründet das: Konstruierte Beispiele haben keine echten Lücken, weil sie beim Erfinden schon vorsortiert wurden. Suchen Sie mindestens fünf offene Punkte und klären Sie sie — oder halten Sie sie als Annahme fest.

3:00 Beides ist erlaubt, nur eines nicht: sie unbeantwortet zu lassen und trotzdem loszulegen. Denn dann beantwortet sie jemand anderes, nämlich der Agent.

Projektkontext analysieren

3:10 Die Anforderung ist geklärt. Bevor irgendetwas geplant wird, muss aber feststehen, worüber überhaupt geplant wird — also wie der Code heute aussieht. Sehen wir uns an, wie diese Erhebung abläuft und woran man erkennt, ob ihr Ergebnis belastbar ist oder nur gut formuliert. Bevor irgendetwas geplant wird, muss der Ist-Zustand feststehen: welche Dateien betroffen sind, wie sie zusammenhängen, welche Tests existieren und wo die riskanten Stellen liegen.

3:37 Diese Erhebung ist der Boden, auf dem der Plan steht. Ist sie ungenau, ist der Plan es auch — und dann fällt es erst in der Umsetzung auf, wenn Schritt drei plötzlich Dateien berührt, von denen in Schritt eins nie die Rede war. Fünf Schritte. Die betroffenen Bereiche erheben lassen, ohne Änderungserlaubnis. Belege in Form von Dateipfaden verlangen. Vorhandene Tests und Lücken benennen lassen.

4:00 Die Annahmen des Agenten prüfen und richtigstellen. Und das Ergebnis schriftlich festhalten. Die Fußzeile ordnet diese Erhebung richtig ein: Sie ist die Grundlage für Plan und Schnitt — nicht der erste Schritt der Umsetzung. Wer sie als Vorarbeit zur Implementierung behandelt, überspringt das Prüfen. Der erste Punkt kennen Sie aus Modul fünf: eine flüssige Beschreibung ohne Belege im Code.

4:25 Der zweite ist die typische Verzerrung — der Agent beschreibt, wie es sein sollte, nicht wie es ist. Gerade in gewachsenen Projekten weicht beides erheblich voneinander ab. Der dritte betrifft den Suchraum, der zu weit gefasst nur Allgemeinplätze liefert. Und der vierte ist ein Fehler, den man erst später bemerkt: die Erhebung nur im Verlauf lassen, statt sie zu sichern.

4:47 Das Erfolgskriterium ist konkret: eine Übersicht der betroffenen Dateien, jede Aussage mit Dateipfad nachprüfbar. Und der Hinweis nennt die Gegenprobe, die zwei Minuten kostet: Öffnen Sie stichprobenartig zwei genannte Dateien. Stimmt die Beschreibung wirklich? In der Mehrzahl der Fälle stimmt sie — und genau deshalb ist die Stichprobe wichtig, denn sie schärft Ihr Gefühl dafür, welchen Aussagen Sie trauen können und welchen nicht.

AGENTS.md vorbereiten

5:13 Jetzt kommt der Schritt, den man im Eifer gern überspringt: die Hausregeln setzen, bevor gearbeitet wird. Denn was hier fehlt, müssen Sie später in jedem einzelnen Auftrag wiederholen — oder es wird stillschweigend anders entschieden. Sehen wir uns an, was für dieses konkrete Vorhaben hineingehört. Vor der Umsetzung stehen die Regeln: Bau- und Testbefehle, Schichtgrenzen, Tabus.

5:36 Was hier fehlt, muss später in jedem einzelnen Auftrag wiederholt werden — oder wird stillschweigend anders entschieden. Der Zeitpunkt ist bewusst gewählt. Regeln, die man nach den ersten Fehlgriffen ergänzt, sind Reparaturen. Regeln, die vorher stehen, sind Leitplanken. Der Aufwand ist derselbe, die Wirkung nicht. Sechs Zeilen, aufgeteilt in Befehle und Grenzen. Der Testbefehl muss vor jeder Meldung grün sein. Die API-Schicht ruft die Fachlogik, nie umgekehrt.

6:06 Migrationen werden nur ergänzt, nie geändert. Und dann die letzte Zeile: Kein Test darf gelöscht oder abgeschwächt werden. Die Fußzeile nennt sie die wichtigste — und das ist sie, weil sie den bequemsten Weg zu grünen Tests verschließt. Ohne diese Zeile ist das erste Erfolgskriterium beliebig erfüllbar. Vier Punkte, zugeschnitten auf dieses Vorhaben. Der Befehl, an dem Erfolg gemessen wird. Die Schichtgrenze, die das Vorhaben berührt — nicht alle Schichtgrenzen, nur die relevante.

6:37 Die Bereiche, die tabu bleiben. Und die Regel, dass Tests nicht angepasst werden. Das ist bewusst wenig. Sie schreiben hier keine vollständige Projektdokumentation, sondern die vier bis sechs Sätze, die für diese Arbeit den Unterschied machen. Der Hinweis liefert den Maßstab für jede Regel, die Sie formulieren: Schreiben Sie sie so, dass eine Verletzung im Diff auffallen würde.

7:02 Das ist ein strenger Test, und er sortiert alles aus, was nur eine Absichtserklärung ist. „Sauberen Code schreiben" fällt durch. „src/api ruft src/buchung, nie umgekehrt" besteht — denn ein Import in die falsche Richtung sieht man. Genau diese Prüfbarkeit macht aus einem Wunsch eine Regel.

Umsetzung mit Plan Mode

7:21 Anforderung geklärt, Ist-Zustand erhoben, Regeln gesetzt. Jetzt entsteht der Plan — und zwar als Text, nicht als Code. Sehen wir uns an, wie aus den ersten drei Schritten eine Folge prüfbarer Zwischenstände wird und woher die Grenzfälle in diesem Plan eigentlich stammen. Aus geschärfter Anforderung und erhobenem Ist-Zustand entsteht ein Plan: eine Folge einzeln umsetzbarer und einzeln prüfbarer Schritte, deren Entwurfsentscheidungen ausgesprochen sind.

7:48 Beachten Sie, dass hier zwei Eingaben zusammenkommen. Die Anforderung sagt, was gewünscht ist. Der Ist-Zustand sagt, wo eingegriffen wird. Ein Plan, der nur auf einer der beiden beruht, ist entweder fachlich richtig und technisch naiv — oder umgekehrt. Fünf Schritte. In den Plan Mode wechseln und die Anforderung übergeben. Den Plan mit benannten Entscheidungen erzeugen lassen. Nach verworfenen Alternativen fragen.

8:14 Die Schritte auf einzeln lauffähige Stände zuschneiden. Und den Plan gezielt nachschärfen, statt ihn neu zu beauftragen. Die Fußzeile nennt den Prüfstein aus Modul vier: Ein Plan, nach dessen Schritten das Projekt jeweils lauffähig bleibt. Das ist die Frage, an der Sie jeden Schritt messen. Vier Schritte für unsere Stornofrist. Konstante herausziehen, konfigurierbar machen, Grenzfälle behandeln, Wert ändern und Dokumentation nachziehen.

8:42 Sehen Sie sich Schritt drei an: bezahlt, Gruppe, Altbuchung. Die Fußzeile sagt, woher diese drei stammen — nicht aus dem Code, sondern aus den offenen Punkten der Anforderung vom Anfang dieses Moduls. Genau so schließt sich der Kreis: Was Sie in Kapitel eins geklärt haben, wird hier zu einem Planschritt. Der Hinweis nennt die Prüffrage, die wir schon kennen und die hier noch einmal zählt: Könnte ich hier aufhören? Gehen Sie damit jeden Schritt Ihres Plans durch.

9:10 Wenn die Antwort bei einem Schritt nein lautet, gehört er mit dem nächsten zusammen — oder er ist anders zu ziehen. Das Ergebnis ist ein Plan, der nicht nur beschreibt, was passieren soll, sondern der sich in Portionen ausliefern lässt.

Aufgaben schrittweise delegieren

9:23 Der Plan steht. Jetzt kommt der Moment, an dem viele die Geduld verlieren und alles auf einmal freigeben. Sehen wir uns an, warum sich das nicht lohnt und wie eine schrittweise Delegation praktisch abläuft — mit einem Commit je Schritt als Rückgrat. Der Plan wird nicht als Ganzes freigegeben, sondern Schritt für Schritt. Jeder Schritt bekommt seinen eigenen Auftrag mit Erfolgskriterium und endet in einem eigenen Commit.

9:48 Das klingt nach Mehraufwand und ist in Wahrheit die Absicherung, die Sie schneller macht. Denn wenn Schritt drei schiefgeht, verlieren Sie Schritt drei — nicht das ganze Vorhaben. Und Sie wissen genau, wo es abgebogen ist, weil Schritt zwei sauber committet danebensteht. Vier Gründe. Jeder Schritt ist einzeln prüfbar und rückholbar. Abweichungen vom Plan fallen sofort auf, nicht am Ende. Das Review bleibt in lesbarer Größe.

10:13 Und ein Abbruch kostet nur den letzten Schritt. Der zweite Punkt ist der, den man unterschätzt: Ein Agent, der bei Schritt zwei anders abbiegt als geplant, baut die Schritte drei und vier auf dieser Abweichung auf. Je später Sie es merken, desto mehr müssen Sie verwerfen. Fünf Schritte je Planschritt. Als eigenständigen Auftrag formulieren. Das Erfolgskriterium ausdrücklich nennen. Die Umsetzung freigeben und das Diff ansehen.

10:40 Die Tests selbst laufen lassen. Committen, dann den nächsten. Die Fußzeile warnt vor der naheliegenden Abkürzung: Wer zwei Schritte zusammenfasst, verliert genau die Prüfbarkeit, für die er geplant hat. Die Versuchung ist real, denn die ersten Schritte laufen meist glatt — und dann wirkt die Sorgfalt übertrieben. Das Erfolgskriterium ist mechanisch prüfbar: je Planschritt ein Commit, nach jedem laufen Build und Tests.

11:06 Der Hinweis nennt die Beobachtung, die für das letzte Kapitel wichtig wird: Notieren Sie, wo der Agent vom Plan abgewichen ist. Diese Abweichungen sind kein Ärgernis, sondern Material. Sie zeigen, an welchen Stellen Ihr Plan ungenau war — und aus dieser Erkenntnis entsteht später Ihr eigenes Verfahren.

Implementierung und Tests

11:25 In der Umsetzung entscheidet sich, ob die ganze Vorarbeit trägt. Und der Prüfstein sind die Tests: Prüfen sie wirklich das gewünschte Verhalten, oder zeichnen sie nach, was gerade entstanden ist? Sehen wir uns an, wie man das sicherstellt — und welcher Schritt dabei nicht übersprungen werden darf. In der Umsetzung entscheidet sich, ob die Tests tragen. Sie müssen das geforderte Verhalten prüfen, vor der Änderung fehlschlagen und danach ohne Anpassung grün werden.

11:52 Diese drei Bedingungen hängen zusammen. Ein Test, der vor der Änderung schon grün war, prüft nicht das neue Verhalten. Einer, der nur nach Anpassung grün wird, hat die Messlatte verschoben. Nur wenn alle drei zutreffen, haben Sie einen Nachweis statt eines guten Gefühls. Fünf Schritte. Den Test zum Grenzfall zuerst schreiben lassen. Ihn rot laufen sehen — sonst prüft er möglicherweise nichts. Die Umsetzung beauftragen, bis er grün ist.

12:19 Den Testinhalt lesen, nicht nur die Farbe. Und den gesamten Testlauf selbst ausführen. Die Fußzeile begründet Schritt zwei mit einem Satz, den man sich merken sollte: Ein Test, der nie rot war, ist kein Nachweis — nur eine Zeile mehr Code. Der erste Punkt ist der, gegen den wir in Kapitel drei eine Regel geschrieben haben: angepasste Tests statt angepassten Codes.

12:43 Der zweite betrifft die Qualität der Tests — sie prüfen den Aufrufweg statt des Verhaltens und brechen dann bei jedem Refactoring. Der dritte ist die grüne Meldung ohne eigenen Testlauf. Und der vierte schließt den Kreis zum Anfang des Moduls: Grenzfälle aus der Anforderung bleiben ungetestet — und damit war das Klären umsonst.

13:02 Der Hinweis beschreibt eine Gegenprobe, die den Bogen dieses Moduls schließt: Vergleichen Sie Ihre Testliste mit der Liste offener Punkte aus dem ersten Kapitel. Für jeden geklärten Grenzfall sollte ein Test existieren. Wo einer fehlt, ist eine fachliche Klärung unterwegs verlorengegangen — und genau das passiert im Alltag ständig, weil zwischen dem Klären und dem Testen mehrere Tage und einige Kontextwechsel liegen.

Reviewen und korrigieren

13:25 Die Umsetzung steht. Jetzt kommt das Review — und zwar nicht Schritt für Schritt, sondern über das gesamte Vorhaben. Denn erst am Ende lässt sich prüfen, ob alles umgesetzt wurde, was am Anfang gefordert war. Sehen wir uns an, wie das abläuft und welche Reihenfolge dabei zählt. Im Review wird das gesamte Ergebnis gegen die ursprüngliche Anforderung gehalten: Ist alles umgesetzt, was gefordert war? Ist etwas passiert, was niemand verlangt hat?

13:53 Halten die Begründungen? Der Bezugspunkt ist bewusst die Anforderung vom Anfang, nicht der Plan. Denn zwischen Anforderung und Plan kann bereits etwas verlorengegangen sein — und wer nur gegen den Plan prüft, findet genau diesen Verlust nicht. Fünf Schritte. Das Diff des gesamten Vorhabens ansehen. Gegen die geschärfte Anforderung prüfen. Ein Review durch den Agenten als zweite Sicht einholen.

14:17 Die Befunde gewichten statt alle zu übernehmen. Und Korrekturen zurück in Plan oder Analyse führen. Die Fußzeile beschreibt die Arbeitsteilung, die sich durch dieses ganze Seminar zieht: Der Agent liefert eine zweite Sicht — die Entscheidung bleibt bei Ihnen. Vier Dinge. Anforderungen, die im Verlauf untergegangen sind — das findet man nur, wenn man die ursprüngliche Liste danebenlegt. Änderungen außerhalb des Plans.

14:43 Neue Abhängigkeiten und stille Standardwerte. Und Annahmen, die nirgends festgehalten wurden. Der letzte Punkt ist der, der später am meisten Ärger macht: Eine Annahme, die im Code steckt und nirgends dokumentiert ist, wird beim nächsten Umbau unbemerkt verletzt. Der Hinweis nennt eine Reihenfolge, die den Unterschied macht: Lesen Sie zuerst die Anforderung noch einmal, dann erst das Diff. Nicht umgekehrt.

15:08 Denn wer mit dem Diff beginnt, prüft, ob das Gemachte sinnvoll ist — und findet es meistens sinnvoll. Wer mit der Anforderung beginnt, prüft, ob das Geforderte gemacht wurde. Das ist eine andere Frage, und sie führt regelmäßig zu einer Lücke, die sonst niemand bemerkt hätte.

Einen eigenen Workflow entwickeln

15:25 Zum Schluss der Schritt, der aus einem gelungenen Durchlauf eine Arbeitsweise macht. Denn ein einzelnes Vorhaben, das gut lief, ist noch kein Verfahren. Sehen wir uns an, was Sie aus diesem Durchlauf mitnehmen sollten und wohin die einzelnen Erkenntnisse gehören, damit sie beim nächsten Mal noch da sind. Am Ende steht nicht ein fertiges Feature, sondern ein Verfahren: die Reihenfolge, die bei Ihnen funktioniert, festgehalten in Projektregeln, Skills und Gewohnheiten, die den nächsten Durchlauf tragen.

15:53 Das ist der eigentliche Ertrag dieses Seminars. Das Feature wäre auch ohne uns entstanden. Was bleibt, ist die Frage, ob Sie beim nächsten Vorhaben wieder bei null anfangen — oder mit dem, was Sie diesmal gelernt haben. Vier Zeilen, die alles einordnen, was wir in zwölf Modulen besprochen haben. Eine Regel, die immer gilt, gehört in die AGENTS.md. Ein Ablauf, der sich wiederholt, wird ein Skill.

16:18 Eine Entscheidung mit Begründung gehört in den Commit oder die Spezifikation. Und eine persönliche Gewohnheit in Ihre eigene Prüfliste. Die Fußzeile nennt die Alternative, die keine ist: Was nur im Kopf bleibt, ist beim nächsten Vorhaben wieder verschwunden. Fünf Schritte für die Nachbetrachtung. Den Durchlauf ehrlich ansehen. Reibungspunkte benennen, nicht beschönigen. Wiederholtes in Regeln und Skills überführen.

16:44 Beim nächsten Vorhaben bewusst anwenden. Und nach dem zweiten Durchlauf erneut nachschärfen. Die Fußzeile fasst zusammen, worauf es ankommt: Zwei Durchläufe zeigen mehr als zehn Vorsätze. Das gilt für diese Arbeitsweise wie für jede andere Veränderung im Arbeitsalltag. Das Erfolgskriterium ist konkret: Regeln, Skills und Prüfliste liegen im Repository, und der nächste Durchlauf startet damit.

17:09 Der Hinweis ergänzt etwas, das man selten dokumentiert: Halten Sie auch fest, was nicht funktioniert hat. Diese Notizen sparen den nächsten Fehlversuch — Ihnen selbst und allen, die nach Ihnen mit diesem Projekt arbeiten. Und sie sind ehrlicher als jede Erfolgsgeschichte.

Danke!

17:26 Damit sind wir am Ende. Sie haben in zwölf Modulen gesehen, wie aus einem Coding-Assistenten ein Engineering-Agent wird — und vor allem, welche Sorgfalt das auf Ihrer Seite verlangt: klarer Kontext, verankerte Regeln, geplante Schritte, geprüfte Ergebnisse. Die Materialien liegen in der Freigabe bereit, für Fragen und Rückmeldungen ist die Adresse angegeben.

17:47 Der wichtigste nächste Schritt steht in der letzten Zeile: der erste eigene Durchlauf im echten Projekt. Alles andere ist Theorie, bis Sie ihn gemacht haben.