Claude Code Anti-Gravity: De IDE-setup die mijn manier van bouwen veranderde

Ik was vorige maand halverwege een klantproject toen mijn terminal-only Claude Code workflow vastliep. Geen technische muur — een cognitieve. Ik had zes terminaltabs open, drie verschillende context windows die tokens vraten, en ik was het overzicht kwijt welke agent aan welke feature werkte. De code was prima. Mijn vermogen om alles te beheren viel uit elkaar.

Diezelfde week stuitte ik op Jack Roberts' uitgebreide tutorial over het combineren van Claude Code met Google's Anti-Gravity IDE, en er viel iets op z'n plek. Niet zomaar "oh, dat is handig" — meer zoiets als "ik doe dit al maanden verkeerd." Binnen een weekend had ik mijn hele AI-codeerworkflow herstructureerd rond deze combinatie, en het verschil was zo opvallend dat ik erover moest schrijven.

Het deel dat me het meest verraste: de terminal is niet het knelpunt. De terminal is geweldig. Claude Code in een kale terminal is nog steeds een van de krachtigste ontwikkeltools die ik ooit heb gebruikt. Het knelpunt was alles om de terminal heen — bestandsnavigatie, taakbeheer, contextmanagement, visuele feedback over wat de AI daadwerkelijk had aangepast. Anti-Gravity loste problemen op waarvan ik niet doorhad dat ik ze aan het compenseren was.

Maar de IDE is slechts de helft van het verhaal. De echte transformatie kwam door een prompting-framework genaamd BLAST en een functie genaamd Claude Skills waarmee repetitieve workflows in one-command-automations veranderden. Ik bespreek beide — en deel precies hoe ik alles heb opgezet — maar eerst moet je begrijpen waarom de standaard Claude Code workflow productiviteit begint te lekken op schaal.

Waarom terminal-only Claude Code op schaal niet meer werkt

Ik ben dol op de terminal. Mijn Ghostty-setup zit perfect, mijn tmux-configuratie is vlekkeloos, en ik kan door een codebase navigeren zonder de muis aan te raken. Dus toen ik voor het eerst mensen hoorde praten over het draaien van Claude Code in een IDE, was mijn eerste reactie scepsis. Waarom visuele overhead toevoegen aan iets dat perfect werkt in tekst?

Het antwoord werd duidelijk zodra ik meer dan twee gelijktijdige taken moest beheren.

Claude Code in een terminal is fenomenaal voor gefocust, single-stream werk. Je geeft het een taak, het voert uit, je reviewt, je itereert. Die cyclus is strak en snel. Het probleem ontstaat wanneer je project bestaat uit het coördineren van meerdere agents, het bijhouden van wijzigingen in tientallen bestanden, en het schakelen tussen verschillende soorten werk — hier debuggen, daar een nieuwe feature bouwen, ergens anders deployment configureren.

In een terminal leeft al die context in je hoofd. Jij bent de router, de taakmanager en de kwaliteitspoort tegelijk. Na ongeveer vier uur hiervan merk ik dat mijn besluitvaardigheid zichtbaar afneemt. Ik begin wijzigingen goed te keuren die ik eigenlijk beter zou moeten bekijken. Ik vergeet welke bestanden een agent twintig minuten geleden heeft gewijzigd. Ik raak de draad kwijt van wat het oorspronkelijke doel was voor een bepaalde feature branch.

Anti-Gravity verandert deze vergelijking door die cognitieve belasting te externaliseren naar een visuele interface. Bestandswijzigingen worden uitgelicht in een zijbalk. Taakbeheer vindt plaats in speciale panelen. Meerdere interactiemodi — sidebar chat, terminal, extensies — laten je het juiste gereedschap kiezen voor het specifieke type werk dat je op dat moment doet.

Dit gaat er niet om dat Anti-Gravity "beter" is dan een terminal. Het gaat om het combineren van twee tools die elkaar aanvullen op manieren die ik niet had verwacht. De terminal handelt de uitvoeringssnelheid af. De IDE zorgt voor situationeel bewustzijn.

En die combinatie is belangrijker dan de meeste ontwikkelaars denken, vanwege iets dat de meeste Claude Code tutorials nauwelijks noemen: degradatie van het context window.

Het context window-probleem waar niemand je voor waarschuwt

