Claude Code Anti-Gravity: Das IDE-Setup, das meine Art zu entwickeln verändert hat

Ich war letzten Monat mitten in einem Kundenprojekt, als mein Terminal-only Claude Code Workflow an eine Wand stieß. Keine technische Wand — eine kognitive. Ich hatte sechs Terminal-Tabs offen, drei verschiedene Context Windows, die Tokens fraßen, und ich hatte den Überblick verloren, welcher Agent an welchem Feature arbeitete. Der Code war in Ordnung. Meine Fähigkeit, alles zu managen, brach zusammen.

In derselben Woche stieß ich auf Jack Roberts' ausführliches Tutorial über die Kombination von Claude Code mit Googles Anti-Gravity IDE, und es machte klick. Nicht einfach "oh, das ist nett" — eher "ich mache das seit Monaten falsch." Innerhalb eines Wochenendes hatte ich meinen gesamten AI-Coding-Workflow um diese Kombination herum umstrukturiert, und der Unterschied war so auffällig, dass ich darüber schreiben muss.

Der Teil, der mich am meisten überrascht hat: Das Terminal ist nicht der Flaschenhals. Das Terminal ist großartig. Claude Code in einem nackten Terminal ist nach wie vor eines der mächtigsten Entwicklungstools, die ich je benutzt habe. Der Flaschenhals war alles um das Terminal herum — Dateinavigation, Aufgabenverwaltung, Kontextmanagement, visuelles Feedback darüber, was die KI tatsächlich geändert hat. Anti-Gravity löste Probleme, von denen mir nicht bewusst war, dass ich sie kompensierte.

Aber die IDE ist nur die halbe Geschichte. Die eigentliche Transformation kam durch ein Prompting-Framework namens BLAST und ein Feature namens Claude Skills, das repetitive Workflows in One-Command-Automations verwandelte. Ich werde beides aufschlüsseln — und genau teilen, wie ich alles eingerichtet habe — aber zuerst musst du verstehen, warum der Standard-Claude-Code-Workflow ab einer gewissen Größe anfängt, Produktivität zu verlieren.

Warum Terminal-only Claude Code ab einer gewissen Größe nicht mehr funktioniert

Ich liebe das Terminal. Mein Ghostty-Setup sitzt perfekt, meine tmux-Konfiguration ist makellos, und ich kann durch eine Codebase navigieren, ohne die Maus anzufassen. Als ich also zum ersten Mal Leute darüber reden hörte, Claude Code in einer IDE laufen zu lassen, war meine erste Reaktion Skepsis. Warum visuellen Overhead zu etwas hinzufügen, das im Text perfekt funktioniert?

Die Antwort wurde offensichtlich, sobald ich mehr als zwei gleichzeitige Aufgaben managen musste.

Claude Code im Terminal ist phänomenal für fokussierte Single-Stream-Arbeit. Du gibst ihm eine Aufgabe, es führt aus, du reviewst, du iterierst. Dieser Zyklus ist straff und schnell. Das Problem taucht auf, wenn dein Projekt aus der Koordination mehrerer Agents besteht, dem Nachverfolgen von Änderungen über Dutzende Dateien hinweg und dem Wechseln zwischen verschiedenen Arbeitstypen — hier debuggen, dort ein neues Feature bauen, woanders Deployment konfigurieren.

Im Terminal lebt der gesamte Kontext in deinem Kopf. Du bist gleichzeitig Router, Aufgabenmanager und Qualitätstor. Nach etwa vier Stunden merke ich, dass meine Entscheidungsqualität spürbar nachlässt. Ich fange an, Änderungen abzunicken, die ich eigentlich genauer prüfen sollte. Ich vergesse, welche Dateien ein Agent vor zwanzig Minuten geändert hat. Ich verliere den Faden, was das ursprüngliche Ziel für einen bestimmten Feature Branch war.

Anti-Gravity verändert diese Gleichung, indem es diese kognitive Last in eine visuelle Oberfläche externalisiert. Dateiänderungen werden in einer Seitenleiste hervorgehoben. Aufgabenverwaltung findet in speziellen Panels statt. Mehrere Interaktionsmodi — Sidebar Chat, Terminal, Extensions — lassen dich das richtige Werkzeug für die spezifische Art von Arbeit wählen, die du gerade erledigst.

Es geht nicht darum, dass Anti-Gravity "besser" als ein Terminal ist. Es geht darum, zwei Tools zu kombinieren, die sich auf Weisen ergänzen, die ich nicht erwartet hatte. Das Terminal übernimmt die Ausführungsgeschwindigkeit. Die IDE übernimmt das Situationsbewusstsein.

Und diese Kombination ist wichtiger, als die meisten Entwickler denken, wegen etwas, das die meisten Claude Code Tutorials kaum erwähnen: die Degradation des Context Window.

Das Context-Window-Problem, vor dem dich niemand warnt

