00:00:00Jeder weiß, dass man für die Arbeit mit Coding-Agents ein Framework braucht, aber nur wenige
00:00:04haben eines, das einfach ist, wirklich zu ihnen passt und das sie mit der Zeit weiterentwickeln können.
00:00:09Auf GitHub gibt es viele überladene Frameworks. All diese Multi-Agenten-Systeme,
00:00:15die da erstellt werden – ich respektiere die Arbeit dahinter, aber oft braucht man einfach nur
00:00:19etwas ganz Simples, das den Job erledigt. Ich weiß nämlich, dass ihr gute Ideen habt,
00:00:24die ihr umsetzen wollt, und ihr wollt nicht mehr Zeit mit dem Erstellen von Agenten-Workflows verbringen
00:00:29als mit dem eigentlichen Codieren. Genau das habe ich heute für euch: Mein extrem simples Framework,
00:00:35das ich jedes Mal verwende, wenn ich ein neues Projekt mit meinem Coding-Agent starte.
00:00:40Brownfield-Entwicklung, also die Arbeit an einer bestehenden Codebasis, ist etwas anders – dazu kommt ein eigenes Video.
00:00:45Hier konzentrieren wir uns auf Greenfield-Entwicklung. Wir wollen ein einfaches System, um so schnell wie möglich
00:00:50mit etwas Neuem durchzustarten. Alles, was ich hier erkläre, ist universell gültig.
00:00:56Diese Prinzipien lassen sich auf jeden Coding-Agent anwenden. Das Video besteht aus zwei Teilen,
00:01:00und ich werde parallel zu den Erklärungen einen Live-Build durchführen, um alles ganz konkret zu machen.
00:01:05Im Moment enthält meine Codebasis so gut wie nichts, außer meinem AI-Layer.
00:01:11Es gibt ein paar Befehle und Skills, die ich übernommen habe. Das ist mein Startpunkt für jedes Projekt.
00:01:16Wir erstellen etwas von Grund auf neu, also beginnen wir mit der initialen Planung
00:01:21und erstellen ein sogenanntes PRD (Product Requirements Document). Das definiert den Umfang,
00:01:27um ein Minimum Viable Product (MVP) für unsere App zu erstellen. Dazu gehört einiges,
00:01:32wie das Aufsetzen des AI-Layers, noch bevor wir mit dem eigentlichen Programmieren beginnen.
00:01:37Anschließend unterteilen wir das PRD in Arbeitsphasen und arbeiten diese mit PIV-Loops ab.
00:01:43Ich werde erklären, was das bedeutet, wir sehen ein Beispiel, und während der Implementierung
00:01:47erläutere ich die vier goldenen Regeln, die wir immer befolgen sollten. Diese Regeln fügen sich
00:01:52ganz natürlich in den Prozess ein – vom PRD über den AI-Layer bis zum PIV-Loop.
00:01:57Ein Beispiel ist das Kontext-Management. Kontext ist eure wertvollste Ressource,
00:02:03wenn ihr mit KI-Coding-Assistenten arbeitet. Das wird sich wie ein roter Faden durchziehen.
00:02:08Außerdem erstellen wir Befehle und Skills für alles und verfolgen ein Mindset der System-Evolution,
00:02:14denn wir wollen ein System schaffen, das zuverlässig und wiederholbar ist.
00:02:18Darauf werde ich im Verlauf immer wieder eingehen. Das Video wird also extrem vollgepackt mit Wissen.
00:02:23Wir starten mit der Planung und dem Erstellen dessen, was ich den AI-Layer nenne.
00:02:28Ich erkläre euch jetzt, was das ist, und wir bauen ihn direkt zusammen auf.
00:02:34Euer AI-Layer besteht aus allen Elementen in eurer Codebasis, die als Kontext für den
00:02:39Coding-Agent dienen. Etwa das PRD: Was bauen wir? Die globalen Regeln: Wie bauen wir es?
00:02:45Die Befehle: Damit wir wiederverwendbare Workflows für unseren Coding-Agent haben.
00:02:50Zuerst konzentrieren wir uns auf den Hauptbefehl, aber auch auf Sub-Agenten für die Recherche.
00:02:55Ich arbeite normalerweise so mit meinem AI-Layer – und ich stelle euch das als Ressource bereit –,
00:03:01dass ich ein Set an generischen Befehlen in jedes neue Projekt mitnehme.
00:03:07Der Clou ist: Wenn die Codebasis wächst, entwickle ich auch meine Befehle weiter,
00:03:13um sie mächtiger und spezifischer für den jeweiligen Anwendungsfall zu machen.
00:03:18Genau das empfehle ich euch auch. Nutzt das hier gerne als Startpunkt.
00:03:23Den Link zum GitHub-Repo findet ihr in der Beschreibung. Es ist absichtlich so simpel gehalten,
00:03:27damit ihr es leicht übernehmen und an eure Arbeitsweise anpassen könnt.
00:03:33Deshalb empfehle ich das eher als komplexe Frameworks wie Beemad oder das GitHub Spec Kit.
00:03:38Die sind zwar extrem mächtig, aber man kann sie schwer zu seinem eigenen Ding machen.
00:03:42Ich zeige euch jetzt, wie man ein komplettes PRD erstellt und die ersten Regeln festlegt.
00:03:48Wir passen sogar unseren ersten Befehl ein wenig an und ich spreche über Sub-Agenten.
00:03:52Ich weiß, das ist viel Planung, bevor wir mit den PIV-Loops den ersten Code schreiben,
00:03:57aber es ist wichtig. Planung vorab mag sich langsam anfühlen, aber mit einem guten Plan,
00:04:03klaren Regeln und einem soliden PRD wird die gesamte restliche Entwicklung
00:04:07viel schneller und zuverlässiger ablaufen. Starten wir also mit dem PRD.
00:04:13Manche nennen es auch Spezifikation. Es ist einfach der gesamte Arbeitsumfang für die
00:04:18erste Version unserer Anwendung. Sobald dieses Fundament steht, geht es eher
00:04:24Richtung Brownfield-Entwicklung über – dazu mehr im nächsten Video. Seid gespannt.
00:04:28In meinem Claude-Code-Projekt, das außer dem AI-Layer noch leer ist, werde ich
00:04:34zuerst ein ganz lockeres Gespräch führen. Ich erzähle ihm von meiner Idee,
00:04:40meinen Gedanken zum Tech-Stack und zur Architektur. Man beginnt völlig unstrukturiert,
00:04:45was den Einstieg enorm erleichtert. Irgendwann nutzt man diese Unterhaltung
00:04:50dann als Kontext, um ein strukturiertes PRD zu erstellen. Ich habe dafür einen Befehl,
00:04:55den ich euch gleich zeige, aber fangen wir erst mal mit der Idee an.
00:05:01Als schönes Beispiel für dieses Video möchte ich eine Art Linktree-Klon bauen,
00:05:06aber als selbstgehostete Version. Man kann seine eigene Landingpage erstellen,
00:05:12Links organisieren, Analytics wie die Klickrate sehen und das Ganze anpassen.
00:05:16Das ist ein gutes Beispiel: Es ist nicht so trivial, dass man es einfach so hincodiert,
00:05:20bietet aber coole Features und ist gleichzeitig nicht so kompliziert, dass wir am Ende
00:05:24des Videos kaum Ergebnisse vorzuweisen hätten.
00:05:29Ich werde ein Speech-to-Text-Tool nutzen, um das hier zu erledigen. Ich empfehle
00:05:33Tools wie Aqua Voice, das nutze ich selbst. Es gibt aber auch gute Open-Source-Optionen
00:05:39wie Whisper Flow oder Epicenter Whispering. Ich liebe Speech-to-Text, weil ich niemals
00:05:43226 Wörter pro Minute tippen könnte. Ich nutze so ein Tool für einen ersten Brain-Dump
00:05:48meiner Ideen. Das wird sehr ungefiltert sein, aber ich mache das jetzt live für euch.
00:05:54Achtet darauf, was ich Claude Code dabei auftrage, denn das ist genauso wichtig wie
00:05:59die Ideen selbst. Ich erkläre das gleich noch genauer. Übrigens könnt ihr das
00:06:03alles mit jedem beliebigen KI-Coding-Assistenten machen. Also, los geht's:
00:06:09"Ich möchte einen 'Link in Bio'-Page-Builder bauen, ähnlich wie Linktree. Nutzer sollen
00:06:13einen Account erstellen und eine Landingpage mit Links gestalten können. Die Reihenfolge
00:06:20soll anpassbar sein. Außerdem will ich Analytics für die Klickraten und verschiedene Themes.
00:06:24Als Tech-Stack stelle ich mir Next.js vor, Neon für die Datenbank und Neon Authentication.
00:06:29Starte also auf jeden Fall einen Sub-Agenten für die Recherche dazu. Die Architektur
00:06:33ist mir nicht so wichtig, da hätte ich gerne deine Empfehlungen – auch dazu, wie wir
00:06:37das Theming und den Link-Builder handhaben. Ich möchte auch, dass du einen Agenten
00:06:43mit der Web-Recherche zu Best Practices für solche Linktree-Anwendungen beauftragst.
00:06:48Danach sollst du mir eine Reihe von Fragen stellen, damit wir bei allen Details
00:06:55auf dem gleichen Stand sind." Okay, sehr gut. Das schicke ich jetzt ab, die Transkription
00:07:00dauert nur ein paar Sekunden. Und zack, es geht los. Das Wichtigste, was ich gerade
00:07:04getan habe, war am Ende: Die Anweisung, mir nach der Recherche Fragen zu stellen.
00:07:10Das ist ein entscheidender Punkt: Das oberste Ziel bei der Planung mit Coding-Agents
00:07:14ist es, die Anzahl der Annahmen zu reduzieren, die der Agent treffen muss.
00:07:20Wenn ein Coding-Agent einen Fehler macht, liegt es oft nicht am schlechten Code,
00:07:25sondern daran, dass man nicht auf einer Wellenlänge war, was genau gebaut werden soll.
00:07:32Es gibt das Sprichwort: Eine Zeile schlechter Code ist nur eine Zeile schlechter Code.
00:07:37Eine schlechte Zeile in einem Plan führt vielleicht zu hundert Zeilen schlechtem Code.
00:07:42Aber eine falsche Zeile im PRD kann tausende Zeilen schlechten Code bedeuten,
00:07:48weil die gesamte Ausrichtung nicht stimmt. Ich habe viel experimentiert, wie man
00:07:54Annahmen minimieren kann. Den Agenten zu bitten, mich mit Fragen zu löchern,
00:08:02funktioniert unglaublich gut. Besonders Claude Code mit seinem Frage-Tool,
00:08:08das Multiple-Choice-Optionen oder eigene Antworten erlaubt, ist extrem mächtig.
00:08:13Es berücksichtigt Edge Cases und Details, an die man selbst gar nicht denkt.
00:08:17Es ist schwer, selbst zu erahnen, welche Annahmen die KI treffen könnte. Deshalb ist
00:08:23das so wertvoll. Wie ihr hier seht, laufen auch verschiedene Sub-Agenten für die Recherche.
00:08:28Ich liebe Sub-Agenten für die Planung, die PRD-Erstellung oder sogar für die Vorbereitung
00:08:33der PIV-Loops. Bei Claude Code muss ich keine eigenen Sub-Agenten erstellen,
00:08:38da Tools für Exploration und Recherche bereits integriert sind. Bei anderen Agents
00:08:42muss man sie vielleicht selbst bauen, deshalb erwähne ich es hier. Fast jeder gute
00:08:48Coding-Agent unterstützt heute das Konzept von Sub-Agenten. Für die Recherche sind
00:08:53sie ideal, und zwar wegen der Kontext-Isolierung. Ein Kernthema ist, den Kontext
00:08:59unseres Haupt-Agents sauber zu halten. Recherche ist deshalb so ein guter Anwendungsfall,
00:09:04weil diese Agenten alles durchforsten – in der Codebasis oder im Web.
00:09:08Dabei verarbeiten sie zehntausende oder gar hunderttausende Tokens. Uns interessieren
00:09:14aber am Ende nur die Ergebnisse, also die Zusammenfassung für unseren Hauptkontext.
00:09:20So bleibt dieser übersichtlich. Für die eigentliche Implementierung empfehle ich
00:09:26keine Sub-Agenten, denn da brauchen wir den vollen Kontext aller bearbeiteten Dateien.
00:09:32Sonst kommt es meiner Erfahrung nach oft zu Halluzinationen. Deshalb hat Claude Code
00:09:36auch keine eingebauten Agenten für die Umsetzung, sondern nur für die Recherche.
00:09:41Genau das sehen wir hier gerade. Ich lasse das jetzt alles fertigstellen und melde mich
00:09:46utilizando subagentes para la implementación porque, con la implementación, normalmente nos importa todo lo relacionado con
00:09:51und wir haben den ersten Schwung Fragen. Ich glaube, ihr werdet das genauso schätzen
00:09:57wie ich, denn wir klären hier eine Menge. Jede Antwort eliminiert eine Annahme des Agents.
00:10:01Dank Multiple-Choice können wir das extrem schnell abarbeiten. So gehen wir mit der
00:10:06Gewissheit in die Implementierung, dass alle Details geklärt sind. Zum Beispiel:
00:10:12Wie soll die URL-Struktur der öffentlichen Seite aussehen? Option 1 gefällt mir,
00:10:17und weiter geht's. Wie viele Seiten soll jeder User erstellen können? Machen wir erst mal
00:10:22eine Seite pro User. Bei vielem bleibe ich einfach bei den Standards, aber es gibt Momente,
00:10:26in denen er etwas grundlegend falsch versteht – dann tippe ich eine eigene Antwort zur Klärung.
00:10:31Ich gehe jetzt alle Fragen durch und melde mich danach wieder. Ihr müsst nicht bei jeder
00:10:36einzelnen zusehen, das können schon mal 20 oder 25 Stück sein. Er meint es ernst.
00:10:41Man braucht etwas Geduld, aber jede Antwort kann einen vor hunderten Zeilen schlechtem Code bewahren.
00:10:46Hier ist ein gutes Beispiel, wo ich etwas ganz anderes will, als vorgeschlagen wurde.
00:10:50Das ist übrigens schon der zweite Schwung Fragen. Soll der Link-Editor ein Live-Vorschau-Frame
00:10:54haben? Ähnlich wie Lovable oder Bolt.new, wo man rechts sieht, was man links baut.
00:10:59Oder soll es inline sein? Eigentlich hätte ich gerne beides. Das schreibe ich ihm jetzt.
00:11:03Die restlichen Fragen kommen danach, aber hier können wir kurz ins Detail gehen.
00:11:07Ich sage: "Ich möchte einen Inline-Editor, aber mit der Option, die Vorschau einzublenden.
00:11:14Ich stelle mir drei Buttons vor: Nur Editor, beide Ansichten oder nur Vorschau."
00:11:19Das schicke ich ab, dann kommen die restlichen Fragen. So, Claude ist fertig mit den Fragen.
00:11:24Das waren wahrscheinlich mehr als nötig, aber man kann das ja nach Belieben steuern.
00:11:30Jetzt erstellen wir das PRD. Die finale Zusammenfassung zeigt, dass er genau verstanden hat,
00:11:35was wir bauen wollen, sogar wo ich es hosten werde: auf Vercel. Fantastisch.
00:11:39Ich habe das Gefühl, es gibt kaum noch offene Annahmen. Jetzt starte ich meinen
00:11:44"create PRD"-Befehl und speichere das unter .claud/prd.md. Den Pfad und Namen könnt ihr
00:11:49frei wählen. Ich nutze den Befehl, den ich vorhin erwähnt habe, denn eine goldene Regel lautet:
00:11:53"Commandify everything" – macht aus allem einen Befehl. Wenn ihr etwas mehr als zweimal macht
00:11:58– und ich habe schon einige Projekte gestartet –, solltet ihr einen Befehl daraus machen.
00:12:03Claude Code nennt das mittlerweile "Skills", da Befehle und Skills verschmolzen wurden,
00:12:08aber ich unterscheide das immer noch: Befehle ruft man selbst auf, wie /commit.
00:12:13Skills nutzt der Agent selbstständig, um etwa neuen Kontext zu verstehen. Ich erstelle hier
00:12:18einen Befehl, weil ich an diesem Punkt der Unterhaltung entscheide, dass nun ein
00:12:23strukturiertes PRD ausgegeben werden soll. In diesem Befehl gebe ich die exakte Struktur
00:12:28und alle Sektionen vor. So mache ich den Prozess wiederholbar. Das ist das Ziel des Systems:
00:12:31Etwas schaffen, das für einen funktioniert und das man immer wieder für neue Features
00:12:36oder Codebasen nutzen kann. Ich starte /createPRD und melde mich mit dem Ergebnis.
00:12:43Unser PRD ist fertig und sehr umfangreich. Das ist gut, denn wir lassen den Agenten
00:12:47nicht alles auf einmal bauen, sondern arbeiten in Phasen, die im PRD beschrieben sind.
00:12:53Ich werde jetzt nicht alles live validieren, das wäre langweilig, aber es ist wichtig,
00:12:59das Dokument durchzulesen, um sicherzugehen, dass man wirklich einer Meinung ist.
00:13:03Sonst rächt sich das später durch schlechten Code. Ein paar Punkte will ich kurz zeigen:
00:13:10Im MVP-Scope sehen wir, wie unsere Antworten aus den Fragen im PRD zum Leben erweckt wurden.
00:13:15Das ist wichtig, denn die Unterhaltung war nur unstrukturierter Input für das PRD.
00:13:20Nur das PRD zählt am Ende. Wir müssen also sicherstellen, dass alles Wichtige aus dem Chat
00:13:27hier gelandet ist. Auch der "Out of Scope"-Bereich ist wichtig: Was bauen wir bewusst nicht?
00:13:32Die Verzeichnisstruktur steht auch schon, da wir Tech-Stack und Architektur festgelegt haben.
00:13:38Ganz entscheidend sind die Arbeitsphasen. Wenn wir später unseren Hauptbefehl nutzen,
00:13:42können wir immer abgleichen: Was steht schon, was kommt laut PRD als Nächstes?
00:13:48Das wird zu Beginn jeder Sitzung ein wichtiger Kontext für den Bau unseres MVP sein.
00:13:53Hier ist die Sektion mit den Phasen. Jede davon wird eine granulare Implementierung,
00:14:00ein PIV-Loop. Erst das Fundament, dann das Link-Management, dann das Design.
00:14:04Wir planen jeden Schritt einzeln, damit der Agent nie zu viel auf einmal machen muss.
00:14:09Das PRD steht also, und das war der größte Brocken. Jetzt sind wir fast bereit für die
00:14:14erste Umsetzung. Als Nächstes müssen wir die Regeln festlegen. Das startet simpel,
00:14:18da sich die Regeln parallel zur Codebasis weiterentwickeln werden. Ich nutze Claude Code
00:14:22und orientiere mich an .agent und agents.md, da das quasi der Standard für globale Regeln ist.
00:14:29Wichtig ist: Alle Einschränkungen und Konventionen, die der Agent immer befolgen soll,
00:14:34gehören in diese Datei für globale Regeln. Also Dinge wie Befehle zum Starten der App,
00:14:40die Test-Strategie oder das Logging. Das soll der Agent bei jeder Aufgabe sehen.
00:14:44Wir erstellen jetzt eine erste Version. Die andere Komponente ist der Reference-Ordner.
00:14:49Man kann dafür auch Claude-Skills nutzen, aber Ordner sind universeller für Kontext,
00:14:53den der Agent nur in bestimmten Situationen braucht – etwa ein Guide für UI-Komponenten,
00:14:58wenn er gerade am Frontend arbeitet. Wir packen das nicht alles in die agents.md,
00:15:04da diese bei jedem einzelnen Gespräch in den Kontext geladen wird. Und denkt daran:
00:15:09Kontext ist wertvoll. Wir halten die Hauptdatei kurz und verweisen nur auf die anderen Files.
00:15:13Wir sagen dem Agenten: "Wenn du am Frontend arbeitest, lies diese Datei. Wenn du neue
00:15:19API-Endpunkte baust, lies jene." Das ist "Progressive Disclosure": Verschiedene
00:15:24Kontextebenen, die der Agent nur bei Bedarf lädt, um immer nur das Nötigste im Fokus zu haben.
00:15:29Auch hierfür habe ich einen Befehl. Wie gesagt: Macht alles zu Befehlen. Ich habe ein Template
00:15:33für PRDs und eines für globale Regeln. Zuerst schauen wir, was schon im Code vorhanden ist.
00:15:38Mein System funktioniert nämlich für neue und bestehende Projekte. In diesem Fall
00:15:43wird er vor allem das PRD analysieren, den Tech-Stack und die Architektur prüfen,
00:15:48Recherchen zu Tests und Logging anstellen und alles zu den globalen Regeln zusammenführen.
00:15:53Ich habe dafür eine feste Struktur vorgegeben, die auf meinem Template basiert.
00:15:58Das zeige ich euch jetzt auch noch ganz kurz.
00:16:04Hier sieht man die Struktur der globalen Regeln: Klare Anweisungen für den Agenten.
00:16:10Es geht darum, Fehlern vorzubeugen, bevor sie entstehen können.
00:16:16Wenn die KI genau weiß, wie sie testen oder loggen soll, spart das unheimlich viel Zeit.
00:16:20Nachdem wir die Regeln generiert haben, schauen wir sie uns gemeinsam an.
00:16:25Ein guter Satz Regeln ist das Rückgrat jeder erfolgreichen KI-Kollaboration.
00:16:30Jetzt lassen wir den Agenten die Arbeit machen und die agents.md erstellen.
00:16:35Es ist faszinierend zu sehen, wie er die Informationen aus dem PRD dort integriert.
00:16:40So, die Basis ist gelegt. Der AI-Layer nimmt langsam Gestalt an.
00:16:44Wir haben das PRD und die globalen Regeln – die wichtigsten Kontext-Quellen.
00:16:49Bevor wir den ersten Code schreiben, prüfen wir noch einmal kurz die Verzeichnisse.
00:16:55Alles sieht sauber und strukturiert aus, genau wie wir es geplant haben.
00:17:00Jetzt sind wir endlich bereit für den ersten PIV-Loop und die eigentliche Entwicklung.
00:17:04Das ist im Grunde progressive Offenlegung. Wir haben verschiedene Ebenen von Kontext,
00:17:09den der Agent mit der Zeit entdecken kann, um sicherzustellen, dass er nur das lädt, was er
00:17:14für die aktuelle Aufgabe wirklich braucht. Und dafür habe ich noch einen weiteren Befehl. Wieder gilt:
00:17:20Alles “befehlifizieren”. Genau wie ich eine Vorlage für meine PRDs habe, habe ich eine Vorlage
00:17:25für meine globalen Regeln. Zuerst finden wir heraus, was wir bereits in der Codebasis haben.
00:17:30Da ich dies für bestehende und neue Codebasen entwickelt habe, wird er hierfür
00:17:35eigentlich nur das PRD untersuchen. Er findet heraus, was unser Tech-Stack und unsere
00:17:38Architektur ist, macht Web-Recherche für Test- und Logging-Strategien und führt das alles
00:17:43mit meiner Anleitung zusammen, um meine globalen Regeln zu erstellen. Ich habe hier die exakte Struktur.
00:17:50Es wird also auf dieser Vorlage basieren, die ich habe. Ich zeige sie euch auch ganz kurz,
00:17:55denn das ist die Vorlage, die ich am liebsten für alle meine globalen Regeln verwende. Man sieht,
00:17:59dass uns hier alles wichtig ist, egal was der Agent tut. Zum Beispiel: Hier ist unser Tech-Stack,
00:18:04die Befehle zum Ausführen und Testen, unsere Projektstruktur. Es enthält quasi einen Index
00:18:08unserer Codebasis, Architektur, Codemuster wie Namenskonventionen, Test- und
00:18:13Validierungsstrategien. Es ist insgesamt recht einfach gehalten, aber wir erstellen das zuerst,
00:18:17und dann zeige ich euch ein paar Beispiele für Referenzdokumente als sekundären On-Demand-Kontext.
00:18:22Ich gehe also hier in Claude und tippe direkt in derselben Konversation, in der ich mein PRD erstellt habe,
00:18:27“create rules” ein, da ich die gesamte Konversation als Kontext zur Hilfe nutzen kann.
00:18:33Er weiß sofort: Okay, hier ist unser PRD, hier ist unser Tech-Stack und so weiter. Alles klar.
00:18:38Unser “create rules”-Befehl ist fertig, und wir haben jetzt unsere globalen Regeln. Ich habe sie
00:18:43schon aufgerufen. Ziemlich Standard hier. Wir haben unseren Tech-Stack, die Befehle,
00:18:47zum Beispiel, dass wir Drizzle ORM für unsere Datenbank nutzen, Projektstruktur, Architektur,
00:18:52Codemuster. Um es kurz zu machen, passe ich hier nichts weiter an oder bringe groß eigene
00:18:57Gedanken ein, aber je nachdem, wie technisch ihr seid, ist dies der Moment, um sicherzustellen,
00:19:03dass die Einschränkungen, Konventionen und Codemuster wirklich so sind, wie ihr eure
00:19:07Codebasen erstellen wollt. Man kann hiermit viel Zeit verbringen. Ich mache das jetzt nicht,
00:19:12weil ich mich hier mit euch auf die übergeordneten Ideen konzentriere. Ich musste also auch etwas
00:19:16Web-Recherche zu Best Practices für Frontend-Komponenten und API-Endpunkte betreiben.
00:19:21Darauf basierend musste ich auch etwas On-Demand-Kontext erstellen. Und nochmal:
00:19:24Das könnten auch Claude-Code-Skills sein, wenn ihr möchtet. Wenn wir zurück zu den globalen Regeln gehen
00:19:29und zum Abschnitt für On-Demand-Kontext scrollen, sehen wir: Beim Bearbeiten von Frontend-Komponenten,
00:19:34lies diese Datei. Beim Bearbeiten von API-Routen, lies jene Datei. Die clod.md ist das Einzige,
00:19:40was vorab geladen wird, aber er entscheidet dann selbst, den Rest bei Bedarf hinzuzuziehen.
00:19:45Meiner Erfahrung nach klappt diese Referenzierung sehr gut, besonders wenn unsere globalen Regeln prägnant sind,
00:19:50wie sie sein sollten. Wir haben hier nicht einmal 240 Zeilen – es sind 233 Zeilen für unsere globalen Regeln.
00:19:58Dann haben wir api.md und components.md. Diese sind viel größer, denn wenn wir an einer Aufgabe
00:20:03arbeiten, die sehr spezifisch ist, ist es okay, viel mehr Informationen für eine gute Anleitung
00:20:08unseres Coding-Agenten hinzuzuziehen. Wenn wir also zurück zu unserem Diagramm gehen: Die Regeln,
00:20:14das ist das “Wie” wir Dinge bauen wollen. Das PRD ist das “Was” genau wir bauen werden.
00:20:19Mit diesen beiden Dingen im Hinterkopf möchte ich zuletzt über Befehle sprechen, speziell den Prime-Befehl.
00:20:23Danach erstellen wir den Plan für die erste Phase und den Code. An diesem Punkt
00:20:29haben wir die initiale KI-Ebene. Wir haben unser PRD, unsere Regeln und diese generischen Befehle,
00:20:34die ich mitgebracht habe und die ihr gerne selbst nutzen könnt. Wir gehen jetzt zur Implementierung über.
00:20:39Aber hier ist der Punkt: Zu Beginn jeder neuen Konversation mit einem KI-Coding-Assistenten
00:20:44muss er sich erst einmal mit der Codebasis vertraut machen. Was bauen wir? Was kommt als Nächstes?
00:20:50Dafür ist der Prime-Befehl da. Das ist ein Befehl. Wir führen am Anfang jeder neuen Sitzung
00:20:56“/prime” aus. Es ist ein geführter Prozess für ihn, um unsere Codebasis zu erkunden und an den Punkt
00:21:02zu kommen, an dem er das mentale Modell hat und bereit für die nächste Feature-Implementierung ist.
00:21:06Wir lassen ihn also Dokumentation lesen und die Struktur erkunden. Er kann dafür auch Sub-Agenten nutzen.
00:21:11Das Prüfen des Git-Logs ist eine weitere Sache, über die ich gleich noch mehr sprechen werde:
00:21:15Die Nutzung des Git-Logs als Langzeitgedächtnis. So kann er sehen, wie sich unsere Codebasis
00:21:21über die Zeit entwickelt hat, was ihm hilft, Entscheidungen darüber zu treffen, was er als Nächstes baut.
00:21:26Nach diesem Befehl wird er uns sein Verständnis der Codebasis ausgeben. So können wir validieren,
00:21:31dass er weiß, was mit unserem Code los ist, und wir können mit dem nächsten Schritt weitermachen.
00:21:36Ohne zu sehr ins Detail zu gehen: Wir führen einige Operationen mit Git durch, um die Historie
00:21:40zu nutzen. Dann lesen wir die Kerndateien durch und identifizieren alles, worauf wir
00:21:45besonders achten müssen, wie zum Beispiel die Haupteinstiegspunkte unserer Anwendung.
00:21:49Dieser Ergebnisbericht dient uns zur Validierung seines Verständnisses. Wir können ihn mit der Zeit
00:21:55projektspezifisch weiterentwickeln. Um euch ein ganz kleines Beispiel zum Lesen der Kern-Dokumentation
00:22:01richtig? Er hatte sogar die automatische Vervollständigung; er wusste genau, worauf ich hinauswollte.
00:22:08¿verdad? Incluso tenía el autocompletado ahí. Sabía exactamente lo que buscaba. Y así, a medida que tú
00:22:12Wenn ihr also euer eigenes Verständnis dafür aufbaut, was die Kernpunkte sind, auf die der Agent
00:22:16in dieser Codebasis achten soll – wie zum Beispiel andere Dokumente im Referenzordner –
00:22:20können wir das hier hinzufügen. Jetzt gehe ich zurück in Claude, starte aber eine
00:22:25völlig neue Konversation, weil wir jetzt in unseren ersten PIV-Loop einsteigen. Ich werde den ganzen
00:22:30PIV-Loop gleich erklären, aber schaut euch das an: Ich führe einfach “Prime” aus.
00:22:34Das ist der Anfang meiner Konversation, bevor ich irgendetwas anderes untersuche. In diesem Fall
00:22:39wird er merken: Okay, das ist ein brandneues Projekt. Lass mich das PRD prüfen. Und er wird
00:22:44empfehlen: Machen wir zuerst Phase eins, erstellen wir das Fundament für unser Projekt.
00:22:49Unser Prime ist fertig. Hier ist die Projektübersicht: “Link in Bio”-Page-Builder. Der aktuelle Status:
00:22:54Ein leeres Repository mit reiner Dokumentation. Ich habe vorhin einen Test-Build gemacht, deshalb steht das da,
00:22:59aber ich habe für den Moment alles gelöscht. Dann hat er die erste Phase, das Fundament,
00:23:04aus unserem PRD gezogen. Und das ist es, was er zur Erstellung empfiehlt. Und genau das ist es,
00:23:10worauf ich hier aus bin. Er soll sich Phasen einzeln aus dem PRD picken, damit wir granulare
00:23:14Implementierungen für unsere PIV-Loops haben. Und wo wir gerade von PIV-Loops sprechen: Damit fangen wir jetzt an.
00:23:20PIV steht für “Plan, Implement, Validate” (Planen, Implementieren, Validieren). Wir nehmen fokussierte Arbeit,
00:23:29meist eine Phase aus einem PRD, und schicken sie durch diesen Prozess. Wir erstellen einen strukturierten Plan.
00:23:34Das ist dieser Teil hier, was wir angehen wollen. Dieser Prozess ist dem Erstellen eines PRDs
00:23:38eigentlich recht ähnlich. Dann geht es an die Implementierung. Unser Ziel ist es, das gesamte Coding
00:23:44an den Agenten zu delegieren. Danach erfolgt die Validierung. Ich werde ganz kurz umreißen,
00:23:50wie dieser Prozess aussieht. Dann sehen wir ihn in Aktion. Zuerst einmal haben wir beim Planen
00:23:55zwei Ebenen: Die übergeordnete Projektplanung. Das haben wir bereits getan, indem wir das PRD
00:24:00und unsere Regeln erstellt haben. Und jetzt haben wir die aufgabenspezifische Planung. Wie schon erwähnt,
00:24:07sind diese sich recht ähnlich. Einen strukturierten Plan zu erstellen ähnelt dem Erstellen
00:24:13unseres strukturierten PRDs sehr. Der Hauptunterschied ist, dass der strukturierte Plan sehr fokussiert auf
00:24:19ein einzelnes Feature und alle damit verbundenen Aufgaben ist. Jetzt kommen wir zum Code.
00:24:24Wir sind nicht mehr so abstrakt, fangen aber trotzdem mit einer sehr unstrukturierten Konversation an.
00:24:30Ich nenne das gerne “Vibe Planning”, bei dem wir allgemeine Ideen erkunden. Wie sieht die Architektur
00:24:35für das aus, was wir bauen? Wir setzen Sub-Agenten für Code-Analysen und Dokumentation ein
00:24:40und finden heraus: Was sind die spezifischen Aufgaben, die wir für dieses Feature erledigen müssen?
00:24:44Wir führen dieses Gespräch – ich zeige euch gleich ein Beispiel – und verwandeln das dann in ein
00:24:50strukturiertes Dokument, genau wie beim PRD. Ziel ist es, basierend auf unserem Gespräch einen
00:24:56detaillierten Schlachtplan für den KI-Coding-Assistenten zu erstellen. Die Unterhaltung ist
00:25:02Teil unseres Kontexts, aber hier haben wir sehr spezifische Abschnitte, die ich im Plan haben will:
00:25:09Ziel und Erfolgskriterien des Features, jegliche Dokumentation, die wir referenzieren wollen
00:25:13und die einer der Sub-Agenten gefunden hat, unsere Aufgabenliste, die sogar einzelne Dateien
00:25:18benennen kann, die erstellt oder aktualisiert werden sollen. Und der wohl wichtigste Teil dieses
00:25:23ganzen Plans ist die Validierungsstrategie. Das ist so ähnlich wie testgetriebene Entwicklung,
00:25:27bei der wir sehr genau festlegen wollen, wie das Feature validiert werden kann, bevor wir überhaupt
00:25:33eine einzige Zeile Code schreiben. Das zwingt sowohl uns als auch den Agenten dazu, die
00:25:38Erfolgskriterien sehr präzise zu definieren. Wir erstellen also unseren strukturierten Plan und sind
00:25:45voll involviert, delegieren dann aber das gesamte Coding an den Agenten selbst. Das ist jedoch kein
00:25:51“Vibe Coding”. Der einzige Grund, warum ich dem Agenten vertraue (und dennoch prüfe), ist,
00:25:56dass ich die Implementierung zwischen Planung und Validierung einbette, bei denen ich voll im Prozess bin.
00:26:01Wir lassen den Coding-Agenten seine eigene Arbeit mit Unit-Tests, Integrationstests und
00:26:06End-to-End-Tests prüfen. Das werden wir auch noch sehen. Aber dann werde ich meinen eigenen
00:26:11Code-Review durchführen und die Anwendung manuell testen. Ich reiche es selbst ein, gehe durch
00:26:16die Anwendung wie ein Nutzer und stelle sicher, dass alles gut funktioniert, bevor ich den
00:26:20Commit mache und es in die Produktion oder Staging schicke. Wichtig ist hierbei, dass ich zwischen
00:26:26der Planung und der Implementierung den Kontext zurücksetze. Das ist eine der goldenen Regeln.
00:26:32Kontext ist kostbar. Ich habe also ein langes, detailliertes Gespräch, um dieses Feature zu planen.
00:26:38Und der strukturierte Plan, den ich hier erstelle, soll der gesamte Kontext sein, den der Agent braucht,
00:26:44um den Job zu erledigen. So kann ich eine frische Konversation starten, in der der Plan das Einzige
00:26:50ist, was ich sende, weil er alle Referenz-Dokumente enthält. Er hat die komplette Aufgabenliste.
00:26:55Wir wissen, was zu tun ist, und wir wissen, wie man validiert. Auf diese Weise können wir einen harten
00:27:00Schnitt machen und in die Ausführung gehen, um alles sehr fokussiert zu halten, oder? Wir wollen die
00:27:06Konversation nicht mit unnötigem Kontext aufblähen, wenn es ans eigentliche Schreiben des Codes geht.
00:27:12Alles klar. Kommen wir nun zu unserem ersten PIV-Loop. Das wird viel einfacher sein, als ihr denkt,
00:27:16da wir jetzt die Früchte der ganzen Planung ernten, die wir im Vorfeld geleistet haben.
00:27:22Wir sind auf einer Wellenlänge mit unserem Coding-Agenten und sicher, dass er versteht, was wir bauen wollen.
00:27:27Es gibt also für jede dieser Phasen gar nicht mehr so viel zu planen, zumindest am Anfang.
00:27:31Gehen wir zurück: Wir haben den Prime-Befehl abgeschlossen und sind uns mit dem Agenten einig.
00:27:36Ich habe ihm hier einen ganz einfachen Prompt gegeben: “Ja, Phase eins sieht gut aus. Bestätige mir
00:27:40einfach noch einmal alles, was wir bauen werden.” Normalerweise sind die PIV-Loops nach dem ersten
00:27:44etwas detaillierter, wie zum Beispiel: “Lass uns die Codebasis ansehen, um genau zu klären, wie wir das bauen.”
00:27:49Aber hier ist es ganz simpel. Das sieht gut aus. Und jetzt, denkt dran: Alles befehlifizieren.
00:27:53Ich möchte dieses Gespräch und die Idee von Phase eins in einen strukturierten Plan mit Aufgabenliste
00:27:59und Validierung verwandeln. Dafür habe ich einen weiteren Befehl. Er heißt einfach
00:28:04“create or plan feature” – also slash plan feature. Da haben wir's. Ich sende das ab, und der Befehl
00:28:10“plan feature” hat, genau wie “create PRD”, das Konzept eines strukturierten Plans eingebaut. Ich zeige
00:28:17euch diesen Befehl auch mal kurz. “plan feature”, öffnen wir das mal. Er akzeptiert ein optionales Argument,
00:28:23mit dem ich spezifizieren kann, was ich bauen will. In diesem Fall nutze ich einfach den Verlauf, er wusste
00:28:28es also schon. Aber wir gehen hier durch einen mehrphasigen Prozess: Feature-Verständnis, Eintauchen
00:28:33in die Codebasis – was für künftige PIV-Loops relevanter ist. Er macht viel Recherche, zieht relevante
00:28:38Dokumentation heran und stellt sicher, dass wir einen reichhaltigen Kontext für die Ausführung haben.
00:28:44Und das, was ihr hier seht, ist die Vorlage. Wir wollen die Problemstellung beschreiben,
00:28:49Kontext oder Referenzen angeben. Wir haben unseren Implementierungsplan mit der Aufgabenliste hier.
00:28:55Und natürlich haben wir unsere Teststrategie. Wir wollen die Validierung im Vorfeld definieren. Und
00:29:00nachdem wir diesen Plan erstellt haben, validieren wir ihn natürlich. Wir stellen sicher, dass wir sehr
00:29:05spezifisch sind: Schritt für Schritt, wie genau die Anwendung validiert werden soll. Ich nutze hier
00:29:11tatsächlich den Vercel Agent Browser CLI Skill, zu dem ich ein Video gemacht habe, das ich hier verlinke.
00:29:17Wir bauen eine vollständige Browser-Automatisierung ein. Der Agent wird das Backend und Frontend
00:29:21starten, die Datenbank-Migrationen ausführen, seinen eigenen Link-Tree erstellen und im Grunde
00:29:26einfach sicherstellen, dass alles genau so funktioniert, wie ein Nutzer die App verwenden würde. Ziemlich
00:29:31spannend, aber die Validierung wird hier sehr detailliert sein, damit wir sehr zuversichtlich sein können,” device: “mobile
00:29:36wenn die Kontrolle an uns zurückgeht. Das spart uns viel Arbeit, auch wenn wir selbst noch validieren.
00:29:42Okay, unser Plan steht. Schauen wir ihn uns an. Ich habe abseits der Kamera schon etwas validiert,
00:29:47das zeige ich euch gleich. Meistens wird man einige Iterationen brauchen, um sicherzugehen, dass
00:29:52sein Verständnis von Phase eins mit dem PRD und dem, was man bauen will, übereinstimmt.
00:29:56Geht alle Abschnitte durch, das empfehle ich euch. Hier ist unser Implementierungsplan mit der Liste.
00:30:01Er ist sehr detailliert, was gut ist. Wir müssen jetzt, da wir uns auf ein einzelnes Feature fokussieren,
00:30:05spezifisch sein. Wir haben unsere Validierung mit der gesamten Validierungspyramide, wie ich sie nenne:
00:30:10Type-Checking, Linting und Unit-Testing. Und wir sind sehr spezifisch bei den End-to-End-Tests,
00:30:15also all den User Journeys, die der Agent durchlaufen soll, damit wir uns bei der Implementierung sicher fühlen.
00:30:20Das hat am Anfang nicht so gut geklappt. Deshalb hatte ich hier einen Follow-up-Prompt, nur um euch
00:30:24ein schnelles Beispiel zu geben, wie wir den Plan verfeinern können, bevor es an die Umsetzung geht.
00:30:29Und noch ein kleiner Geheimtipp – versprochen, gleich geht's an die Umsetzung –, aber das ist wichtig:
00:30:34Generell sind Coding-Agenten nicht besonders gut im Umgang mit Umgebungsvariablen.
00:30:38Sie verheddern sich. Wenn die Variablen vor der Implementierung nicht gesetzt sind, macht er nur
00:30:43ein paar Mock-Tests und sagt, alles sei validiert, obwohl es das gar nicht ist – das ist echt frustrierend.
00:30:48Deshalb erstelle ich meist parallel zur Planung eine .env.example und lasse ihn dort hineinschauen.
00:30:53So kennt er alle gesetzten Variablen, und ich richte meine Umgebungsvariablen ebenfalls ein.
00:30:57Natürlich zeige ich diese Datei nicht, da sie meine Geheimnisse für die Datenbank-URL und so enthält.
00:31:03Aber da ich das schon vorbereitet habe, können wir jetzt die gesamte Implementierung durchziehen.
00:31:09Er schreibt nicht nur den Code, sondern kann die Migration ausführen, Backend und Frontend starten,
00:31:13das Vercel Agent Browser CLI zum Testen nutzen und muss mich nicht unterbrechen,
00:31:19um Umgebungsvariablen zu setzen. Die Bühne ist also perfekt bereitet für die Implementierung,
00:31:23und ich bin mit dem Plan zufrieden. Jetzt denkt dran: Kontext-Reset, denn Kontext ist kostbar.
00:31:29Ich bin nun in einem brandneuen Kontextfenster, in dem ich meinen Execute-Befehl nutze.
00:31:34Der einzige Parameter ist der Plan, auf den ich verweise. Das ist alles, was er jetzt als Kontext braucht.
00:31:40Ich mache kurz Pause und komme wieder, wenn er alles durchlaufen hat. Wir delegieren jetzt
00:31:45das gesamte Coding an den Agenten und ernten den Lohn für die ganze Mühe bei der Planung.
00:31:51Ab diesem Punkt wird jeder PIV-Loop so schnell gehen, dank der Vorarbeit, die wir geleistet haben.
00:31:56Alles klar, unsere Implementierung ist abgeschlossen. Wir sehen an den Screenshots, dass er volle
00:32:01End-to-End-Tests gemacht hat. Man kann also sehr zuversichtlich sein, da der Agent sich bereits
00:32:06um alles gekümmert hat. Dennoch ist die menschliche Validierung wichtig. Wir arbeiten nach dem
00:32:11Prinzip “Vertrauen ist gut, Kontrolle ist besser”. Das Code-Review geht sehr ins Detail,
00:32:16daher mache ich das jetzt nicht, aber wenn ihr technisch versierter seid, ist das definitiv wichtig.
00:32:21Was ich aber machen werde, ist, die Anwendung live mit euch zu testen. Das Einzige,
00:32:26was ich off-camera gemacht habe, ist ein Konto zu erstellen, um die Basis-Authentifizierung zu prüfen.
00:32:30Ansonsten habe ich hier noch nichts gemacht. Und schaut euch das an: Das ist so cool!
00:32:35Es sieht schon richtig gut aus. Ich kann meinen Anzeigenamen festlegen, eine Bio schreiben wie
00:32:39“ein cooler KI-Builder”. Alles klar. Ich kann meine Avatar-URL setzen – ich habe gerade ein Bild
00:32:43bei Imgur hochgeladen. Okay, das sieht auch sehr gut aus. Ich kann Links hinzufügen, zum Beispiel
00:32:49YouTube unter https [youtube.com/atcolemedine](https://www.google.com/search?q=https://youtube.com/atcolemedine). Sehr schön. Noch ein Link: LinkedIn.
00:32:55Ich habe meine LinkedIn-URL gerade nicht parat, also nehme ich einfach linkedin.com. Egal.
00:32:59Cool. Und ich füge noch einen hinzu: X. Also einfach x.com. Sehr cool. Und ich kann diese
00:33:08per Drag-and-Drop verschieben, es wird sofort hier reflektiert. Ich kann nur den Editor sehen oder
00:33:11die Vorschau anpassen. Das Theme sieht noch nicht so toll aus, es ist einfach nur weiß, aber ich glaube,
00:33:18das kommt ohnehin erst in einer späteren Phase, da wir gerade erst das Fundament bauen.
00:33:24Vieles ist also noch nicht perfekt, aber als Startpunkt sieht es schon extrem gut aus. Dann
00:33:28klicke ich auf Speichern. Und okay, ja, laden wir die API-Endpunkte. Das läuft hier lokal auf
00:33:32Localhost. Da haben wir's: Änderungen erfolgreich gespeichert. Ich kann die Seite neu laden und
00:33:37alles ist noch da. Das ist fantastisch. Das sieht also wirklich richtig gut aus. Jetzt möchte ich,
00:33:42da wir ein gutes Fundament gebaut haben, ganz kurz über die Commit-Nachricht sprechen.
00:33:46Dafür habe ich einen weiteren Befehl namens “slash commit”. Der ist ganz simpel. Man kann ihn
00:33:51detaillierter machen, wenn man will, aber im Grunde gibt man dem Agenten Anweisungen, wie er
00:33:57eine Git-Nachricht erstellt, da wir diese als Langzeitgedächtnis nutzen werden. Wenn wir zurück
00:34:01zum Diagramm gehen: Das ist eine der goldenen Regeln. Deine Commit-Historie ist dein Langzeitgedächtnis.
00:34:06Wenn wir also unsere Nachrichten standardisieren – deshalb nutzen wir den Befehl “slash commit”
00:34:11hierhin zurück: Das ist eine dieser goldenen Regeln. Ihre Commit-Historie ist Ihr Langzeitgedächtnis.
00:34:17Wenn wir unsere Nachrichten also standardisieren – und deshalb nutzen wir den Befehl „/commit“,
00:34:22um das Ganze wiederverwendbar zu machen –, dann kann unser Agent beim Primen das Git-Log prüfen,
00:34:28um eine Historie dessen zu sehen, was wir zuletzt gebaut haben. Das dient als Orientierung für den nächsten Schritt
00:34:32und zeigt Muster auf, denen er folgen soll. Das ist die Stärke dieser Commit-Nachricht. Ich mache also „/commit“.
00:34:38Ich könnte „git commit“ zwar auch selbst ausführen, das ist kinderleicht, aber so stellen wir sicher,
00:34:43dass die Nachrichten für die Konsistenz immer gleich aufgebaut sind. In diesem Fall gibt es nichts zu commiten,
00:34:48da ich das bereits außerhalb der Aufnahme erledigt habe. Aber es ist wichtig, das nach jeder einzelnen
00:34:53Implementierung zu tun. Eine weitere extrem wichtige Sache, nachdem das Fundament unseres
00:34:58Projekts steht, ist die Einrichtung eines Frameworks für Regressionstests. Wir müssen sicherstellen,
00:35:04dass wir bei künftigen PIV-Schleifen – also wenn wir diesen Prozess für alle gewünschten Features
00:35:09immer wieder durchlaufen – das Bestehende nicht kaputtmachen. Darauf werde ich in einem anderen
00:35:14Video näher eingehen: auf all die Strategien, wie man so ein Test-Harness (Testumgebung) selbst
00:35:19implementiert. Im Grunde geht man zum Agenten und sagt: „Was wir jetzt haben, ist super, aber ich
00:35:25möchte auch, dass du in Aqua Voice alle End-to-End-Tests auflistest, die du durchgeführt hast,
00:35:31und packe das für mich in einen Befehl. So kann ich ihn später ausführen, wenn ich weitere Features
00:35:36gebaut habe, um sicherzugehen, dass alles, was wir zuvor erstellt haben, noch immer funktioniert.“
00:35:41So in der Art. Wie gesagt, ich gehe hier jetzt nicht zu tief ins Detail. Es dauert eine Weile,
00:35:46so etwas aufzusetzen und ein Test-Harness zu erstellen, aber so stellt man sicher,
00:35:50dass die Anwendung stabil bleibt, während man sie weiter ausbaut. Und es macht
00:35:55eine Menge Arbeit, das zu erstellen und zu pflegen, weil man es ständig aktualisieren muss.
00:36:00Es gibt jedoch auch Lösungen auf dem Markt, die einem das abnehmen. Die sind sehr leistungsfähig.
00:36:05Eine dieser Anwendungen ist QA-Tech. Sie nutzen KI-Test-Agenten, die sich mit Ihrer Codebasis mitentwickeln.
00:36:11Während Sie also immer mehr Funktionen hinzufügen, ergänzen sie weitere Testfälle, um sicherzustellen,
00:36:16dass Ihre Anwendung beim weiteren Ausbau einwandfrei funktioniert. Ich zeige Ihnen
00:36:22kurz ein Beispiel dafür. Der Einstieg ist kinderleicht. Gehen Sie zu QA-Tech, es gibt eine
00:36:26kostenlose Version zum Ausprobieren. Ich erstelle hier ein Projekt, und dann muss man nur
00:36:30die URL einfügen, die man testen möchte. Ich habe diese Anwendung – da ich bereits einen Commit
00:36:35gemacht und ihn auf GitHub gepusht habe – in nur einer Minute auf Vercel bereitgestellt. Das ist der einfachste Ort,
00:36:40um Seiten kostenlos zu hosten, besonders wenn man mit Next.js arbeitet. Ich gehe also zu meinem Projekt
00:36:45und füge diese URL ein. Es dauert dann einen Moment, das Projekt zu erstellen und den
00:36:50Code zu analysieren. Wir können dann einfach sagen: „Ich möchte ein gutes Test-Setup für meine Seite.
00:36:55Hilf mir, die ersten drei bis fünf Testfälle zu erstellen.“ Das ist ein bisschen wie bei Bolt.new oder Lovable,
00:36:59oder Sie geben einfach einen Prompt ein, was auch immer getan werden soll, um die Test-Suite für Ihr
00:37:04Projekt einzurichten. Aber das hier ist deren Empfehlung für den Start. Ich schicke das jetzt mal ab.
00:37:08Und es ist so cool, weil das Tool die Website wirklich durchforstet – also crawlt –, ohne dass man
00:37:12sich um die Infrastruktur kümmern muss. Es analysiert die Seite und schlägt Testfälle vor.
00:37:16Ich melde mich wieder, sobald das erledigt ist. Während der Ausführung möchte ich Ihnen nur kurz zeigen,
00:37:21dass meine Website in nur wenigen Minuten gecrawlt wurde. Ein ganz wichtiger Punkt ist,
00:37:25dass wir eine Möglichkeit brauchen, uns auf der Website einzuloggen. Die Automatisierung muss das können.
00:37:29Dafür gibt es eine Funktion, mit der wir Benutzername und Passwort eingeben können, die dann
00:37:34sicher gespeichert werden. Ich habe hier ein Testkonto erstellt. Das speichere ich jetzt.
00:37:38Das Tool nutzt diese Daten, um sich einzuloggen und die User-Journeys, die wir testen wollen, wirklich zu verstehen.
00:37:43Und da haben wir es. Es wurde eine Reihe von Testfällen generiert, und wir können
00:37:48sogar in jeden einzelnen reinklicken. Wir sehen genau den Ablauf, der durchlaufen wurde. Jetzt haben
00:37:53wir also all diese Tests eingerichtet. Und die KI-Test-Agenten in QA-Tech werden diese
00:37:59Testfälle im Laufe der Zeit weiterentwickeln, um sicherzustellen, dass weiterhin alles in unserer Codebasis abgedeckt ist.
00:38:04Je mehr Features wir bauen, desto cooler wird das Ganze. Natürlich können wir auch unser eigenes
00:38:09Befehlssystem für so etwas aufbauen. Aber ich schätze es sehr, eine Plattform zu haben, die mir das alles
00:38:14abnimmt. Im Hintergrund gibt es Agenten, mit denen ich chatten kann, um die Tests zu bearbeiten
00:38:19und sicherzustellen, dass ich wirklich alles per Regressionstest prüfe. Wenn also irgendwann
00:38:24etwas kaputtgeht, kann ich hierher kommen und sagen: „Es gibt gerade einen Bug in der Anwendung,
00:38:28erstelle einen Test, der fehlschlagen sollte.“ Dann behebe ich das Problem, und danach sollte
00:38:33der Test bestehen. Und das bringt uns zur letzten goldenen Regel: das Mindset der Systemevolution.
00:38:40Wann immer wir auf einen Fehler in unserem Code stoßen, ist es wichtig, nicht nur den Bug zu beheben,
00:38:46sondern zu überlegen, was wir in unserem KI-Layer korrigieren können, damit das nicht wieder passiert.
00:38:51Vielleicht müssen wir unseren Styleguide und die Regeln präziser formulieren oder neuen On-Demand-Kontext erstellen.
00:38:57Vielleicht brauchen wir mehr End-to-End-Tests, die in unseren Befehlen oder Workflows festgelegt sind,
00:39:02was auch immer nötig ist, um dieses Problem künftig zu vermeiden. Und wir können auch das tun,
00:39:06was ich gerade in QA-Tech gezeigt habe, oder unser eigenes System nutzen, um einen Test hinzuzufügen,
00:39:12der sicherstellt, dass dieser Fehler im Code nicht mehr auftritt. Die Stärke dabei ist – auch wenn es
00:39:16Zeit kostet –, dass wir unseren Coding-Agenten zuverlässiger und reproduzierbarer machen, indem er sich
00:39:21zusammen mit unserem Code weiterentwickelt. Wir machen also drei Dinge gleichzeitig: Während wir
00:39:26unseren Code aufbauen, entwickeln wir unsere Testbasis, unseren Code und unseren KI-Layer weiter.
00:39:32Und dieser Effekt potenziert sich mit der Zeit. Zurück zu Cloud Code, ich gebe Ihnen ein einfaches Beispiel.
00:39:37Eine Sache, die ich außerhalb der Aufnahme iteriert habe, war das Design der Seite.
00:39:43Wenn Sie zum Anfang des Videos zurückgehen, sehen Sie, dass ich ganz vergessen hatte, über den
00:39:47Stil zu sprechen – also wie die Seite genau aussehen sollte. Cloud Code hat also einfach eigene
00:39:51Annahmen getroffen. Und das sah nicht gerade berausend aus. Also musste ich das überarbeiten.
00:39:56Ich kann hier also sagen: „Zuerst gefiel mir das Frontend-Design nicht, das du implementiert hast.
00:40:01Wir haben definitiv nicht genug Infos im KI-Layer mit unseren Regeln und On-Demand-Kontexten für
00:40:06eine Style-Richtlinie. Ich möchte, dass du eine Meta-Analyse machst. Ändere noch nichts, aber hilf mir
00:40:10jetzt beim Überlegen: Was könnten wir an unseren Regeln oder dem On-Demand-Kontext ändern, hinzufügen
00:40:15oder aktualisieren, damit wir künftig konsistentere Stile haben, während wir die Analytics
00:40:20und die weiteren Seiten dieser Anwendung aufbauen?“
00:40:25Das Wichtige hierbei ist die Anweisung, noch nichts zu ändern,
00:40:29da ich über Änderungen am KI-Layer viel mehr Kontrolle haben möchte, während ich beim Code
00:40:34so viel wie möglich an den Agenten delegiere. Ich lasse ihn also mit mir überlegen,
00:40:39mache diese kleinen, gezielten Änderungen dann aber meist selbst. Sie sehen hier, dass er
00:40:44empfiehlt, eine „style.md“ im Referenz-Ordner zu erstellen. Also ein drittes Stück On-Demand-Kontext.
00:40:50Das würde wohl gut zur „components.md“ passen. Dort steht eher: „So sollten Dinge aufgebaut sein“,
00:40:54und die „styles.md“ erklärt dann: „So funktioniert es. So sollten wir mit Tailwind CSS
00:40:58und wahrscheinlich ShadCN arbeiten.“ Ich werde jetzt nicht die komplette Implementierung und
00:41:03Korrektur durchgehen, aber ich wollte Ihnen ein Beispiel geben: Wann immer wir auf Fehler stoßen oder
00:41:06etwas nicht ganz unseren Vorstellungen entspricht, wie hier beim Design, ist das immer eine
00:41:11Gelegenheit, den KI-Layer weiterzuentwickeln. So stimmen wir uns immer besser auf unseren Coding-Agenten
00:41:16für dieses spezifische Projekt ab, während wir es weiter ausbauen.
00:41:20Und das, mein Freund, ist der effektivste Teil des gesamten Prozesses – das Beste zum Schluss.
00:41:26Das war's eigentlich. Es ist wirklich ein denkbar einfacher Prozess, um zuverlässige und reproduzierbare
00:41:32Ergebnisse mit Coding-Agenten zu erzielen, wenn man neue Projekte startet. Denn nach der
00:41:35Systemevolution fangen wir wieder oben an und durchlaufen weitere PIV-Schleifen im exakt
00:41:40gleichen Prozess, um alle Phasen unseres PRD abzuarbeiten, Features hinzuzufügen und was auch immer
00:41:45nötig ist, um zum MVP zu gelangen. Und das führt uns dann zur Brownfield-Entwicklung,
00:41:49die ich in einem der nächsten Videos auf meinem Kanal behandeln werde. Wenn das alles für Sie
00:41:54gut klingt und Sie mit meiner Ressourcen-Bibliothek für Befehle und Regeln noch tiefer eintauchen wollen,
00:41:59um zu sehen, wie Systemevolution wirklich aussieht, dann schauen Sie sich unbedingt den
00:42:04Agentic Coding Kurs an, den ich in der Dynamics-Community anbiete. Den Link dazu finden Sie in der
00:42:08Beschreibung und im angepinnten Kommentar. Das ist alles, was ich momentan für Sie habe. Wenn Ihnen
00:42:13dieses Video gefallen hat und Sie sich auf weitere Inhalte zu Agentic Coding und das Video zur
00:42:17Brownfield-Entwicklung freuen, würde ich mich über ein Like und ein Abo freuen. Wir sehen uns
00:42:22im nächsten Video!