Hier is een feit dat veranderde hoe ik elke Claude Code-sessie opbouw: zodra je context window ruwweg 50% capaciteit overschrijdt, begint de outputkwaliteit af te nemen. Niet crashen — afnemen. De antwoorden worden iets minder precies. De code wordt iets generieker. Hallucinaties sluipen erin langs de randen. Als je niet goed oplet, merk je het pas als je bezig bent met het debuggen van fantoomfouten die terug te leiden zijn naar een context-opgeblazen sessie.

Ik heb dit bevestigd door een ruw maar effectief experiment. Ik nam dezelfde codeertaak — een REST API endpoint bouwen met validatie, foutafhandeling en tests — en voerde het uit bij verschillende context-bezettingsniveaus. Bij 20% context was de gegenereerde code strak, goed gestructureerd en kwam bijna perfect overeen met mijn projectconventies. Bij 60% werkte de code, maar miste een paar van mijn naamgevingspatronen en bevatte enkele onnodige imports. Bij 80% genereerde het een werkend endpoint, maar met een compleet ander foutafhandelingspatroon dan wat al bestond in de rest van de codebase.

Dezelfde prompt. Hetzelfde model. De enige variabele was hoeveel context er al geladen was.

Dit is waarom de discipline van "één venster per taak" zo belangrijk is. Voordat ik dit begreep, gebruikte ik een enkele Claude Code-sessie urenlang, laadde bestand na bestand, stelde vraag na vraag, bouwde feature na feature. Het eerste uur was magie. Na drie uur besteedde ik meer tijd aan het corrigeren van de AI dan die me bespaarde.

Anti-Gravity helpt hier omdat de interface het contextverbruik zichtbaar maakt. Je kunt zien hoeveel van je window al verbruikt is, waardoor het vanzelfsprekend wordt om een sessie te sluiten en opnieuw te beginnen wanneer het vol begint te raken. In een terminal is contextgebruik onzichtbaar — je voelt het pas als de output slechter wordt, en dan heb je al cycli verspild.

De praktische regel die ik nu hanteer: één context window per taak. Rond een feature af, sluit de sessie, begin een nieuwe voor de volgende feature. Het voelt verspillend — alsof je "geheugen" weggooit dat de AI heeft opgebouwd. Maar het geheugen voorbij 50% doet meer kwaad dan goed. Verse context met een heldere, gefocuste prompt levert betere resultaten op dan een diepe context die vervuild is door drie uur ongerelateerde gesprekken.

Die realisatie alleen al bespaarde me meer tijd dan welke tool of techniek dan ook. Maar de echte productiviteitswinst kwam toen ik leerde hoe ik prompts moest structureren voor deze beperking met het BLAST-framework.

Het BLAST-systeem: een prompting-framework dat daadwerkelijk schaalt

Het meeste advies over prompting komt neer op "wees specifiek" en "geef context." Nuttig, maar vaag. Het BLAST-framework — dat Jack Roberts demonstreerde in zijn Anti-Gravity tutorial — geeft dat advies een concrete structuur die ik consistent kan herhalen over projecten heen.

BLAST staat voor Blueprint, Linkages, Architecture, Stylize en Trigger. Elk onderdeel adresseert een specifieke foutmodus die ik heb gezien bij AI-ondersteunde ontwikkeling. Laat me doorlopen hoe ik elk onderdeel daadwerkelijk gebruik, want de theorie is minder interessant dan de praktijk.

Blueprint is de projectspecificatie. Geen vage beschrijving — een gestructureerd document dat beschrijft wat je bouwt, waarom het bestaat en hoe succes eruitziet. Ik bewaar mijn blueprints in een BLUEPRINT.md-bestand in de projectroot en verwijs ernaar in mijn Claude Code system prompts via global rules. Een goede blueprint beantwoordt drie vragen: wat doet dit project, voor wie is het, en wat zijn de niet-onderhandelbare technische beperkingen?

Voor een recent SaaS-dashboardproject was mijn blueprint ongeveer 400 woorden. Het specificeerde de gebruikerspersona (operationsmanagers bij middelgrote logistieke bedrijven), de kernworkflow (realtime monitoring van leveringsuitzonderingen), de tech stack (Next.js 15, Supabase, Tailwind) en drie beperkingen (moet laden onder 2 seconden op 3G, moet offline modus ondersteunen, moet integreren met hun bestaande Slack-notificatiesysteem). Wanneer Claude deze blueprint in context heeft, sluit elk gegenereerd component aan bij deze beperkingen zonder dat ik ze bij elke prompt opnieuw hoef te specificeren.