Hier ist eine Erkenntnis, die verändert hat, wie ich jede Claude Code-Sitzung strukturiere: Sobald dein Context Window ungefähr 50% Kapazität überschreitet, beginnt die Ausgabequalität nachzulassen. Nicht abstürzen — nachlassen. Die Antworten werden etwas weniger präzise. Der Code wird etwas generischer. Halluzinationen schleichen sich an den Rändern ein. Wenn du nicht genau aufpasst, merkst du es erst, wenn du Phantomfehlern nachjagst, die auf eine kontextaufgeblähte Sitzung zurückzuführen sind.

Ich habe das durch ein grobes, aber effektives Experiment bestätigt. Ich nahm dieselbe Codieraufgabe — einen REST API Endpoint mit Validierung, Fehlerbehandlung und Tests bauen — und führte sie bei verschiedenen Kontextauslastungsstufen durch. Bei 20% Kontext war der generierte Code straff, gut strukturiert und entsprach fast perfekt meinen Projektkonventionen. Bei 60% funktionierte der Code, verfehlte aber ein paar meiner Benennungsmuster und enthielt einige unnötige Imports. Bei 80% generierte er einen funktionierenden Endpoint, aber mit einem völlig anderen Fehlerbehandlungsmuster als dem, das im Rest der Codebase existierte.

Derselbe Prompt. Dasselbe Modell. Die einzige Variable war, wie viel Kontext bereits geladen war.

Deshalb ist die Disziplin "ein Fenster pro Aufgabe" so wichtig. Bevor ich das verstand, nutzte ich eine einzige Claude Code-Sitzung stundenlang, lud Datei um Datei, stellte Frage um Frage, baute Feature um Feature. Die erste Stunde war Magie. Nach drei Stunden verbrachte ich mehr Zeit damit, die KI zu korrigieren, als sie mir einsparte.

Anti-Gravity hilft hier, weil die Oberfläche den Kontextverbrauch sichtbar macht. Du kannst sehen, wie viel deines Windows bereits belegt ist, wodurch es selbstverständlich wird, eine Sitzung zu schließen und frisch zu starten, wenn es voll wird. Im Terminal ist der Kontextverbrauch unsichtbar — du spürst es erst, wenn die Ausgabe schlechter wird, und dann hast du bereits Zyklen verschwendet.

Die praktische Regel, die ich jetzt befolge: ein Context Window pro Aufgabe. Feature abschließen, Sitzung beenden, neue starten für das nächste Feature. Es fühlt sich verschwenderisch an — als würde man "Erinnerungen" wegwerfen, die die KI aufgebaut hat. Aber die Erinnerungen jenseits der 50% schaden mehr als sie nützen. Frischer Kontext mit einem klaren, fokussierten Prompt liefert bessere Ergebnisse als ein tiefer Kontext, der durch drei Stunden zusammenhangloser Gespräche verschmutzt ist.

Allein diese Erkenntnis hat mir mehr Zeit gespart als jedes einzelne Tool oder jede Technik. Aber der eigentliche Produktivitätsschub kam, als ich lernte, Prompts für diese Einschränkung mit dem BLAST-Framework zu strukturieren.

Das BLAST-System: Ein Prompting-Framework, das tatsächlich skaliert

Die meisten Prompting-Ratschläge laufen darauf hinaus: "Sei spezifisch" und "Gib Kontext." Nützlich, aber vage. Das BLAST-Framework — das Jack Roberts in seinem Anti-Gravity Tutorial demonstrierte — gibt diesem Rat eine konkrete Struktur, die ich konsistent über Projekte hinweg wiederholen kann.

BLAST steht für Blueprint, Linkages, Architecture, Stylize und Trigger. Jede Komponente adressiert einen spezifischen Fehlermodus, den ich bei KI-gestützter Entwicklung beobachtet habe. Lass mich durchgehen, wie ich jede tatsächlich verwende, denn die Theorie ist weniger interessant als die Praxis.

Blueprint ist die Projektspezifikation. Keine vage Beschreibung — ein strukturiertes Dokument, das beschreibt, was du baust, warum es existiert und wie Erfolg aussieht. Ich bewahre meine Blueprints in einer BLUEPRINT.md-Datei im Projektstamm auf und referenziere sie in meinen Claude Code System Prompts über Global Rules. Ein guter Blueprint beantwortet drei Fragen: Was macht dieses Projekt, für wen ist es, und was sind die nicht verhandelbaren technischen Einschränkungen?

Für ein kürzliches SaaS-Dashboard-Projekt umfasste mein Blueprint etwa 400 Wörter. Er spezifizierte die Benutzer-Persona (Operations-Manager bei mittelgroßen Logistikunternehmen), den Kernworkflow (Echtzeit-Monitoring von Lieferausnahmen), den Tech Stack (Next.js 15, Supabase, Tailwind) und drei Einschränkungen (muss in unter 2 Sekunden bei 3G laden, muss Offline-Modus unterstützen, muss sich in deren bestehendes Slack-Benachrichtigungssystem integrieren). Wenn Claude diesen Blueprint im Kontext hat, richtet sich jede generierte Komponente nach diesen Einschränkungen, ohne dass ich sie bei jedem Prompt erneut angeben muss.

