Prompting, Planung & Architektur

Prompting, Planung & Architektur

0:00 Im ersten Kapitel haben Sie den Agenten zum Laufen gebracht und ihm eine kleine Aufgabe gegeben. Das hat gut funktioniert — und genau darin liegt die Falle. Denn was bei „benenne diese Funktion um" mühelos klappt, geht bei „migriere das Auth-Backend" oft schief. Nicht, weil der Agent zu dumm wäre, sondern weil niemand vorher geklärt hat, in welcher Reihenfolge was passieren soll.

0:22 In diesem Kapitel geht es deshalb um die Arbeitsweise davor: Wie bringt man den Agenten dazu, erst zu denken und dann zu bauen? Wie macht man Architektur sichtbar? Und woran erkennt man, welche Aufgabe welches Vorgehen verlangt?

Prompting, Planung & Architektur

0:36 Der rote Faden dieses Kapitels lässt sich in einem Satz sagen: Die Größe der Aufgabe bestimmt die Vorgehensweise. Wir schauen uns zuerst den Plan-Modus an — die Möglichkeit, den Agenten erkunden und planen zu lassen, bevor er eine einzige Datei anfasst. Danach geht es um Architektur als Text, mit Mermaid direkt im Repository. Und zum Schluss um die schlichte, aber wichtige Frage, wann sich der ganze Aufwand überhaupt lohnt.

Vom Prompt zum Multi-Step-Plan

1:02 Beginnen wir dort, wo einfache Prompts an ihre Grenze stoßen. Es gibt einen Punkt, ab dem eine Aufgabe nicht mehr in einem Rutsch zu lösen ist — und die gute Nachricht ist, dass Claude Code für genau diesen Punkt einen eigenen Modus mitbringt. Stellen Sie sich einen Handwerker vor, der Ihre Wohnung umbauen soll. Der schlechte Handwerker fängt sofort an zu stemmen.

1:23 Der gute geht erst einmal durch alle Räume, schaut sich an, was da ist, und legt Ihnen dann vor, in welcher Reihenfolge er vorgehen will — und erst wenn Sie nicken, kommt der Bohrhammer raus. Genau das ist der Plan-Modus. Technisch gesehen ist er eine Berechtigungsstufe: Claude Code darf die Codebasis lesen, aber nicht schreiben.

1:41 Er legt einen mehrstufigen Plan vor, und erst Ihre Freigabe schaltet die Änderungen frei. Das Bemerkenswerte daran ist weniger die Technik als die Reihenfolge — Verstehen kommt vor Handeln. Warum lohnt sich dieser Zwischenschritt? Weil er den Zeitpunkt der Korrektur verschiebt. Ein Zero-Shot-Prompt — also der Versuch, eine Aufgabe in einem einzigen Anlauf zu lösen — scheitert bei mehrstufigen Refactorings oft nicht am einzelnen Schritt, sondern an der Reihenfolge und an stillschweigenden Annahmen.

2:10 Der Plan legt beides offen, bevor auch nur eine Zeile geschrieben ist. Und das ist der eigentliche Gewinn: Sie korrigieren einen Absatz Text statt hinterher Änderungen, die über ein Dutzend Dateien verstreut sind. Dazu kommt der Nebeneffekt des Read-only-Modus — voreilige Änderungen sind schlicht nicht möglich, solange Sie nicht zugestimmt haben.

2:30 In der Praxis sind das fünf Schritte, und die ersten beiden sind einfach zwei Wege zum selben Ziel: Entweder Sie schalten mit `Shift+Tab` durch die Modi, bis der Plan-Modus aktiv ist, oder Sie sagen es direkt mit `/plan` und Ihrer Beschreibung. Danach übernimmt Claude und erkundet — lesend, ohne etwas anzufassen. Der entscheidende Schritt ist der vierte, und er gehört Ihnen: Plan lesen, Feedback geben oder freigeben.

2:53 Nehmen Sie sich dafür wirklich Zeit, denn hier ist die Korrektur billig. Erst danach beginnt die Umsetzung. Und für wirklich große Vorhaben gibt es mit `/ultraplan` noch eine Stufe darüber, bei der die Planung in der Cloud läuft. Was Sie hier sehen, ist kein Code, sondern ein Gesprächsverlauf — und das ist der Punkt. Sie formulieren ein Vorhaben in einem Satz, hier eine Migration des Auth-Backends auf Token-Login.

3:18 Danach passiert erst einmal nichts Sichtbares: Claude liest sich durch das Projekt. Diese Phase kann einen Moment dauern, und sie ist gut investiert, denn sie ersetzt das, was sonst Sie selbst im Kopf zusammensuchen müssten. Heraus kommt ein mehrstufiger Plan. Behalten Sie die Fußzeile im Kopf, sie ist die eigentliche Zusicherung: Es gibt keinen Schreibzugriff, solange der Plan nicht bestätigt ist.