Linkages definiëren hoe componenten met elkaar verbonden zijn. Dit is het deel dat de meeste ontwikkelaars overslaan, en het is het deel dat het meeste herwerk veroorzaakt. Linkages beschrijven je dataflow, API-contracten en componentafhankelijkheden. Ik schrijf ze als eenvoudige relatiemappen: "Het dashboardcomponent consumeert data van de exceptions API, die de Supabase delivery_exceptions-tabel bevraagt, die gevuld wordt door de webhook handler die verbonden is met het logistieke platform van de klant."

Zonder linkages bouwt Claude componenten die op zichzelf werken, maar niet schoon op elkaar aansluiten. Het dashboard verwacht data in de ene vorm terwijl de API het in een andere retourneert. Door linkages vooraf te specificeren heb ik integratiebugs met naar schatting 70% verminderd — ik heb geen harde cijfers, maar mijn git-historie vertelt een duidelijk verhaal van minder "fix integration"-commits sinds ik deze aanpak gebruik.

Architecture omvat je bestandsstructuur, naamgevingsconventies en organisatiepatronen. Waar gaan nieuwe componenten naartoe? Hoe zijn routes gestructureerd? Wat is het testpatroon? Ik geef Claude een samenvatting van de bestaande architectuur zodat het aansluit bij de codebase-conventies in plaats van eigen conventies te verzinnen.

Stylize behandelt codestijl — maar niet alleen opmaak. Het omvat patronen zoals foutafhandelingsconventies, logging-standaarden, hoe je async-operaties structureert, en of je de voorkeur geeft aan compositie of overerving. Mijn stylize-sectie voor de meeste projecten is een lijst van ongeveer vijftien specifieke regels, dingen als "gebruik early returns in plaats van geneste conditionals" en "alle API-fouten moeten een machine-leesbare foutcode en een menselijk leesbaar bericht bevatten."

Trigger is de daadwerkelijke prompt — de specifieke instructie voor de huidige taak. Omdat de andere vier componenten de context afhandelen, kan de trigger kort en gefocust zijn. "Bouw het delivery exceptions API endpoint dat gepagineerde resultaten retourneert met filtering op datumbereik en ernstniveau." Dat is het. Claude heeft de blueprint, linkages, architectuur en stijlregels al geladen. De trigger wijst het alleen naar het specifieke werk.

Dit is wat BLAST specifiek binnen Anti-Gravity laat werken: je kunt de Blueprint, Linkages, Architecture en Stylize-componenten opslaan als global of local rules in de IDE-configuratie. Global rules gelden voor alle projecten. Local rules staan in je projectmap en gelden alleen voor die codebase. De Trigger is het enige dat je elke keer vers intypt.

Deze scheiding — persistente context in rules, verse context in triggers — sluit perfect aan op de context window-beperking die ik eerder noemde. Je rules laden efficiënt omdat ze gestructureerd en consistent zijn. Je trigger gebruikt minimale context omdat het het project niet opnieuw hoeft uit te leggen. Het resultaat is meer van je context window beschikbaar voor daadwerkelijke codegeneratie.

Ik heb een week zonder BLAST gewerkt nadat ik het had aangenomen, puur om het verschil te kalibreren. Het kwaliteitsverschil was aanzienlijk genoeg dat ik binnen twee dagen terugging.

Maar een framework is alleen zo goed als je vermogen om het consistent uit te voeren, en dat is waar Claude Skills het spel voor mij veranderden.

Claude Skills: repetitieve workflows omzetten in one-command-automations

Als het BLAST-framework de strategie is, zijn Claude Skills de tactiek. Skills zijn aangepaste automations die je eenmalig definieert en herhaaldelijk activeert — herbruikbare instructies die Claude volgt wanneer ze worden geactiveerd. Zie ze als opgeslagen workflows die je best practices vastleggen, zodat je ze niet bij elke sessie opnieuw hoeft uit te leggen.

Er zijn twee typen skills, en het onderscheid is belangrijker dan het lijkt.

Static skills zijn vaste instructiesets. Ze veranderen niet tussen uitvoeringen. "Wanneer ik 'new component' zeg, maak een React-component aan in /src/components/ met een TypeScript interface voor props, een Storybook-bestand en een testbestand met Vitest" — dat is een static skill. Dezelfde instructies, dezelfde outputstructuur, elke keer. Ik heb er een stuk of twaalf voor veelvoorkomende patronen in mijn projecten: API endpoints aanmaken, database migrations opzetten, testsuites scaffolden, documentatiestubs genereren.