Linkages definieren, wie Komponenten miteinander verbunden sind. Das ist der Teil, den die meisten Entwickler überspringen, und es ist der Teil, der die meiste Nacharbeit verursacht. Linkages beschreiben deinen Datenfluss, API-Verträge und Komponentenabhängigkeiten. Ich schreibe sie als einfache Beziehungskarten: "Die Dashboard-Komponente konsumiert Daten von der Exceptions-API, die die Supabase delivery_exceptions-Tabelle abfragt, die vom Webhook-Handler befüllt wird, der mit der Logistikplattform des Kunden verbunden ist."

Ohne Linkages baut Claude Komponenten, die isoliert funktionieren, aber nicht sauber zusammenpassen. Das Dashboard erwartet Daten in einer Form, während die API sie in einer anderen zurückgibt. Durch das vorherige Spezifizieren von Linkages habe ich Integrationsfehler um geschätzte 70% reduziert — ich habe keine harten Zahlen dazu, aber meine Git-Historie erzählt eine klare Geschichte von weniger "fix integration"-Commits, seitdem ich diesen Ansatz verwende.

Architecture umfasst deine Dateistruktur, Benennungskonventionen und Organisationsmuster. Wohin kommen neue Komponenten? Wie sind Routes strukturiert? Was ist das Testmuster? Ich gebe Claude eine Zusammenfassung der bestehenden Architektur, damit es die Codebase-Konventionen übernimmt, anstatt eigene zu erfinden.

Stylize behandelt den Codestil — aber nicht nur Formatierung. Es umfasst Muster wie Fehlerbehandlungskonventionen, Logging-Standards, wie du Async-Operationen strukturierst und ob du Komposition oder Vererbung bevorzugst. Meine Stylize-Sektion für die meisten Projekte ist eine Liste von etwa fünfzehn spezifischen Regeln, Dinge wie "verwende Early Returns statt verschachtelter Conditionals" und "alle API-Fehler müssen einen maschinenlesbaren Fehlercode und eine menschenlesbare Nachricht enthalten."

Trigger ist der eigentliche Prompt — die spezifische Anweisung für die aktuelle Aufgabe. Da die anderen vier Komponenten den Kontext handhaben, kann der Trigger kurz und fokussiert sein. "Baue den Delivery-Exceptions-API-Endpoint, der paginierte Ergebnisse mit Filterung nach Datumsbereich und Schweregrad zurückgibt." Das war's. Claude hat Blueprint, Linkages, Architektur und Stilregeln bereits geladen. Der Trigger zeigt nur auf die spezifische Arbeit.

Das ist es, was BLAST speziell innerhalb von Anti-Gravity zum Laufen bringt: Du kannst die Blueprint-, Linkages-, Architecture- und Stylize-Komponenten als Global oder Local Rules in der IDE-Konfiguration speichern. Global Rules gelten über alle Projekte hinweg. Local Rules leben in deinem Projektverzeichnis und gelten nur für diese Codebase. Der Trigger ist das Einzige, was du jedes Mal neu eintippst.

Diese Trennung — persistenter Kontext in Rules, frischer Kontext in Triggers — passt perfekt zur Context-Window-Einschränkung, die ich zuvor erwähnt habe. Deine Rules laden effizient, weil sie strukturiert und konsistent sind. Dein Trigger verbraucht minimalen Kontext, weil er das Projekt nicht erneut erklären muss. Das Ergebnis ist, dass mehr deines Context Window für die tatsächliche Codegenerierung verfügbar ist.

Ich habe eine Woche ohne BLAST gearbeitet, nachdem ich es übernommen hatte, nur um den Unterschied zu kalibrieren. Der Qualitätsunterschied war signifikant genug, dass ich innerhalb von zwei Tagen zurückging.

Aber ein Framework ist nur so gut wie deine Fähigkeit, es konsistent auszuführen, und da haben Claude Skills das Spiel für mich verändert.

Claude Skills: Repetitive Workflows in One-Command-Automations verwandeln

Wenn das BLAST-Framework die Strategie ist, sind Claude Skills die Taktik. Skills sind benutzerdefinierte Automations, die du einmal definierst und wiederholt auslöst — wiederverwendbare Anweisungen, denen Claude folgt, wenn sie aktiviert werden. Stell sie dir als gespeicherte Workflows vor, die deine Best Practices festhalten, damit du sie nicht in jeder Sitzung erneut erklären musst.

Es gibt zwei Arten von Skills, und die Unterscheidung ist wichtiger, als sie scheint.

Static Skills sind feste Anweisungssets. Sie ändern sich nicht zwischen den Ausführungen. "Wenn ich 'new component' sage, erstelle eine React-Komponente in /src/components/ mit einem TypeScript Interface für Props, einer Storybook-Datei und einer Testdatei mit Vitest" — das ist ein Static Skill. Dieselben Anweisungen, dieselbe Output-Struktur, jedes Mal. Ich habe etwa ein Dutzend davon für häufige Muster in meinen Projekten: API Endpoints erstellen, Datenbankmigrationen aufsetzen, Testsuiten scaffolden, Dokumentationsstubs generieren.

