00:00:00Obwohl Claude Code eines der leistungsstärksten Tools für die KI-Entwicklung ist,
00:00:03warum scheitert es bei bestimmten Aufgaben? Angesichts der Funktionen, die Anthropic
00:00:08kürzlich veröffentlicht hat, und der Workflows, die wir darum herum aufgebaut haben, sieht die
00:00:12vorgesehene Nutzung heute ganz anders aus als noch vor wenigen Wochen. Unser Team nutzt Claude
00:00:16Code täglich – nicht nur für die Entwicklung, sondern auch für die Forschung, die Verwaltung unserer
00:00:21Produktions-Pipeline und die Automatisierung von Aufgaben abseits des Codens. Ich zeige euch jetzt alles,
00:00:26was wir herausgefunden haben. Anthropic hat vor kurzem den Befehl “Insights” für Claude Code hinzugefügt. Er analysiert
00:00:31alle vergangenen Claude-Code-Sitzungen über einen bestimmten Zeitraum und erstellt einen Bericht. Dieser Bericht
00:00:36analysiert euren Arbeitsstil, nimmt eure Arbeitsmuster humorvoll unter die Lupe, hebt Stärken sowie
00:00:40Schwächen hervor und gibt Tipps zur Verbesserung. Uns hat vor allem interessiert, wo
00:00:45etwas schiefgelaufen ist, denn daraus können wir am meisten lernen. Der Bericht zeigte
00:00:49die Bereiche mit der größten Reibung auf und schlug Funktionen vor, die den Workflow
00:00:54verbessern könnten. Wir erinnern uns zum Beispiel an eine Sitzung, in der der Haupt-Agent beim Einsatz von
00:00:58Agenten-Teams die Aufgabenliste immer wieder extrem lange abfragte. Dadurch dauerte die Sitzung zu lange,
00:01:03sodass wir sie manuell abbrechen mussten. Um das künftig zu verhindern, können wir diesen Prompt
00:01:07in die cloud.md kopieren. So fragt Claude bei der Nutzung von Multi-Agenten-Systemen nicht
00:01:12endlos nach, sondern handelt direkt. Wir können diese Tipps für künftige Workflows in unsere Projekte importieren,
00:01:17sodass unsere Erfahrung mit Claude Code mit der Zeit immer besser wird. Unser Team hat viel Zeit mit
00:01:22Claude Code verbracht, und der wichtigste Schritt ist nach wie vor, wie gut man dem Agenten den Kontext vermittelt.
00:01:26Das können in Unteraufgaben unterteilte Projektanforderungen oder Dokumentationen der verwendeten Frameworks und
00:01:30Bibliotheken sein. Mit dem richtigen Kontext sinkt die Fehlerquote praktisch auf Null,
00:01:35da der Agent genau weiß, worauf er reagieren muss. Bei der Projektdokumentation lassen wir lieber
00:01:39Claude schreiben, anstatt es selbst zu tun. Wir gaben Claude einen spezifischen Prompt mit allen
00:01:44nötigen Informationen, um die Projektidee in die erforderlichen Dokumente zu unterteilen. Wir baten ihn,
00:01:48vier Dokumente zu erstellen, die sich jeweils auf einen Aspekt der App konzentrieren. Das wichtigste ist das PRD,
00:01:53das Informationen zu den Projektanforderungen und zum Umfang enthält. Dann gibt es die architecture.md,
00:01:57in der Datenformatierung, Dateistruktur, APIs und alle Architekturdetails festgehalten sind.
00:02:02Hinzu kommt die decision.md mit allen Entscheidungen, die Claude während der Projekterstellung getroffen hat,
00:02:08als Referenz für später. Und das entscheidende Dokument ist die feature.json, die
00:02:12alle Funktionen in einem speziellen JSON-Format enthält. Sie liefert Details zu jedem Feature auf Token-effiziente
00:02:17Weise und enthält Kriterien für den Abschluss eines Features sowie einen “passes”-Schlüssel,
00:02:22um den Implementierungsstatus zu verfolgen. Da die große Aufgabe nun in kleinere Abschnitte unterteilt ist,
00:02:27müssen wir über das Context 7 MCP dokumentieren, welche Tools für die Umsetzung benötigt werden.
00:02:31Es enthält Dokumentationen für alle Bibliotheken und Frameworks und wird regelmäßig aktualisiert,
00:02:36damit Agenten die neuesten Infos abrufen können und die Lücke zwischen dem Modellwissen und
00:02:41dem aktuellen Stand geschlossen wird. Die Einrichtung des MCP dauert nur wenige Schritte. Einmal installiert,
00:02:46nutzt es die Tools von Context 7 und ruft Bibliotheksinformationen direkt ab. Dadurch kann es
00:02:50die aktuellste Dokumentation nutzen, Codefehler durch Versionskonflikte vermeiden und eine
00:02:55präzisere Implementierung liefern. Hooks sind ein weiteres, oft unterschätztes Feature. Die Hooks in Claude Code
00:03:00sind Shell-Befehle, die zu bestimmten Zeitpunkten im Lebenszyklus ausgeführt werden. Es gibt viele Typen,
00:03:05die etwa beim Sitzungsstart, vor oder nach der Nutzung eines Tools ausgelöst werden. Das Wichtigste
00:03:11ist jedoch die Konfiguration mit spezifischen Exit-Codes. Diese Codes sagen Claude Code, ob eine Aktion
00:03:16fortgesetzt, blockiert oder ignoriert werden soll. Ein Exit-Code von 0 bedeutet Erfolg, eine 2 steht für einen blockierenden Fehler.
00:03:22Wenn Claude also etwas Unerlaubtes versucht, wird Exit-Code 2 ausgelöst, er erhält eine Fehlermeldung
00:03:27und kann sich selbst korrigieren. Jeder andere Exit-Code ist nicht-blockierend, wird im Verbose-Modus angezeigt
00:03:32und die Ausführung geht weiter. Dieser Exit-Code 2 ist entscheidend, um das Verhalten des Agenten
00:03:37zu steuern. Wenn ihr schon mal Test-Driven Development mit Claude Code ausprobiert habt,
00:03:41ist euch vielleicht aufgefallen, dass er dazu neigt, die Tests zu ändern, wenn er sie nicht besteht.
00:03:46Um das zu verhindern, haben wir einen benutzerdefinierten Hook eingerichtet, der vor der Tool-Nutzung triggert.
00:03:50Dieser Hook schützt die Testskripte vor Änderungen. Wenn der Pfad, an dem gearbeitet wird, ein Testverzeichnis ist
00:03:55oder das Wort “Test” enthält, erscheint eine Fehlermeldung, dass Änderungen an Testordnern nicht erlaubt sind,
00:04:00und es wird Exit-Code 2 zurückgegeben. Mit diesem Hook passierte Folgendes: Als wir Claude anwiesen, Tests auszuführen
00:04:05und diese fehlschlugen, wollte er die Testdateien ändern. Das Skript blockierte ihn jedoch mit einer entsprechenden
00:04:10Meldung. So wurde verhindert, dass Claude Dateien editiert, die er nicht anfassen sollte. Wenn ihr
00:04:15schon mit MCPs gearbeitet habt, wisst ihr, dass sie das Kontextfenster aufblähen. Bei Großprojekten
00:04:19steigt die Zahl der verbundenen MCPs. Alle MCP-Tools landen im Kontextfenster und verbrauchen Platz.
00:04:25Genau dafür bietet Claude Code einen experimentellen MCP-CLI-Modus an. Wir haben das Flag für
00:04:31den experimentellen MCP-CLI auf “true” gesetzt. Danach verschwanden alle MCPs aus dem Kontext,
00:04:36und die MCP-Tools nahmen keinen Platz mehr im Kontextfenster ein. Die Frage war nur,
00:04:41wie man auf die Tools zugreift, wenn sie nicht mehr im Speicher liegen. Statt alle Tool-Schemas
00:04:45vorab zu laden, nutzt Claude Code “MCP CLI info” sowie “MCP CLI calls” und führt alle verbundenen
00:04:52MCPs über diese Tools via Bash aus. Mit dem gesetzten Flag rief er bei einem Prompt die MCP-Tools
00:04:56nicht direkt auf, sondern über die MCP-CLI-Werkzeuge als Bash-Befehle. Auf diese Weise
00:05:03wurde das benötigte Tool nur bei Bedarf geladen, was das Aufblähen des Kontexts verhinderte. Übrigens,
00:05:08wenn euch unsere Inhalte gefallen, drückt gerne den Hype-Button. Das hilft uns, mehr solcher Videos
00:05:13zu erstellen und mehr Menschen zu erreichen. In früheren Videos haben wir betont, wie wichtig Git ist,
00:05:18um die Arbeit der Agenten in der Versionskontrolle zu verfolgen. So kann man alles rückgängig machen, falls
00:05:23etwas falsch implementiert wird. Wir haben auch ein Video gemacht, in dem wir Git nutzten, um einen Agenten
00:05:28mit einer langfristigen Aufgabe zu betrauen. Wir nutzten parallele Agenten in verschiedenen Worktrees,
00:05:32damit sie alle Projektfeatures erstellen konnten, während sie voneinander isoliert blieben.
00:05:37Dadurch konnten wir ihre Ergebnisse später ohne Probleme zusammenführen, da Agenten,
00:05:41die an denselben Dateien arbeiten, Konflikte verursachen. Branches sind hier weniger geeignet, da sie
00:05:46oft zu Konflikten führen, weil sie dasselbe Arbeitsverzeichnis teilen – Worktrees hingegen nicht. Wir gaben
00:05:50also einen Prompt mit mehreren zu implementierenden Features vor und legten fest, dass jeder Agent
00:05:55in einem separaten Worktree arbeiten soll. Es wurde für jeden Worktree ein eigener Agent genutzt,
00:05:59der die Features isoliert umsetzte, selbst wenn sich die Aufgabenbeschreibungen teilweise überschnitten.
00:06:03Nachdem Claude alles korrekt in separaten Branches implementiert hatte, ließen wir die Ergebnisse
00:06:08zusammenführen, um alle Features in einem einzigen Arbeitsverzeichnis zu erhalten.
00:06:13Der Strict Mode ist essenziell, um die Fehlerprüfung auf den Agenten zu übertragen. Das sollte man für
00:06:18jede verwendete Sprache einrichten, da Bugs so schon beim Build-Vorgang und nicht erst zur Laufzeit
00:06:22beim Nutzer auffallen. Da wir primär TypeScript nutzen, setzen wir den Strict Mode in unseren Projekten
00:06:26immer auf “true”. Das aktiviert Prüfungen auf Null-Werte und implizite Typen, erzwingt strikte Typisierung
00:06:31und sorgt insgesamt für weniger Laufzeitfehler. Für KI-Agenten ist das wichtig, da sie keine eingebaute
00:06:36Möglichkeit haben, Laufzeitfehler abzufangen. Der Strict Mode minimiert dieses Risiko und stellt sicher,
00:06:41dass der Compiler diese Probleme löst. Agenten können sich dann auf Fehlerprotokolle im Terminal verlassen.
00:06:46Anstatt das Projekt nur durch Skripte testen zu lassen, empfiehlt sich eine zusätzliche Testebene.
00:06:51Man schreibt User Stories, die beschreiben, wie der Nutzer mit dem System interagiert, um den
00:06:56Testprozess nach Fertigstellung der App zu leiten. Wir definieren User Stories tatsächlich schon vor der
00:07:00Implementierung, da dies einen Standard setzt, dem die Umsetzung folgen muss. Per Prompt erstellte
00:07:05Claude mehrere Stories in einem Ordner, die alle Interaktionsmöglichkeiten mit dem System abdeckten.
00:07:10Jede Story beschreibt einen Aspekt der App, dessen Priorität und die Akzeptanzkriterien, gegen die
00:07:15der Agent testen soll. Die User Stories umfassten alle Szenarien, inklusive Best-Case und Edge-Cases.
00:07:21Diese Stories sagen den Agenten im Grunde, wie sie mit dem soeben gebauten System interagieren sollen.
00:07:26Mit den richtigen Anweisungen kann jeder Agent dieselben Prinzipien auf die von ihm entwickelte App
00:07:31anwenden und die Erwartungen der Nutzer besser erfüllen. Nachdem die Stories dokumentiert waren,
00:07:35baten wir Claude, diese nacheinander umzusetzen, beginnend mit dem optimalen Pfad aus jeder Story,
00:07:40wobei auch alle Sonderfälle berücksichtigt wurden. So gab es weniger Lücken in der Implementierung
00:07:45und insgesamt eine höhere Nutzerzufriedenheit. Alle Tipps, über die wir hier sprechen, sind als
00:07:50fertige Vorlagen in AI Labs Pro verfügbar. Für alle, die es noch nicht kennen: Das ist unsere vor kurzem
00:07:55gestartete Community. Dort findet ihr einsatzbereite Vorlagen, Prompts, Befehle und Skills, die ihr
00:08:00direkt in eure Projekte übernehmen könnt. Wenn euch unsere Arbeit gefällt und ihr den Kanal unterstützen
00:08:05wollt, ist das der beste Weg. Die Links findet ihr in der Beschreibung. Wir müssen Parallelisierung
00:08:10so oft wie möglich nutzen, denn so beschleunigt der Agent seinen Workflow und setzt Dinge um,
00:08:14die nicht aufeinander warten müssen. Claude erkennt zwar automatisch, ob eine Aufgabe parallel oder
00:08:20sequenziell laufen kann, aber es schadet nicht, selbst Agenten zu erstellen. Diese Agenten-Fähigkeiten
00:08:25haben wir auch in unserem letzten Video besprochen – wie man damit den Workflow beschleunigt.
00:08:29Diese Geschwindigkeit geht jedoch mit einem höheren Token-Verbrauch einher. Dennoch lohnt sich der Aufwand.
00:08:34Einmal arbeiteten wir an einer Recherche zu den Verbesserungen von Opus 4.6 mit demselben Modell,
00:08:39und es halluzinierte Fakten, obwohl wir Quellen bereitgestellt hatten. Es schrieb immer wieder falsche Infos,
00:08:43die wir mühsam korrigieren mussten. Die Recherche fühlte sich sinnlos an, da wir alles selbst fixen mussten.
00:08:49Um das künftig zu vermeiden, setzten wir parallele Agenten ein. Wir erstellten eine Recherche-Aufgabe,
00:08:54bei der wir die Agent-Swarm-Fähigkeiten von KimiK 2.5 und Claudes Agent-Swarm vergleichen wollten.
00:08:58Wir nutzten zwei Agenten: einen für die Recherche und einen weiteren zum Faktencheck. Die Grundidee
00:09:03war, beide Agenten miteinander kommunizieren zu lassen, um die Genauigkeit sicherzustellen, damit wir das
00:09:09nicht selbst tun müssen. In diesem Setup erledigt ein Agent die Aufgabe, während der andere sie kritisch
00:09:14analysiert – eine gegnerische Arbeitsweise. Der Recherche-Agent startete zuerst, und der Faktenchecker
00:09:19war blockiert, bis der erste Entwurf vorlag. Sobald dieser fertig war, begann die Überprüfung durch den
00:09:24Faktenchecker. Dieser fand sofort zahlreiche Ungenauigkeiten in den Daten des Recherche-Agenten,
00:09:28die wir sonst manuell hätten finden müssen. Beide Agenten blieben im Austausch und hielten den
00:09:33Prüfprozess straff. Ein Agent war nur dazu da, den anderen bei Fehlern zu korrigieren. Viele Aufgaben lassen
00:09:38sich so lösen – nicht nur Recherche, sondern auch Entwicklung, wo ein Agent ein Feature implementiert
00:09:43und ein anderer die Umsetzung gegen den Plan prüft. Laut dem Schöpfer von Claude Code arbeitet
00:09:47der Agent besser, wenn er eine Möglichkeit hat, seine eigene Arbeit zu verifizieren. Die Kernidee ist,
00:09:52dem Agenten “Augen” zu geben, also die Fähigkeit zu prüfen, ob ein Feature korrekt ist und den Erwartungen entspricht.
00:09:57Da diese Agenten terminalbasiert sind, können sie Probleme zur Laufzeit – besonders clientseitig – nicht
00:10:02erkennen. Wir nutzen mehrere Wege zur Verifizierung. Der erste ist die Claude Chrome Extension,
00:10:07die Browser-Tools wie DOM-Capturing, Konsolen-Logs und mehr bietet. Ein weiteres Tool ist das Puppeteer MCP.
00:10:12Dieses ist nützlich, da es in einem separaten Browser ohne eure bestehenden Sitzungen läuft, anders als die
00:10:17Chrome Extension. Es ist isoliert, stört eure aktuellen Sessions nicht und bietet so mehr Privatsphäre.
00:10:21Unsere bevorzugte Option ist jedoch der Agent Browser von Vercel. Das ist kein MCP, sondern ein CLI-Tool,
00:10:26das Agenten Browser-Test-Fähigkeiten verleiht. Es bietet Tools für Navigation, Screenshots und mehr.
00:10:31Im Gegensatz zu anderen Tools navigiert es nicht nur basierend auf Screenshots, sondern nutzt den
00:10:36Accessibility Tree, in dem jedes Element eine eindeutige Referenz hat. Das reduziert den kompletten DOM von
00:10:41Tausenden auf etwa 200 bis 400 Token – also viel effizienter. Das war das Hauptproblem der Chrome Extension,
00:10:46das der Agent Browser gelöst hat: Die Extension lädt den gesamten DOM in den Kontext und erschöpft ihn schnell.
00:10:51Wir haben zudem Anweisungen in der cloud.md hinzugefügt, damit Claude zuerst den Agent Browser nutzt,
00:10:56bevor er auf MCP-basierte Tests zurückgreift. Claude nutzt den Agent Browser also als primäre Methode.
00:11:01Aber es gibt noch einen weiteren Aspekt: Tests sind wichtig, aber man kann Fehler auch ohne Tests oder Code-Reviews
00:11:07reduzieren. Wir bitten Claude, Dinge vorherzusagen, die noch nicht passiert sind. Wir lassen ihn die Umsetzung
00:11:12prüfen und Bereiche identifizieren, in denen die App scheitern könnte. Das funktioniert, weil wir Claude die Chance geben,
00:11:17potenzielle Probleme durch Mustererkennung bekannter Fehler aus anderen Apps zu finden – selbst wenn wir sie
00:11:23selbst in Tests noch nicht bemerkt haben. Es zwingt Claude, den Code aus einem anderen Blickwinkel zu betrachten.
00:11:28Dabei identifizierte er kritische Lücken, die selbst unseren mehrstufigen Testprozess bestanden hatten,
00:11:33und fand 18 potenziell schädliche Probleme für die Produktion. Unsere bisherigen Tests hatten diese nicht
00:11:38erkannt. Sie konnten nur gefunden werden, indem wir Claude aus einer anderen Perspektive auf das Projekt
00:11:43blicken ließen. Damit sind wir am Ende dieses Videos. Wenn ihr den Kanal unterstützen wollt, damit wir
00:11:47weiterhin solche Videos machen können, nutzt gerne den Super Thanks Button unten. Wie immer vielen Dank
00:11:52fürs Zuschauen und wir sehen uns beim nächsten Mal!
00:11:57testing process and found 18 issues that could have been harmful in production. But our testing
00:12:01processes didn't catch them. They could only be identified when we pushed Claude to look at the
00:12:06project from another angle. That brings us to the end of this video. If you'd like to support the
00:12:10channel and help us keep making videos like this you can do so by using the super thanks button
00:12:15below. As always thank you for watching and I'll see you in the next one.