Dynamic skills passen zich aan op basis van input of context. Hier wordt het echt krachtig. Een dynamic skill kan het huidige project inspecteren, bestaande bestanden lezen, beslissingen nemen op basis van wat het vindt, en anders uitvoeren afhankelijk van de situatie. Jack Roberts demonstreerde er een in zijn tutorial die me verbijsterde: een website-kloon- en verbeteringsskill.

De skill werkte als volgt: geef het een URL, en het gebruikte Firecrawl om de structuur en inhoud van de site te scrapen, analyseerde de designpatronen, en herbouwde vervolgens de site met verbeteringen met moderne tooling — allemaal via een enkel commando. Het haalde de Nano Banana 2 API erbij voor verbeterde beeldgeneratie wanneer de originele afbeeldingen van de site een upgrade nodig hadden, en gebruikte ImageB voor beeldverwerking. De gehele pipeline — scrapen, analyseren, herontwerpen, assets genereren, bouwen — gebeurde in één skill-activatie.

Ik heb een vereenvoudigde versie hiervan aangepast voor mijn eigen werk. Mijn versie kloont geen concurrentsites (de ethiek daarvan wordt snel onduidelijk), maar het analyseert wel een bestaande pagina die ik aan het herontwerpen ben, extraheert de contentstructuur en belangrijke UI-patronen, en genereert een nieuwe implementatie die de content behoudt terwijl de interface wordt gemoderniseerd. Het bespaart me ongeveer twee uur per pagina vergeleken met handmatige analyse en herbouw.

Zo heb ik die skill gebouwd in Anti-Gravity. Je opent de Skill Creator via de Claude Code interface, en deze leidt je door het definiëren van de triggerzin van de skill, invoerparameters, instructieset en eventuele externe tools of API's die nodig zijn. De kernles is om het aanmaken van skills te behandelen als het schrijven van een zeer gedetailleerde functiesignatuur: duidelijke inputs, duidelijke outputs, duidelijke bijeffecten.

Mijn redesign-skill heeft drie inputs: de URL van de pagina om te analyseren, de doel-tech stack (standaard Next.js + Tailwind) en een stijlreferentie (meestal een screenshot of Figma-link van de gewenste esthetiek). De instructieset vertelt Claude om eerst de contenthiërarchie van de bronpagina te analyseren, vervolgens die hiërarchie te mappen naar de componentpatronen van de doel-tech stack, en daarna de componenten te genereren met de stijlreferentie toegepast. Elke stap produceert tussentijdse output die ik kan reviewen voordat de volgende stap wordt uitgevoerd.

De tussentijdse reviewstap is cruciaal. Ik heb op de harde manier geleerd dat volledig autonome multi-step skills in ongeveer 70% van de gevallen indrukwekkende resultaten opleveren en in de overige 30% spectaculair falen. Het toevoegen van reviewcheckpoints tussen stappen verlaagt het faalpercentage naar vrijwel nul, ten koste van enige handmatige interventie. Elke keer de moeite waard.

Voor API key management over skills heen — aangezien veel van hen externe services aanroepen — gebruik ik environment variables opgeslagen in een .env-bestand dat Anti-Gravity automatisch laadt. Firecrawl API key, image generation API keys, database connection strings — ze staan allemaal in environment variables in plaats van hardcoded in skill-definities. Dit houdt gevoelige credentials uit je skill-configuraties en maakt het triviaal om te wisselen tussen development- en productieomgevingen.

Nog iets over skills dat ik pas na een tijdje leerde waarderen: ze stapelen zich op. Een skill die een component scaffoldt kan worden gecombineerd met een skill die tests schrijft, die weer doorketent naar een skill die documentatie genereert. Een bibliotheek van combineerbare skills opbouwen is als het opbouwen van een bibliotheek met shellscripts, behalve dat elk script toegang heeft tot een AI-redeneermotor die zich kan aanpassen aan de huidige context.

De ontwikkelaars die ik ken die het meest productief zijn met Claude Code hebben allemaal één ding gemeen: een rijke skill-bibliotheek die ze in de loop der tijd hebben opgebouwd. De initiële investering per skill is misschien 20-30 minuten. De doorlopende tijdsbesparing vermenigvuldigt zich bij elk gebruik.

De volledige stack opzetten: Anti-Gravity, Claude Code en alles daartussenin