Dynamic Skills passen sich basierend auf Input oder Kontext an. Hier wird es richtig mächtig. Ein Dynamic Skill kann das aktuelle Projekt inspizieren, bestehende Dateien lesen, Entscheidungen auf Basis dessen treffen, was er findet, und je nach Situation unterschiedlich ausführen. Jack Roberts demonstrierte in seinem Tutorial einen, der mich umgehauen hat: einen Website-Klon- und Verbesserungsskill.

Der Skill funktionierte so: Gib ihm eine URL, und er nutzte Firecrawl, um die Struktur und den Inhalt der Seite zu scrapen, analysierte die Designmuster und baute die Seite dann mit Verbesserungen und modernem Tooling neu auf — alles über einen einzigen Befehl. Er zog die Nano Banana 2 API für verbesserte Bildgenerierung heran, wenn die Original-Bilder der Seite ein Upgrade brauchten, und nutzte ImageB für die Bildverarbeitung. Die gesamte Pipeline — Scrapen, Analysieren, Neugestalten, Assets generieren, Bauen — geschah in einer einzigen Skill-Aktivierung.

Ich habe eine vereinfachte Version davon für meine eigene Arbeit adaptiert. Meine Version klont keine Konkurrenzseiten (die Ethik dabei wird schnell undurchsichtig), aber sie analysiert eine bestehende Seite, die ich redesigne, extrahiert die Inhaltsstruktur und wichtige UI-Muster und generiert eine neue Implementierung, die den Inhalt beibehält, während die Oberfläche modernisiert wird. Das spart mir etwa zwei Stunden pro Seite im Vergleich zu manueller Analyse und Neuaufbau.

So habe ich diesen Skill in Anti-Gravity gebaut. Du öffnest den Skill Creator über die Claude Code-Oberfläche, und er führt dich durch die Definition des Auslösebegriffs des Skills, der Eingabeparameter, des Anweisungssets und aller externen Tools oder APIs, die er benötigt. Die Kernerkenntnis ist, die Skill-Erstellung wie das Schreiben einer sehr detaillierten Funktionssignatur zu behandeln: klare Eingaben, klare Ausgaben, klare Nebeneffekte.

Mein Redesign-Skill hat drei Eingaben: die URL der zu analysierenden Seite, den Ziel-Tech-Stack (standardmäßig Next.js + Tailwind) und eine Stilreferenz (normalerweise ein Screenshot oder Figma-Link der gewünschten Ästhetik). Das Anweisungsset sagt Claude, zuerst die Inhaltshierarchie der Quellseite zu analysieren, dann diese Hierarchie auf die Komponentenmuster des Ziel-Tech-Stacks zu mappen und dann die Komponenten mit angewandter Stilreferenz zu generieren. Jeder Schritt erzeugt Zwischenausgaben, die ich reviewen kann, bevor der nächste Schritt ausgeführt wird.

Der Zwischenreview-Schritt ist entscheidend. Ich habe auf die harte Tour gelernt, dass vollständig autonome Multi-Step-Skills in etwa 70% der Fälle beeindruckende Ergebnisse liefern und in den anderen 30% spektakulär scheitern. Das Hinzufügen von Review-Checkpoints zwischen den Schritten senkt die Fehlerquote auf nahezu null, auf Kosten einiger manueller Eingriffe. Jedes Mal den Trade-off wert.

Für das API-Key-Management über Skills hinweg — da viele von ihnen externe Services aufrufen — verwende ich Environment Variables, die in einer .env-Datei gespeichert sind, die Anti-Gravity automatisch lädt. Firecrawl API Key, Image-Generation API Keys, Datenbank-Connection-Strings — sie alle leben in Environment Variables statt hartcodiert in Skill-Definitionen. Das hält sensible Credentials aus deinen Skill-Konfigurationen heraus und macht es trivial, zwischen Entwicklungs- und Produktionsumgebungen zu wechseln.

Noch etwas über Skills, das ich erst mit der Zeit zu schätzen lernte: Sie bauen aufeinander auf. Ein Skill, der eine Komponente scaffoldet, kann mit einem Skill kombiniert werden, der Tests schreibt, der wiederum in einen Skill übergeht, der Dokumentation generiert. Eine Bibliothek aus kombinierbaren Skills aufzubauen ist wie eine Bibliothek aus Shell-Skripten aufzubauen, nur dass jedes Skript Zugriff auf eine KI-Reasoning-Engine hat, die sich an den aktuellen Kontext anpassen kann.

Die Entwickler, die ich kenne und die mit Claude Code am produktivsten sind, haben alle eines gemeinsam: eine reichhaltige Skill-Bibliothek, die sie über die Zeit aufgebaut haben. Die anfängliche Investition pro Skill beträgt vielleicht 20-30 Minuten. Die laufende Zeitersparnis multipliziert sich mit jeder Nutzung.

Den vollständigen Stack einrichten: Anti-Gravity, Claude Code und alles dazwischen

Gut, lass mich den tatsächlichen Einrichtungsprozess durchgehen, denn ein paar Details haben mich stolpern lassen und werden wahrscheinlich auch dich stolpern lassen.