3:41 Sie können also gefahrlos ausprobieren, was der Agent vorschlägt. Jetzt probieren Sie das an einem eigenen Vorhaben aus — und wählen Sie es bitte bewusst groß genug. Bei einer Zeile Änderung ist der Plan-Modus Overhead; sein Wert zeigt sich erst, wenn mehrere Schritte in einer bestimmten Reihenfolge zusammenspielen müssen.

4:01 Das Lernziel ist nicht, einen Plan zu bekommen — den bekommen Sie ohnehin —, sondern ihn bewusst zu behandeln: freigeben oder nachschärfen. Lesen Sie ihn kritisch. Stehen dort Annahmen, die nicht stimmen? Fehlt ein Schritt? Genau dieses Nachschärfen ist die Fähigkeit, die Sie hier üben. Die Umsetzung startet erst, wenn Sie zufrieden sind.

Systemarchitektur & Diagramme

4:21 Ein Plan beschreibt, was passieren soll. Manchmal braucht es aber vorher noch etwas anderes: ein gemeinsames Bild davon, wie das System überhaupt aussieht. Auch dabei hilft der Agent — und zwar in einer Form, die erstaunlich gut zu einem Entwickler-Alltag passt. Architekturdiagramme haben ein bekanntes Problem: Sie liegen als Bilddatei irgendwo im Wiki, niemand weiß, wo das Original ist, und aktuell sind sie sowieso nie.

4:47 Mermaid dreht das um. Ein Diagramm ist hier schlicht Text — ein paar Zeilen, die beschreiben, welcher Kasten mit welchem Pfeil verbunden ist. Das klingt nach einem Rückschritt, ist aber ein Gewinn: Text lässt sich versionieren, im Pull Request diffen und vom Agenten aus dem Projektkontext heraus erzeugen und ändern. Gerendert wird woanders — im Editor, in der Dokumentation, in einem Viewer. Das Diagramm lebt damit dort, wo auch der Code lebt.

5:13 Der offensichtliche Vorteil ist die Versionierbarkeit: Sie sehen im Diff, dass jemand einen Service hinzugefügt hat, statt zwei PNG-Dateien nebeneinanderzulegen und Unterschiede zu suchen. Der zweite Vorteil ist der Agent selbst — er kennt das Projekt und kann ein Diagramm daraus ableiten, statt dass Sie es aus dem Gedächtnis malen.

5:32 Der dritte ist Kommunikation: Ein Bild schafft in einer Diskussion schneller gemeinsames Verständnis als drei Absätze Prosa. Und schließlich bleiben Sie unabhängig von einem bestimmten Werkzeug. Mermaid ist ein offenes Textformat, kein Produkt, das Ihnen eines Tages die Lizenzbedingungen ändert. Diese vier Zeilen lohnen sich als Beispiel, weil man ihnen die Idee direkt ansieht: Ein Nutzer spricht die REST-API an, die API redet mit der Datenbank und schiebt Arbeit in eine Queue, aus der ein Worker sie abholt.

6:02 Sie können das lesen, ohne Mermaid je gelernt zu haben — die Pfeile erzählen die Geschichte. Genau darin liegt der praktische Wert: Sie müssen die Syntax nicht beherrschen, um ein vom Agenten erzeugtes Diagramm zu prüfen und zu korrigieren. Worauf es ankommt, ist die Auswahl. Welche Komponenten gehören in diese Sicht, welche lassen Sie bewusst weg? Das ist eine inhaltliche Entscheidung, keine technische.

6:25 Vier Punkte, die typischerweise für Irritation sorgen. Der erste ist eine Erwartungsfrage: In der Kommandozeile erscheint kein Bild, sondern Text — zum Rendern brauchen Sie einen externen Viewer, und das ist kein Fehler, sondern der Preis für die Versionierbarkeit. Zweitens gibt es keine native Anbindung an draw.io oder Lucidchart; Mermaid ist der dokumentierte Weg, und man fährt gut damit.

6:48 Der dritte Punkt ist ein Klassiker jeder Dokumentation: Wer alles in ein Diagramm packt, bekommt eine unlesbare Tapete — lieber je Sicht ein eigenes. Und der vierte ist der ehrlichste: Diagramme driften vom Code weg, wenn niemand sie mitpflegt. Textformat hilft dabei, ersetzt die Disziplin aber nicht. Lassen Sie sich jetzt selbst eine Struktur zeichnen — entweder etwas, das es in Ihrem Projekt schon gibt, oder etwas, das Sie planen. Beides funktioniert.