Oké, laat me het daadwerkelijke installatieproces doorlopen, want er zijn een paar details die mij struikelen en die jou waarschijnlijk ook zullen struikelen.

Stap 1: Claude Code installatie en abonnementskeuze. Claude Code zelf is gratis om mee te beginnen, maar de gratis versie heeft aanzienlijke beperkingen op gebruiksvolume en modeltoegang. Het Pro-abonnement van $20/maand ontgrendelt hogere rate limits en toegang tot Claude Opus, het model dat ik gebruik voor complexe architectuurbeslissingen en multi-file refactors. Voor de meeste codeertaken doet Claude Sonnet het prima, maar wanneer ik het model nodig heb om na te denken over systeemontwerp of een bijzonder lastige bug te ontrafelen, is Opus elke cent waard. Installeer de Claude Code app van Anthropic's website — het is een standalone applicatie die ook integreert in je terminal.

Stap 2: Anti-Gravity IDE opzetten. Anti-Gravity is Google's IDE die bovenop de standaard code-editing-ervaring zit, maar AI-native features toevoegt. Download het van Google's developer tools-pagina. Het belangrijkste integratiepunt is dat Anti-Gravity Claude Code herkent als backend AI-provider, zodat je Claude's redeneervaardigheden krijgt binnen Google's IDE-interface. De IDE geeft je meerdere interactiemodi direct uit de doos.

Ten eerste is er de sidebar chat — een persistent gesprekspaneel dat open blijft terwijl je codeert. Ik gebruik dit voor snelle vragen, code-uitleg en kleine wijzigingen. Het verbruikt geen apart context window van je hoofdterminalsessie, wat belangrijk is voor de contextmanagementstrategie die ik eerder beschreef.

Ten tweede krijg je extensies die Claude-aangedreven features toevoegen aan specifieke bestandstypen en workflows. De extensies die ik het meest gebruik zijn de code review-extensie (markeert mogelijke problemen voordat ik commit) en de refactoring-extensie (suggereert verbeteringen voor geselecteerde codeblokken met toepassing in één klik).

Ten derde — en hier gebeurt het zware werk — heb je nog steeds de terminal direct ingebed in de IDE. Dit is je volledige Claude Code-ervaring, identiek aan wat je zou krijgen in een standalone terminal, maar nu omringd door de visuele context van je project's bestandsboom, open editors en taakpanelen.

Stap 3: Configureer global en local rules. Dit sluit direct aan op het BLAST-framework. Global rules gaan in je Claude Code configuratiemap en gelden voor elk project waaraan je werkt. De mijne bevatten algemene codeervoorkeuren: TypeScript strict mode, voorkeur voor functionele patronen, altijd foutafhandeling opnemen, zelfdocumenterende code schrijven. Local rules staan in een .claude/-map in je projectroot en bevatten projectspecifieke instructies: de tech stack, naamgevingsconventies, API-patronen en eventuele beperkingen die uniek zijn voor die codebase.

Anti-Gravity leest beide regelsets en past ze automatisch toe wanneer je met Claude interacteert via elke modus — sidebar, extensie of terminal. Je configureert rules eenmalig, en elke Claude-interactie respecteert ze. Nooit meer dezelfde "vergeet niet om TypeScript strict mode te gebruiken"-regel in elke prompt te plakken.