Schritt 1: Claude Code Installation und Planwahl. Claude Code selbst ist kostenlos zum Einstieg, aber die kostenlose Version hat spürbare Einschränkungen bei Nutzungsvolumen und Modellzugang. Der Pro-Plan für $20/Monat schaltet höhere Rate Limits und Zugang zu Claude Opus frei, dem Modell, das ich für komplexe Architekturentscheidungen und Multi-File-Refactors verwende. Für die meisten Codieraufgaben macht Claude Sonnet die Arbeit gut, aber wenn ich das Modell brauche, um über Systemdesign nachzudenken oder einen besonders kniffligen Bug zu entwirren, ist Opus jeden Cent wert. Installiere die Claude Code App von Anthropics Website — es ist eine Standalone-Anwendung, die sich auch in dein Terminal integriert.

Schritt 2: Anti-Gravity IDE einrichten. Anti-Gravity ist Googles IDE, die auf der Standard-Code-Editing-Erfahrung aufsetzt, aber AI-native Features hinzufügt. Lade sie von Googles Developer-Tools-Seite herunter. Der wichtigste Integrationspunkt ist, dass Anti-Gravity Claude Code als Backend-AI-Provider erkennt, sodass du Claudes Reasoning-Fähigkeiten in Googles IDE-Oberfläche bekommst. Die IDE gibt dir direkt mehrere Interaktionsmodi.

Erstens gibt es den Sidebar Chat — ein persistentes Gesprächspanel, das offen bleibt, während du codest. Ich nutze es für schnelle Fragen, Code-Erklärungen und kleine Änderungen. Es verbraucht kein separates Context Window von deiner Hauptterminalsitzung, was wichtig für die Kontextmanagement-Strategie ist, die ich zuvor beschrieben habe.

Zweitens bekommst du Extensions, die Claude-betriebene Features zu bestimmten Dateitypen und Workflows hinzufügen. Die Extensions, die ich am meisten nutze, sind die Code-Review-Extension (hebt potenzielle Probleme hervor, bevor ich committe) und die Refactoring-Extension (schlägt Verbesserungen für ausgewählte Codeblöcke mit Ein-Klick-Anwendung vor).

Drittens — und hier passiert die Schwerstarbeit — hast du immer noch das Terminal direkt in die IDE eingebettet. Das ist deine vollständige Claude Code-Erfahrung, identisch mit dem, was du in einem Standalone-Terminal bekämst, aber jetzt umgeben vom visuellen Kontext deines Projekt-Dateibaums, offener Editoren und Aufgabenpanels.

Schritt 3: Global und Local Rules konfigurieren. Das knüpft direkt an das BLAST-Framework an. Global Rules gehen in dein Claude Code-Konfigurationsverzeichnis und gelten für jedes Projekt, an dem du arbeitest. Meine beinhalten allgemeine Codiervorlieben: TypeScript Strict Mode, Vorliebe für funktionale Muster, immer Fehlerbehandlung einschließen, selbstdokumentierenden Code schreiben. Local Rules leben in einem .claude/-Verzeichnis im Projektstamm und enthalten projektspezifische Anweisungen: den Tech Stack, Benennungskonventionen, API-Muster und alle Einschränkungen, die für diese Codebase einzigartig sind.

Anti-Gravity liest beide Regelsätze und wendet sie automatisch an, wenn du über einen beliebigen Modus mit Claude interagierst — Sidebar, Extension oder Terminal. Du konfigurierst Rules einmal, und jede Claude-Interaktion respektiert sie. Nie wieder dieselbe "vergiss nicht TypeScript Strict Mode zu verwenden"-Zeile in jeden Prompt kopieren.

Schritt 4: Modellauswahl. Anti-Gravity unterstützt mehrere Modelle, darunter Gemini 3.1 (Googles Modell) und Claude Opus. Ich habe beide ausführlich für Codieraufgaben getestet, und hier ist meine ehrliche Einschätzung: Gemini 3.1 ist stark bei Code Completion, Inline-Vorschlägen und schnellen Bearbeitungen. Claude Opus ist stärker bei Multi-File-Reasoning, Architekturentscheidungen und Aufgaben, die ein Verständnis der Beziehungen zwischen Komponenten erfordern. Mein Setup nutzt Gemini für den Sidebar Chat (schnelle, leichtgewichtige Interaktionen) und Claude Opus für Terminalsitzungen (tiefe, komplexe Arbeit). Das kannst du in den Modelleinstellungen von Anti-Gravity konfigurieren — verschiedene Modelle für verschiedene Interaktionsmodi.

Schritt 5: Externe Services verbinden. Hier wird das Setup richtig spannend. Anti-Gravity unterstützt Connectors für Gmail, Notion, Google Calendar und andere Services. Ich habe meinen Notion-Workspace verbunden, sodass Claude meine Projektdokumentation und Aufgaben-Boards direkt referenzieren kann. Ich habe meinen Kalender verbunden, sodass geplante Agents (dazu gleich mehr) auf Konflikte prüfen können, bevor sie Fokuszeitblöcke für langfristige Aufgaben einplanen.