7:16 Der Tipp aus der Praxis ist wichtiger, als er klingt: Starten Sie grob. Bitten Sie zuerst um die großen Bausteine und deren Verbindungen, schauen Sie sich das an, und verfeinern Sie dann gezielt einen Ausschnitt. Wer sofort alles auf einmal verlangt, bekommt genau die Tapete von der letzten Folie. Als Erfolg gilt ein gerendertes Diagramm, in dem Komponenten und Datenfluss tatsächlich stimmen — prüfen Sie das, der Agent rät im Zweifel auch mal.

Entscheidungsmatrix

7:42 Bleibt die Frage, die sich im Alltag jedes Mal neu stellt: Reicht ein kurzer Prompt, oder lohnt der Plan? Dafür gibt es keine Formel, aber zwei ziemlich verlässliche Kriterien — und die schauen wir uns jetzt an. Die Einordnung läuft über zwei Achsen: Umfang und Risiko. Umfang ist die naheliegende Größe — wie viele Dateien, wie viele Schritte.

8:03 Risiko ist die weniger beachtete, aber oft wichtigere: Wie leicht komme ich zurück, wenn das Ergebnis nicht passt? Kleine, lokale Änderungen mit klarem Effekt laufen als einfacher Prompt; umfangreiche oder schwer umkehrbare Vorhaben laufen über den Plan-Modus. Das ist übrigens keine Erfindung aus der KI-Welt. Sie machen dieselbe Abwägung, wenn Sie entscheiden, ob Sie schnell auf `main` committen oder lieber einen Branch aufmachen.

8:29 Nur ist die Frage hier expliziter geworden. Lesen Sie diese Tabelle nicht als Liste von Beispielen, sondern als vier Ausprägungen derselben zwei Kriterien. Die Zeilen bewegen sich von außen nach innen: oben der Umfang — eine Datei gegen viele, bei denen die Reihenfolge zählt. Darunter das Risiko, und zwar in der entscheidenden Form: Wie schwer ist die Änderung rückgängig zu machen?

8:51 Je weiter Sie in dieser Tabelle nach rechts rutschen, desto teurer wird ein Fehler und desto billiger wird im Vergleich dazu die Planung. Die Fußzeile ist deshalb mehr als eine Floskel: Im Zweifel planen. Ein Plan, den Sie nach dreißig Sekunden freigeben, hat Sie fast nichts gekostet. Diese Übung braucht kein Terminal, nur Ihren eigenen Rückstau. Nehmen Sie drei Aufgaben, die tatsächlich bei Ihnen anstehen, und ordnen Sie jede begründet einem Vorgehen zu.

9:18 Auf die Begründung kommt es an — „fühlt sich groß an" reicht nicht. Und achten Sie besonders auf den Hinweis: Nicht der Aufwand allein entscheidet. Eine Datenbankmigration kann in zehn Minuten geschrieben sein und gehört trotzdem in den Plan-Modus, weil sie sich kaum zurückdrehen lässt. Umkehrbarkeit ist das Kriterium, das man am leichtesten übersieht — und das am teuersten wird, wenn man es übersieht.

9:42 Fassen wir zusammen. Sie kennen jetzt den Plan-Modus — erreichbar über `Shift+Tab` oder `/plan` — und wissen, wofür er gedacht ist: mehrstufige, riskante Vorhaben, bei denen die Korrektur am Plan viel billiger ist als die Korrektur am Code. Sie haben gesehen, wie Architektur als Mermaid-Text ins Repository wandert und damit denselben Regeln folgt wie der Code selbst.

10:03 Und Sie haben ein Kriterienpaar an der Hand, um Aufgaben einzuordnen: Umfang und Umkehrbarkeit. Im nächsten Kapitel geht es darum, wie der Agent sich all das merkt, was Sie ihm einmal beigebracht haben — Skills und Projektgedächtnis.

Erst denken lassen, dann bauen

10:17 Der Titel dieser Folie ist die Zusammenfassung des ganzen Kapitels: Prompt für Kleines, bestätigter Plan für Großes. Was Sie hier gelernt haben, ist im Kern keine Bedienung, sondern eine Haltung — dieselbe, die gute Entwicklungsarbeit schon immer ausgezeichnet hat. Erst verstehen, dann entscheiden, dann umsetzen. Der Unterschied ist, dass dieses Vorgehen jetzt einen Schalter hat und Sie sichtbar vorgelegt bekommen, was gleich passieren soll.

10:44 Nutzen Sie das lieber einmal zu oft als einmal zu selten. Fragen und das Material zum Nachlesen finden Sie unter www.HCO.de.