Stap 4: Modelselectie. Anti-Gravity ondersteunt meerdere modellen, waaronder Gemini 3.1 (Google's model) en Claude Opus. Ik heb beide uitgebreid getest voor codeertaken, en hier is mijn eerlijke oordeel: Gemini 3.1 is sterk voor code completion, inline suggesties en snelle bewerkingen. Claude Opus is sterker voor multi-file reasoning, architectuurbeslissingen en taken die begrip vereisen van de relaties tussen componenten. Mijn setup gebruikt Gemini voor de sidebar chat (snelle, lichtgewicht interacties) en Claude Opus voor terminalsessies (diep, complex werk). Je kunt dit configureren in Anti-Gravity's modelinstellingen — verschillende modellen voor verschillende interactiemodi.

Stap 5: Externe services verbinden. Hier wordt de setup echt spannend. Anti-Gravity ondersteunt connectors voor Gmail, Notion, Google Calendar en andere services. Ik heb mijn Notion-workspace verbonden zodat Claude direct mijn projectdocumentatie en taakborden kan raadplegen. Ik heb mijn agenda verbonden zodat ingeplande agents (hierover zo meer) conflicten kunnen controleren voordat ze focustijdblokken inplannen voor langlopende taken.

De connector-setup omvat OAuth-flows voor elke service — standaardzaken, niets exotisch. De beloning is dat Claude's context nu verder reikt dan je codebase, naar je bredere werkomgeving. Wanneer ik Claude vraag om "de huidige sprinttaken te bekijken en het hoogst geprioriteerde backend-ticket te kiezen," leest het rechtstreeks van mijn Notion-bord en genereert een plan op basis van de daadwerkelijke ticketbeschrijving. Geen ticketdetails meer kopiëren en plakken in prompts.

Stap 6: GitHub en Vercel integratie. Deze twee verdienen speciale vermelding omdat ze de lus sluiten van ontwikkeling tot deployment. De GitHub-integratie laat Claude branches aanmaken, wijzigingen committen en pull requests openen zonder de IDE te verlaten. De Vercel-integratie laat het deployments triggeren en preview-URL's controleren. Mijn typische flow nu: Claude bouwt een feature in een terminalsessie, maakt een PR via de GitHub-connector, Vercel deployt automatisch een preview, en ik review de live preview naast de code diff. Alles binnen Anti-Gravity. De deployment-feedbackloop die vroeger 15 minuten tab-wisselen kostte, duurt nu ongeveer 90 seconden.

Een valkuil bij de GitHub-integratie: zorg dat je Git-credentials geconfigureerd zijn via SSH keys of een credential helper voordat je verbinding maakt. De eerste keer dat ik het probeerde met HTTPS-credentials, faalde de auth-flow stilletjes en rapporteerde Claude alleen "unable to push" zonder bruikbare foutcontext. SSH keys losten het meteen op.

Multi-agent management: parallelle workflows draaien zonder gek te worden

Dit is de sectie waarvan ik wou dat die bestond toen ik begon met het opschalen van Claude Code-gebruik. Een enkele Claude-agent draaien is eenvoudig. Drie of vier tegelijkertijd draaien op verschillende taken binnen hetzelfde project is waar de workflows van de meeste mensen instorten.

Het kernprobleem is coördinatie. Agent A is de authenticatiemodule aan het refactoren terwijl Agent B een nieuw dashboardcomponent bouwt dat afhankelijk is van de API van de auth-module. Als ze allebei gedeelde bestanden wijzigen zonder bewustzijn van elkaar, krijg je in het beste geval merge conflicts en in het slechtste geval subtiele dataflow-bugs.

Anti-Gravity's taakmanager helpt hierbij door een register bij te houden van actieve agents en hun huidige scope. Je kunt zien aan welke bestanden elke agent werkt, welke bestanden "vergrendeld" zijn door actieve wijzigingen, en welke taken in de wachtrij staan versus in uitvoering zijn. Alleen al deze zichtbaarheid voorkomt de meeste coördinatiefouten — ik kan zien dat Agent A auth.ts aan het wijzigen is en de taak van Agent B vasthouden totdat die wijziging is afgerond.

De agent scheduling-functie gaat nog verder. Ik kan een reeks taken definiëren — "eerst auth refactoren, dan dashboard bouwen, dan integratietests schrijven" — en de scheduler voert ze in volgorde uit, waarbij relevante context tussen fasen wordt doorgegeven. Elke taak krijgt een vers context window (denk aan de 50%-degradatieregel), maar de scheduler draagt een samenvatting over van wat eerdere taken hebben bereikt en welke bestanden ze hebben gewijzigd.

Voor echt onafhankelijke taken — werk aan ongerelateerde features die geen bestanden of API's delen — draai ik agents parallel zonder scheduling. Anti-Gravity kan gelijktijdige sessies beheren in aparte terminalpanelen, elk met hun eigen context window en taakscope. De taakmanager toont me een geünificeerd overzicht van al het actieve werk, zodat ik voortgang kan monitoren zonder tussen terminals te wisselen.

Mijn typische dagpatroon: ik begin de ochtend met het in de wachtrij zetten van drie tot vier taken in de scheduler op basis van mijn sprintprioriteiten. De eerste een of twee zijn sequentieel (meestal afhankelijke features). De rest is parallel (onafhankelijke features of bugfixes). Ik review output naarmate elke taak wordt afgerond, keur goed of vraag revisies aan, en de scheduler gaat door naar het volgende item. Op een productieve dag genereert deze setup meer gereviewde, geteste, gecommitte code voor de lunch dan ik vroeger in een hele dag handmatig coderen produceerde.

Een eerlijk voorbehoud: de multi-agent aanpak vereist goede testdekking om integratieproblemen op te vangen. Ik draai de volledige testsuite nadat elke agent zijn taak heeft afgerond, en ik heb subtiele regressies ontdekt die er in isolatie prima uitzagen maar kapotgingen wanneer ze werden gecombineerd. Zonder tests zouden parallelle agents meer problemen creëren dan ze oplossen. Dit is geen kortere weg om engineeringdiscipline heen — het is een vermenigvuldiger erop.

Wat ik verkeerd deed en wat ik anders zou doen

Ik wil eerlijk zijn over de fouten die ik maakte tijdens het opbouwen van deze workflow, want de tutorials laten alles er soepel uitzien en de werkelijkheid heeft wrijving.

Fout één: te vroeg te veel automatiseren. Ik was enthousiast over Claude Skills en probeerde in de eerste week overal automations voor te maken. De meeste van die vroege skills waren te rigide — ze gingen uit van specifieke projectstructuren en braken wanneer ik ze gebruikte op andere codebases. De skills die ik dagelijks gebruik zijn degene die ik na een maand handmatige herhaling heb gebouwd, toen ik de workflow die ik automatiseerde diepgaand begreep. Bouw skills vanuit patronen die je handmatig hebt bewezen. Probeer geen workflows te automatiseren die je niet minstens tien keer met de hand hebt gedaan.

Fout twee: het context window negeren tot het te laat was. De eerste twee weken behandelde ik de 50%-contextregel als richtlijn in plaats van als harde grens. "Ik druk nog even door deze sessie, het is bijna klaar." De code die in die uitgerekte sessies werd gegenereerd kostte me meer debugtijd dan het starten van een verse sessie zou hebben gekost. Nu behandel ik het als een harde regel. Wanneer mijn context zwaar aanvoelt, sluit ik af en herstart. Elke keer.

Fout drie: het verkeerde model gebruiken voor de verkeerde taak. Ik gebruikte standaard Claude Opus voor alles, omdat het voelde alsof het "beste" model de beste resultaten zou geven. Het bleek dat Opus overkill is voor simpele bestandswijzigingen en eigenlijk langzamer dan Sonnet voor eenvoudige taken. De overhead van Opus' diepere redenering voegt latency toe zonder evenredige kwaliteitsverbetering wanneer de taak is "voeg een laadspinner toe aan deze knop." Stem modelcomplexiteit af op taakcomplexiteit. Gebruik Opus voor architectuur- en ontwerpbeslissingen. Gebruik Sonnet (of zelfs Gemini 3.1 voor inline completions) voor implementatietaken waarbij de richting al duidelijk is.

Fout vier: niet genoeg investeren in local rules. Mijn eerste projecten met deze setup hadden dunne local rules — misschien vijf of zes regels. De AI maakte constant aannames die niet overeenkwamen met mijn projectconventies, en ik besteedde tijd aan corrigeren. Nu zijn mijn local rules-bestanden 40-60 regels en bevatten ze specifieke voorbeelden van gewenste patronen naast de regels zelf. Claude een voorbeeld tonen van het foutafhandelingspatroon dat je wilt is tien keer effectiever dan het in abstracte termen beschrijven.

Wat ik anders zou doen als ik opnieuw zou beginnen: ik zou de hele eerste dag besteden aan het opzetten van rules en het testen ervan tegen voorbeeldprompts voordat ik echte code zou schrijven. De configuratietijd verdient zichzelf terug binnen de eerste week, maar ik was te ongeduldig om het vooraf te doen en betaalde de prijs in correctiecycli gedurende een maand.

De meetbare impact: voor en na deze setup

Ik wil specifieke cijfers delen, want vage claims over "productiviteitswinst" zijn nutteloos zonder context.

Ervoor (terminal-only Claude Code, geen framework):

• Gemiddelde tijd om een CRUD-feature met tests te bouwen: 3,5 uur
• Context-gerelateerde debugging per week: ongeveer 4 uur
• Mislukte deployments door integratieproblemen: 2-3 per week
• Skills/automations: nul, alles handmatig

Erna (Anti-Gravity + BLAST + Claude Skills, 6 weken later):

• Gemiddelde tijd om een CRUD-feature met tests te bouwen: 1,2 uur
• Context-gerelateerde debugging per week: minder dan 30 minuten
• Mislukte deployments door integratieproblemen: misschien 1 per maand
• Actieve skills in mijn bibliotheek: 14 (8 static, 6 dynamic)

De CRUD-feature metriek is de meest betrouwbare vergelijking omdat het de meest gestandaardiseerde taak is. Ander werk — complexe integraties, nieuwe features, architectuurontwerp — is moeilijker te benchmarken omdat geen twee taken identiek zijn. Maar subjectief voelt de verbetering consistent aan over alle taaktypen.

De context-gerelateerde debugging-metriek is de meest bevredigende verbetering. Vier uur per week aan "waarom genereert Claude rare code" verdween vrijwel volledig zodra ik de één-venster-per-taak discipline invoerde en contextgebruik begon te monitoren via Anti-Gravity's interface.

De deployment-metriek verbeterde deels vanwege betere codekwaliteit door verse context windows, en deels omdat de GitHub-naar-Vercel integratie problemen opvangt in preview deployments voordat ze productie bereiken. Beide factoren komen voort uit de Anti-Gravity setup.

Een metriek die ik niet kan kwantificeren maar sterk voel: cognitieve vermoeidheid. De oude workflow liet me mentaal uitgeput achter tegen 15:00. Het beheren van alles in mijn hoofd — welke agent deed wat, welke bestanden veranderden, waar ik was gebleven — verbruikte energie die naar daadwerkelijke engineeringbeslissingen had moeten gaan. Het uitbesteden van dat beheer aan de IDE maakte mentale bandbreedte vrij die ik het meest merk in de kwaliteit van mijn middagwerk.

Snelle winsten om te verwachten in de eerste week: de global en local rules alleen al zullen de outputkwaliteit van Claude merkbaar verbeteren. De sidebar chat vermindert je context-switching tussen browserdocumentatie en terminal. De zichtbaarheid van bestandswijzigingen vangt onbedoelde aanpassingen op die terminal-only workflows missen.

Langetermijnwinsten (week 3-6): je skill-bibliotheek begint zich op te stapelen. Multi-agent workflows worden praktisch. Het BLAST-framework wordt spiergeheugen in plaats van een bewust proces. Het volledige systeem — IDE, framework, skills, agents — begint als één geïntegreerde tool aan te voelen in plaats van een verzameling onderdelen.

Waar ik denk dat dit naartoe gaat

Zes maanden geleden schreef ik Claude Code prompts in een terminal en voelde me productief. Nu orkestreer ik meerdere AI-agents via een visuele interface met custom automations en geïntegreerde deployment pipelines. Het tempo van verandering in deze ruimte is oprecht desoriënterend, en ik denk dat we nog in de eerste hoofdstukken zitten.

De combinatie van Claude Code's redeneervermogen met Anti-Gravity's visuele beheerlaag wijst richting een toekomst waarin de IDE niet alleen een plek is om code te schrijven — het is een commandocentrum voor het aansturen van AI-agents die namens jou code schrijven. Je rol verschuift van implementatie naar specificatie, review en orkestratie.

Die verschuiving maakt sommige ontwikkelaars bang. Ik snap het. Maar vanuit mijn positie maakt het engineeringvaardigheden niet minder waardevol. Het maakt ze juist waardevoller. De ontwikkelaars die systeemontwerp begrijpen, die heldere specificaties kunnen schrijven, die weten hoe ze een project moeten structureren voor onderhoudbaarheid — zij zijn degenen die het meeste uit deze tools halen. De AI doet het typewerk. Jij doet het denkwerk.

Als je één ding meeneemt uit dit artikel, laat het dan de context window-discipline zijn. Eén venster per taak. Verse context voor vers werk. Alles wat ik verder heb beschreven bouwt voort op dat fundament, en het kost niets om het nu meteen te implementeren in welke setup je ook al gebruikt.

De tools zullen blijven evolueren. Google zal updates uitbrengen voor Anti-Gravity. Anthropic zal Claude's codeervaardigheden verbeteren. Nieuwe frameworks en technieken zullen opkomen. Maar het principe van het beheren van de context van je AI als een schaarse bron — dat is een blijvend inzicht. En het is degene die het grootste verschil maakte in mijn werk.

Hoe ziet jouw Claude Code workflow er op dit moment uit? Ik ben oprecht benieuwd of anderen andere oplossingen hebben gevonden voor het contextmanagementprobleem, of dat de één-venster-per-taak aanpak net zo universeel is als in mijn ervaring.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io