Das Connector-Setup umfasst OAuth-Flows für jeden Service — Standardkram, nichts Exotisches. Der Gewinn ist, dass Claudes Kontext jetzt über deine Codebase hinaus in deine breitere Arbeitsumgebung reicht. Wenn ich Claude bitte, "die aktuellen Sprint-Aufgaben zu prüfen und das höchstpriorisierte Backend-Ticket auszuwählen," liest es direkt von meinem Notion-Board und erstellt einen Plan basierend auf der tatsächlichen Ticketbeschreibung. Kein Kopieren und Einfügen von Ticketdetails in Prompts mehr.

Schritt 6: GitHub- und Vercel-Integration. Diese beiden verdienen besondere Erwähnung, weil sie den Kreis von Entwicklung bis Deployment schließen. Die GitHub-Integration lässt Claude Branches erstellen, Änderungen committen und Pull Requests öffnen, ohne die IDE zu verlassen. Die Vercel-Integration lässt es Deployments triggern und Preview-URLs prüfen. Mein typischer Flow jetzt: Claude baut ein Feature in einer Terminalsitzung, erstellt einen PR über den GitHub-Connector, Vercel deployt automatisch eine Preview, und ich reviewe die Live-Preview neben dem Code-Diff. Alles innerhalb von Anti-Gravity. Die Deployment-Feedbackschleife, die früher 15 Minuten Tab-Wechsel kostete, dauert jetzt etwa 90 Sekunden.

Ein Stolperstein bei der GitHub-Integration: Stelle sicher, dass deine Git-Credentials über SSH Keys oder einen Credential Helper konfiguriert sind, bevor du die Verbindung herstellst. Beim ersten Versuch mit HTTPS-Credentials schlug der Auth-Flow still fehl und Claude meldete nur "unable to push" ohne brauchbaren Fehlerkontext. SSH Keys lösten es sofort.

Multi-Agent-Management: Parallele Workflows ausführen, ohne den Verstand zu verlieren

Dies ist der Abschnitt, den ich mir gewünscht hätte, als ich anfing, die Claude Code-Nutzung hochzuskalieren. Einen einzelnen Claude-Agent zu betreiben ist unkompliziert. Drei oder vier gleichzeitig auf verschiedenen Aufgaben innerhalb desselben Projekts zu betreiben ist der Punkt, an dem die Workflows der meisten Leute zusammenbrechen.

Das Kernproblem ist Koordination. Agent A refactort das Authentifizierungsmodul, während Agent B eine neue Dashboard-Komponente baut, die von der API des Auth-Moduls abhängt. Wenn beide gemeinsame Dateien ohne Kenntnis voneinander ändern, bekommst du im besten Fall Merge Conflicts und im schlimmsten Fall subtile Datenfluss-Bugs.

Anti-Gravitys Task Manager hilft hier, indem er ein Register aktiver Agents und ihres aktuellen Scopes führt. Du kannst sehen, an welchen Dateien jeder Agent arbeitet, welche Dateien durch aktive Änderungen "gesperrt" sind und welche Aufgaben in der Warteschlange stehen versus in Bearbeitung sind. Allein diese Sichtbarkeit verhindert die meisten Koordinationsfehler — ich kann sehen, dass Agent A gerade auth.ts ändert, und Agent Bs Aufgabe zurückhalten, bis diese Änderung abgeschlossen ist.

Die Agent-Scheduling-Funktion geht noch weiter. Ich kann eine Abfolge von Aufgaben definieren — "zuerst Auth refactoren, dann Dashboard bauen, dann Integrationstests schreiben" — und der Scheduler führt sie der Reihe nach aus, wobei relevanter Kontext zwischen den Phasen weitergegeben wird. Jede Aufgabe bekommt ein frisches Context Window (denke an die 50%-Degradationsregel), aber der Scheduler trägt eine Zusammenfassung weiter, was vorherige Aufgaben erreicht haben und welche Dateien sie geändert haben.

Für wirklich unabhängige Aufgaben — Arbeit an unverwandten Features, die keine Dateien oder APIs teilen — lasse ich Agents parallel ohne Scheduling laufen. Anti-Gravity kann gleichzeitige Sitzungen in separaten Terminal-Panels verwalten, jede mit eigenem Context Window und Aufgabenscope. Der Task Manager zeigt mir eine einheitliche Ansicht aller aktiven Arbeiten, sodass ich den Fortschritt überwachen kann, ohne zwischen Terminals zu wechseln.

Mein typisches Tagesmuster: Ich beginne den Morgen damit, drei bis vier Aufgaben basierend auf meinen Sprint-Prioritäten in den Scheduler einzureihen. Die ersten ein oder zwei sind sequentiell (normalerweise abhängige Features). Der Rest läuft parallel (unabhängige Features oder Bugfixes). Ich reviewe die Ausgabe, sobald jede Aufgabe abgeschlossen ist, genehmige oder fordere Überarbeitungen an, und der Scheduler geht zum nächsten Punkt über. An einem produktiven Tag generiert dieses Setup mehr gereviewten, getesteten, committeten Code bis zum Mittagessen, als ich früher an einem ganzen Tag manuellen Codierens produzierte.

Ein ehrlicher Vorbehalt: Der Multi-Agent-Ansatz erfordert gute Testabdeckung, um Integrationsprobleme aufzufangen. Ich führe die vollständige Testsuite nach Abschluss jeder Agent-Aufgabe aus und habe subtile Regressionen entdeckt, die isoliert betrachtet gut aussahen, aber beim Zusammenführen Probleme verursachten. Ohne Tests würden parallele Agents mehr Probleme schaffen als lösen. Das ist keine Abkürzung um Engineering-Disziplin herum — es ist ein Multiplikator darauf.

Was ich falsch gemacht habe und was ich anders machen würde

Ich möchte ehrlich über die Fehler sein, die ich beim Aufbau dieses Workflows gemacht habe, denn die Tutorials lassen alles glatt aussehen und die Realität hat Reibung.

Fehler eins: Zu früh zu viel automatisiert. Ich war begeistert von Claude Skills und versuchte, in der ersten Woche für alles Automations zu erstellen. Die meisten dieser frühen Skills waren zu starr — sie setzten bestimmte Projektstrukturen voraus und brachen, wenn ich sie auf anderen Codebases nutzte. Die Skills, die ich täglich verwende, sind die, die ich nach einem Monat manueller Wiederholung gebaut habe, als ich den Workflow, den ich automatisierte, tiefgreifend verstanden hatte. Baue Skills aus Mustern, die du manuell bewiesen hast. Versuche nicht, Workflows zu automatisieren, die du nicht mindestens zehnmal von Hand durchgeführt hast.

Fehler zwei: Das Context Window ignoriert, bis es zu spät war. Die ersten zwei Wochen behandelte ich die 50%-Kontextregel als Richtlinie statt als harte Grenze. "Ich drücke mich noch durch diese Sitzung, es ist fast fertig." Der Code, der in diesen überzogenen Sitzungen generiert wurde, kostete mich mehr Debugging-Zeit, als das Starten einer frischen Sitzung gekostet hätte. Jetzt behandle ich es als harte Regel. Wenn sich mein Kontext schwer anfühlt, schließe ich ab und starte neu. Jedes Mal.

Fehler drei: Das falsche Modell für die falsche Aufgabe verwendet. Ich nutzte standardmäßig Claude Opus für alles, weil es sich anfühlte, als würde das "beste" Modell die besten Ergebnisse liefern. Wie sich herausstellte, ist Opus Overkill für einfache Dateiänderungen und tatsächlich langsamer als Sonnet für unkomplizierte Aufgaben. Der Overhead von Opus' tieferem Reasoning fügt Latenz hinzu ohne proportionale Qualitätsverbesserung, wenn die Aufgabe "füge einen Lade-Spinner zu diesem Button hinzu" lautet. Stimme Modellkomplexität auf Aufgabenkomplexität ab. Nutze Opus für Architektur- und Designentscheidungen. Nutze Sonnet (oder sogar Gemini 3.1 für Inline Completions) für Implementierungsaufgaben, bei denen die Richtung bereits klar ist.

Fehler vier: Nicht genug in Local Rules investiert. Meine ersten Projekte mit diesem Setup hatten dünne Local Rules — vielleicht fünf oder sechs Zeilen. Die KI traf ständig Annahmen, die nicht zu meinen Projektkonventionen passten, und ich verbrachte Zeit mit Korrekturen. Jetzt umfassen meine Local-Rules-Dateien 40-60 Zeilen und enthalten spezifische Beispiele bevorzugter Muster neben den Regeln selbst. Claude ein Beispiel des gewünschten Fehlerbehandlungsmusters zu zeigen ist zehnmal effektiver als es in abstrakten Begriffen zu beschreiben.

Was ich anders machen würde, wenn ich von vorne anfinge: Ich würde den gesamten ersten Tag damit verbringen, Rules einzurichten und sie gegen Beispiel-Prompts zu testen, bevor ich echten Code schreibe. Die Konfigurationszeit amortisiert sich innerhalb der ersten Woche, aber ich war zu ungeduldig, sie vorzuziehen, und zahlte den Preis in Korrekturzyklen über einen Monat hinweg.

Die messbare Wirkung: Vorher und Nachher

Ich möchte konkrete Zahlen teilen, denn vage Behauptungen über "Produktivitätsgewinne" sind ohne Kontext nutzlos.

Vorher (Terminal-only Claude Code, kein Framework):

• Durchschnittliche Zeit, um ein CRUD-Feature mit Tests zu bauen: 3,5 Stunden
• Kontextbezogenes Debugging pro Woche: etwa 4 Stunden
• Fehlgeschlagene Deployments durch Integrationsprobleme: 2-3 pro Woche
• Skills/Automations: null, alles manuell

Nachher (Anti-Gravity + BLAST + Claude Skills, nach 6 Wochen):

• Durchschnittliche Zeit, um ein CRUD-Feature mit Tests zu bauen: 1,2 Stunden
• Kontextbezogenes Debugging pro Woche: unter 30 Minuten
• Fehlgeschlagene Deployments durch Integrationsprobleme: vielleicht 1 pro Monat
• Aktive Skills in meiner Bibliothek: 14 (8 Static, 6 Dynamic)

Die CRUD-Feature-Metrik ist der zuverlässigste Vergleich, weil es die am stärksten standardisierte Aufgabe ist. Andere Arbeit — komplexe Integrationen, neuartige Features, Architekturdesign — ist schwieriger zu benchmarken, weil keine zwei Aufgaben identisch sind. Aber subjektiv fühlt sich die Verbesserung konsistent über alle Aufgabentypen hinweg an.

Die kontextbezogene Debugging-Metrik ist die befriedigendste Verbesserung. Vier Stunden pro Woche "warum generiert Claude seltsamen Code" verschwanden fast vollständig, sobald ich die Ein-Fenster-pro-Aufgabe-Disziplin einführte und den Kontextverbrauch über Anti-Gravitys Oberfläche zu überwachen begann.

Die Deployment-Metrik verbesserte sich teilweise durch bessere Codequalität dank frischer Context Windows und teilweise, weil die GitHub-zu-Vercel-Integration Probleme in Preview-Deployments auffängt, bevor sie die Produktion erreichen. Beide Faktoren gehen auf das Anti-Gravity-Setup zurück.

Eine Metrik, die ich nicht quantifizieren kann, aber stark spüre: kognitive Erschöpfung. Der alte Workflow ließ mich gegen 15 Uhr mental erschöpft zurück. Alles im Kopf zu managen — welcher Agent was tat, welche Dateien sich änderten, wo ich aufgehört hatte — verbrauchte Energie, die in tatsächliche Engineering-Entscheidungen hätte fließen sollen. Das Auslagern dieses Managements an die IDE gab mentale Bandbreite frei, die ich am meisten in der Qualität meiner Nachmittagsarbeit bemerke.

Schnelle Gewinne, die du in der ersten Woche erwarten kannst: Die Global und Local Rules allein werden Claudes Ausgabequalität merklich verbessern. Der Sidebar Chat wird dein Context-Switching zwischen Browser-Dokumentation und Terminal reduzieren. Die Sichtbarkeit von Dateiänderungen fängt unbeabsichtigte Modifikationen auf, die Terminal-only-Workflows übersehen.

Langfristige Gewinne (Woche 3-6): Deine Skill-Bibliothek beginnt sich aufzubauen. Multi-Agent-Workflows werden praktikabel. Das BLAST-Framework wird zum Muskelgedächtnis statt zu einem bewussten Prozess. Das Gesamtsystem — IDE, Framework, Skills, Agents — fühlt sich wie ein einziges integriertes Tool an statt wie eine Sammlung von Teilen.

Wohin das meiner Meinung nach führt

Vor sechs Monaten schrieb ich Claude Code Prompts in einem Terminal und fühlte mich produktiv. Jetzt orchestriere ich mehrere KI-Agents über eine visuelle Oberfläche mit Custom Automations und integrierten Deployment-Pipelines. Das Tempo der Veränderung in diesem Bereich ist ehrlich gesagt desorientierend, und ich glaube, wir befinden uns noch in den Anfangskapiteln.

Die Kombination von Claude Codes Reasoning-Fähigkeiten mit Anti-Gravitys visueller Verwaltungsschicht deutet auf eine Zukunft hin, in der die IDE nicht nur ein Ort zum Codeschreiben ist — sie ist eine Kommandozentrale für die Steuerung von KI-Agents, die in deinem Auftrag Code schreiben. Deine Aufgabe verschiebt sich von der Implementierung hin zu Spezifikation, Review und Orchestrierung.

Diese Verschiebung macht manchen Entwicklern Angst. Das verstehe ich. Aber aus meiner Perspektive macht sie Engineering-Fähigkeiten nicht weniger wertvoll. Sie macht sie wertvoller. Die Entwickler, die Systemdesign verstehen, die klare Spezifikationen schreiben können, die wissen, wie man ein Projekt für Wartbarkeit strukturiert — sie sind diejenigen, die am meisten aus diesen Tools herausholen. Die KI übernimmt das Tippen. Du übernimmst das Denken.

Wenn du eine Sache aus diesem Beitrag mitnimmst, dann die Context-Window-Disziplin. Ein Fenster pro Aufgabe. Frischer Kontext für frische Arbeit. Alles andere, was ich beschrieben habe, baut auf diesem Fundament auf, und es kostet nichts, es jetzt sofort in deinem bestehenden Setup umzusetzen.

Die Tools werden sich weiterentwickeln. Google wird Updates für Anti-Gravity ausliefern. Anthropic wird Claudes Coding-Fähigkeiten verbessern. Neue Frameworks und Techniken werden entstehen. Aber das Prinzip, den Kontext deiner KI wie eine knappe Ressource zu verwalten — das ist eine dauerhafte Erkenntnis. Und es ist diejenige, die den größten Unterschied in meiner Arbeit gemacht hat.

Wie sieht dein Claude Code Workflow gerade aus? Ich bin ehrlich neugierig, ob andere unterschiedliche Lösungen für das Kontextmanagement-Problem gefunden haben, oder ob der Ein-Fenster-pro-Aufgabe-Ansatz so universell ist, wie er es in meiner Erfahrung war.

Lass uns zusammenarbeiten

Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Custom Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io