Wat doet DeerFlow precies?

DeerFlow staat voor Deep Exploration and Efficient Research Flow. Dat klinkt ingewikkelder dan het is. In de kern is het een orkestratielaag: één hoofdagent die meerdere sub-agents aanstuurt, elk met een eigen taak. Eén zoekt informatie op, een tweede vat samen, een derde schrijft code op basis van die samenvatting. Allemaal gecoördineerd door DeerFlow, zonder dat jij dat handmatig hoeft te regelen.

Normaal betekent multi-agent (meerdere AI-agents die samenwerken) een berg custom code om context door te sturen, fouten op te vangen en de volgorde te bewaken. DeerFlow neemt dat van je over.

Het framework biedt drie dingen die ik direct interessant vind:

• Sub-agent orkestratie: je definieert wie wat doet, DeerFlow regelt de handoff.
• Geheugenbeheer: zowel kortetermijncontext (lopend gesprek) als langetermijngeheugen, zodat agents kunnen leren van eerdere runs.
• Sandboxing: agent-gegenereerde code voer je niet zomaar uit op je server. DeerFlow isoleert die uitvoering in een lokale omgeving, Docker-container of Kubernetes-pod.

Dat laatste is voor mij het meest waardevol. Als een agent code produceert die je niet 100% vertrouwt, wil je niet dat die zomaar op je productieserver draait. Met de instelling auto_approve_permissions: false in je config gaat er niets door zonder jouw goedkeuring. Eén regel, grote impact.

DeerFlow is ontwikkeld door ByteDance en bereikte in februari 2026 de eerste plek op GitHub Trending na de lancering van versie 2. Of dat betekent dat het de standaard wordt? Dat weet ik nog niet. Maar de technische basis is serieus genoeg om te testen.

Opzetten in minder dan 10 minuten: hoe werkt dat?

Je kloont de repo, typt drie regels en een wizard regelt de rest. Dat is het. DeerFlow vraagt je welke LLM je wilt gebruiken, of je web search wilt, en welke sandbox-modus je kiest. Daarna schrijft het zelf een config.yaml en slaat API-keys op in een .env bestand. Voor developers die graag zelf alles instellen: er is ook een uitgebreid template beschikbaar.

De setup ziet er zo uit:

git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
make setup

De make setup wizard doorloopt de belangrijkste keuzes: LLM-provider, web search, sandbox-modus en schrijftoegang tot bestanden. Binnen een paar minuten heb je een werkende basisinstallatie.

Wil je meer controle? Dan gebruik je make config, dat kopieert het volledige configuratietemplate zodat je alles handmatig kunt aanpassen: subagent runtime-limieten, modelconfiguraties per agent, sandbox-instellingen.

Er is ook een ingebouwde health check:

make doctor

Dat commando controleert of alles klopt en geeft concrete suggesties als er iets mist. Klinkt als een detail, maar als je met Docker-containers en API-keys werkt, is een geautomatiseerde check een stuk betrouwbaarder dan zelf uitzoeken wat er misgaat.

Voor Docker-ontwikkeling:

make docker-init
make docker-start

Dit start je services met hot-reloading, zodat je config-wijzigingen direct worden opgepikt zonder handmatige herstart. Prettig als je iteratief werkt.

Welke AI-modellen werken met DeerFlow?

Vrijwel alles. GPT-4o, Gemini 2.5 Flash via OpenRouter, lokale modellen via vLLM, en zelfs CLI-gebaseerde tools zoals Claude Code. Je koppelt elk model aan een specifieke sub-agent, zodat je de goedkopere of snellere optie kunt inzetten voor eenvoudige taken en het zwaardere model reserveert voor de moeilijke stappen.

DeerFlow gebruikt langchain_openai:ChatOpenAI als basis voor OpenAI-compatibele providers. Dat betekent dat alles met een OpenAI-compatibele API direct werkt, inclusief OpenRouter (die toegang geeft tot honderden modellen) en lokale vLLM-deployments.

Een voorbeeld uit de config.yaml:

models:
  - name: gpt-4o
    use: langchain_openai:ChatOpenAI
    model: gpt-4o
    api_key: $OPENAI_API_KEY

  - name: openrouter-gemini
    use: langchain_openai:ChatOpenAI
    model: google/gemini-2.5-flash-preview
    api_key: $OPENROUTER_API_KEY
    base_url: https://openrouter.ai/api/v1

  - name: lokaal-qwen
    use: deerflow.models.vllm_provider:VllmChatModel
    model: Qwen/Qwen3-32B
    api_key: $VLLM_API_KEY
    base_url: http://localhost:8000/v1

Elk model wijs je toe aan een specifieke sub-agent. Dat is slim: je kunt de goedkopere Gemini Flash inzetten voor het samenvatten van bronnen, en GPT-4o alleen gebruiken voor de stap die echt redenering vereist. Zo houd je de kosten in de hand.

Mijn voorkeur zou zijn om te beginnen met één model, de workflow stabiel te krijgen, en dan pas te differentiëren per agent. Direct met vijf verschillende modellen starten maakt debuggen lastig. Kies voor de eerste tests een model dat je al kent.

Als je meer wilt weten over het switchen tussen AI-modellen in een bestaande setup, is het artikel over LLM model migratie zonder gedoe een goede aanvulling.

Hoeveel server heb je nodig voor een stabiele DeerFlow-omgeving?

Voor productie raadt ByteDance 8 vCPU en 16 GB RAM aan als startpunt. Bij zware workflows, zoals meerdere agents tegelijk met actieve sandbox, heb je al snel 16 vCPU en 32 GB RAM nodig. Op minder dan 8 vCPU krijg je bottlenecks zodra de sandbox actief is. Linux met Docker is de meest stabiele deploymentkeuze.

Dit is het onderdeel dat veel tutorials overslaan, maar dat je later duur kan komen te staan. DeerFlow is geen lichtgewicht tool. De sandbox-modus voert code uit in geïsoleerde containers, en dat kost resources.

Richtlijnen voor productie:

• Minimaal: 8 vCPU, 16 GB RAM, 40 GB vrije SSD
• Intensief gebruik: 16 vCPU, 32 GB RAM (voor multi-agent runs of rapportgeneratie)
• OS: Linux met Docker is de aanbevolen combinatie

Voor development werkt Docker uitstekend en geeft het je isolatie zodat je lokale machine niet vervuild raakt met dependencies.

Naar mijn idee is dit ook het punt waar DeerFlow verschilt van simpelere AI-tools: het is infrastructuur, geen plugin. Je zet het op zoals je een backend-service opzet, niet zoals je een Chrome-extensie installeert. Dat vraagt een andere manier van denken.

Als je nu al nadenkt over de bredere verschuiving in hoe developers met AI werken, is het artikel over de developer rol in het AI-tijdperk een eerlijke blik op wat er verandert.

Is DeerFlow iets voor jou als developer?

DeerFlow is interessant als je complexe, meertraps AI-workflows wilt bouwen waarbij meerdere agents samenwerken. Het is niet geschikt als je simpelweg een chatbot wilt of een API wilt aanroepen. De leercurve is reëel, de infrastructuurvereisten zijn serieus, maar de controle die je terugkrijgt over hoe agents samenwerken is het waard als dat je use case is.

Eerlijk oordeel: DeerFlow is geen beginnersspeeltje. De setup is redelijk toegankelijk dankzij de wizard, maar zodra je meerdere agents met verschillende modellen gaat configureren en de sandbox serieus gaat inzetten, ben je bezig met infrastructuur.

Voor wie het wél interessant is:

• Developers die AI-workflows bouwen waarbij stappen van elkaar afhankelijk zijn
• Teams die agent-gegenereerde code veilig willen uitvoeren zonder hun productieserver te riskeren
• Projecten waarbij je wilt schakelen tussen LLM-providers per taak, voor kosten- of kwaliteitsoptimalisatie

Voor wie het minder geschikt is:

• Je wilt snel een chatbot of eenvoudige AI-assistent bouwen
• Je hebt geen server met minimaal 8 vCPU beschikbaar
• Je bent niet bekend met Docker en wil dat ook niet worden

Wat ik zelf zou doen: het lokaal opzetten met make setup, één eenvoudige workflow testen met twee agents en één model, en dan evalueren of de complexiteit gerechtvaardigd is voor het project. Niet direct in productie gooien.

Ben je ook bezig met het bouwen van AI-agents voor specifieke taken? Het artikel over AI-agents als ontwikkelteam laat zien hoe zo’n opzet er in de praktijk uitziet.

Wat ik in mijn eigen werk zie veranderen

Ik ben zelf developer en ik werk dagelijks met AI-tools voor klantprojecten. Het verschil met twee jaar geleden: ik typ minder code, ik review meer. Ik schrijf minder algoritmes, ik schrijf meer specificaties. De rol is niet kleiner geworden, hij is verschoven. Wie nog elke regel zelf wil typen omdat dat "echt programmeren" is, loopt achter.

Twee jaar geleden begon ik een feature met een lege editor en een idee. Nu begin ik met een prompt: hier is de huidige code, hier is wat ik wil, schrijf de eerste versie. De AI tikt het in 30 seconden uit. Daarna komt mijn werk: kloppen de assumpties, zit er geen verzonnen library in, hoe gaat dit zich gedragen onder load.

Niet elke developer ervaart dit zo. Sommige collega’s negeren AI bewust. Anderen accepteren elke gegenereerde regel klakkeloos. Beiden lopen risico. De eerste groep raakt achter omdat AI-tools zo sterk worden dat handmatig coderen straks duurder is. De tweede groep stopt productie-bugs in hun software omdat ze de output niet snappen.

Wat blijft, en zelfs belangrijker is geworden: weten waarom code werkt. Niet alleen of het werkt. Bij mijn klanten zie ik dat de developers die het beste presteren, de developers zijn die kritisch lezen en doorvragen op de output. Niet de developers die het hardst typen.

Welke skills écht waarde toevoegen in 2026

Architectuur, systeemontwerp, security en het schrijven van heldere specificaties. Dat is waar de waarde nu zit. AI bouwt componenten, jij ontwerpt het systeem. AI schrijft de query, jij beoordeelt of de query veilig is. Skills die niet goed door AI worden ingevuld zijn de skills die je doelgericht moet bijspijkeren.

De skills die in mijn ervaring nu het zwaarst wegen, in volgorde:

Systeemontwerp. Een AI kan een loginscherm bouwen, maar niet bedenken hoe authenticatie samenhangt met sessions, met de cache-laag, met de e-mailprovider, met je hosting. Dat overzicht moet uit een mensenhoofd komen.

Code reviewen met aandacht voor wat er níét staat. AI vergeet edge cases. AI verzint soms dependencies die niet bestaan. AI gebruikt soms verouderde APIs. Een goede review controleert wat ontbreekt, niet alleen wat er staat.

Security en privacy. AI-tools genereren regelmatig code met onveilige defaults: hardcoded secrets, ontbrekende input-sanitisatie, te brede CORS-headers. Wie dat herkent, voorkomt incidenten. De Autoriteit Persoonsgegevens publiceerde richtlijnen voor AI-gebruik waar elke developer met klantdata mee bekend hoort te zijn.

Specificaties schrijven. Een AI doet alleen wat je vraagt, en een vage vraag levert vage code op. Helder kunnen formuleren wat je wilt is geen managers-skill meer maar core developer-werk.

Wat dit betekent als jij een developer of freelancer inhuurt

Ondernemers die freelance-developers of een dev-team inhuren, kijken nu naar andere signalen dan vijf jaar geleden. Niet meer "kan deze persoon snel typen", maar "begrijpt deze persoon mijn business en kan hij de AI-output beoordelen". Een developer die alle code uit ChatGPT haalt zonder review levert je een tijdbom. Een developer die AI bewust inzet en de output kritisch leest, levert je in dezelfde tijd meer waarde op.

Drie concrete dingen die je nu anders moet doen bij het inhuren of werken met developers:

Vraag naar AI-werkwijze, niet naar AI-vermijding. Iemand die zegt "ik gebruik geen AI" is in 2026 vaak duurder dan iemand die het slim inzet. Niet omdat AI gratis is, maar omdat de eerste groep langer doet over hetzelfde werk. Vraag liever: hoe gebruik je AI in je workflow, en wat doe je om niet in valkuilen te trappen.

Reken op review-tijd, niet alleen bouwtijd. Vroeger schatten developers bouwtijd. Nu is bouwtijd korter en review-tijd langer. Een feature van twee weken oude stijl is misschien drie dagen bouwen plus drie dagen review. Plan beide in.

Eis documentatie van AI-keuzes. Welke libraries gebruikt de developer, welke daarvan zijn AI-suggesties, en welke tests zitten erop. Dit is je verzekering voor als de developer wegloopt en jij straks zelf de code moet onderhouden of overdragen.

Wat ik adviseer aan junior developers en ondernemers met een dev-team

Junior developers: leer de fundamenten zoals datastructuren, algoritmen en systeemontwerp. Daar bouw je je AI-werk bovenop. Ondernemers met een dev-team: investeer in pair-programming en code-review-cultuur, niet in meer AI-licenties. Tools maken het werk niet beter, kritisch denken doet dat.

Voor junior developers die net beginnen: laat AI niet je leerproces overnemen. Genereer code, ontleed hem, schrijf hem opnieuw vanaf scratch zonder AI, vergelijk. Dat is hoe je AI gebruikt om sneller te leren in plaats van langzamer.

Voor ondernemers met een eigen dev-team of freelance-developers: de grootste winst zit niet in betere tools maar in betere werkprocessen. Een uur per week pair-programmen levert meer op dan een nieuwe AI-licentie. Een verplichte code-review op AI-gegenereerde features voorkomt incidenten die je later weken kosten.

Voor ZZP’ers die zelf bouwen: het is geen schande om de AI te gebruiken voor je klantenwebsite. Het is wel een probleem om de output blind te plaatsen. Schrijf een korte review-checklist en ren die door op alles wat AI voor je maakt: input-validatie, foutmeldingen, edge cases, security-headers. Vijf minuten controle voorkomt een uur incident-respons.

Wat "zelfverbetering" in AI nu echt is

Het mooie verhaal: AI traint AI, dus elke generatie wordt exponentieel beter. De realiteit: AI-modellen helpen met het genereren van trainingsdata en het destilleren van kleinere modellen. Echte recursive zelfverbetering bestaat niet, daar staat de vakwereld nog ver vanaf.

De marketing-versie van dit verhaal klinkt als sciencefiction: AI bouwt AI, en straks zijn we niet meer nodig. De technische realiteit is veel saaier. AI-modellen worden gebruikt om trainingsdata te labellen, om edge cases te genereren en om kleinere modellen te trainen op de output van grotere. Dat heet distillatie en het is geen magie.

Wat ik er bij klanten van merk: de tools die ik vorig jaar adviseerde zijn nu verouderd. Niet omdat AI zichzelf overtroffen heeft, maar omdat er gewoon snel nieuwe modellen worden uitgebracht en de prijzen schuiven. Dat is geen exponentiële zelfverbetering. Dat is een markt in beweging.

Het effect dat je écht merkt: tooling-instabiliteit

Wat ondernemers in 2026 voelen is geen exponentiële sprong, maar instabiele tooling. Een tool die zes maanden geleden goed werkte heeft nu een ander prijsmodel, andere features of is opgekocht door een groter bedrijf.

Concreet bij mij: ik adviseerde vorig jaar een klant om een specifieke AI-schrijftool te gebruiken voor zijn klantenservice-mails. Drie maanden later kocht een groter platform de tool, twee maanden later werd de prijs verdubbeld en verdween een feature die hij dagelijks gebruikte.

Dat is wat "exponentiële versnelling" in de praktijk betekent: niet dat alles beter wordt, maar dat alles sneller verandert. Voor een ondernemer is dat een planning-probleem, niet een opportunity-probleem.

Wat dit betekent voor je AI-strategie

Drie principes die ik bij elke klant inbouw: geen langlopende contracten op AI-tools, modulaire setups die makkelijk wisselbaar zijn, en niet je hele bedrijf bouwen op één leverancier. Dat klinkt voor de hand liggend, maar ik zie regelmatig anders.

Wat ik concreet doe: voor elke klant die AI integreert kies ik tools met een API die op meerdere providers werkt. OpenAI-compatible APIs van Anthropic, Google en open-source-modellen. Dat scheelt straks veel pijn als één leverancier zijn prijzen verdubbelt.

Voor klanten zonder eigen IT-team: kies maand-tot-maand abonnementen, niet jaarcontracten. De besparing van een jaarcontract is meestal 10 tot 20 procent. Het risico op vastzitten aan een tool die over zes maanden niet meer past, is veel groter dan die besparing.

Hoe je rustig blijft tussen alle hype

Ik heb een filter ontwikkeld voor AI-nieuws: lees pas de hands-on reviews na drie maanden, niet de launch-aankondigingen. Dat scheelt een hoop adrenaline en je mist niets dat er echt toe doet.

Wat ik bij mezelf merk: in het begin volgde ik elke launch live. Ik wilde direct testen, direct adviseren. Inmiddels wacht ik standaard drie maanden voordat ik een nieuwe tool serieus oppak. Driekwart van de hyped tools is dan al weer vergeten of merkbaar tegengevallen.

Mijn praktische tip aan klanten: abonneer je niet op AI-nieuws. Kies twee mensen die jij vertrouwt op het vak (geen AI-influencers, maar echte gebruikers) en lees alleen wat zij delen. Dat geeft je tijd terug en het signaal-naar-ruis-verhouding is veel beter.

Het patroon dat ik altijd gebruik bij animaties

Beschrijf wat de gebruiker zou moeten zien (niet de techniek), geef context over de stack en kies een animatie-bibliotheek. Drie zinnen prompt, een halve pagina werkende code terug.

Concreet bij een klant: hij wilde dat zijn productkaarten “subtiel oprijzen” als de gebruiker er overheen beweegt. Mijn prompt aan Claude: Ik werk in React 18 met Tailwind CSS en framer-motion. Maak een ProductCard component die een subtiele lift-animatie heeft op hover: 4px omhoog, lichte schaduw, 200ms duur, ease-out timing.

Resultaat: een werkend component dat ik direct kon gebruiken. Twee minuten finetune nodig om de schaduwsterkte iets minder zwaar te maken. Werk dat me vroeger een halve middag kostte aan tutorials kijken en code aanpassen, nu een kwartier.

Welke bibliotheken werken het beste

Voor React: framer-motion, sterk en goed gedocumenteerd. Voor vanilla JS: GSAP voor complexere flows, of pure CSS-keyframes voor eenvoud. Vermijd jQuery-animaties, dat is achterhaald en Claude voelt dat ook aan in zijn voorstellen.

Mijn ervaring per stack: framer-motion is voor React-werk een veilige eerste keuze omdat Claude er heel veel voorbeelden van kent en dus zelden onzin produceert. GSAP is breder en krachtiger maar vraagt meer instelwerk. Pure CSS-animaties zijn voor simpele effecten ideaal en kosten geen extra bibliotheek.

Bij klanten kies ik per project. Een marketing-landingspagina: pure CSS plus eventueel framer-motion voor één of twee key-momenten. Een interactieve webapp: framer-motion of GSAP afhankelijk van de complexiteit. Niet alles op één bibliotheek bouwen, niet alles los oplossen.

De finetune-fase die niemand overslaat

Animaties die op de eerste try goed voelen zijn zeldzaam. Timing, easing en delay zijn drie kleine knoppen waarmee je een animatie van "OK" naar "echt goed" brengt. Plan tijd in voor deze finetune, anders levert je werk halve kwaliteit op.

Wat ik bij elke animatie doe: nadat Claude code heeft opgeleverd, draai ik hem in de browser en kijk drie keer. Eerste keer voor de timing (te snel of te traag?), tweede keer voor de easing (voelt het natuurlijk of mechanisch?), derde keer voor de afstemming met andere elementen op de pagina. Per check minimaal één micro-aanpassing.

Tip uit eigen ervaring: animaties die op een snel scherm goed voelen, voelen op een traag scherm vaak haperig. Ik test bij klanten altijd op minimaal twee apparaten voordat ik iets als af bestempel.

Toegankelijkheid: het stuk dat AI vergeet

Claude denkt niet automatisch aan gebruikers die animaties willen uitschakelen. De CSS-mediaquery <code>prefers-reduced-motion</code> moet je zelf vragen. Bij elke animatie doe ik dat als laatste stap.

Wat ik standaard doe bij elke animatie: na de eerste werkende versie voeg ik handmatig de respect voor prefers-reduced-motion toe. Een gebruiker die deze instelling heeft staat (vaak vanwege vestibulaire klachten) krijgt dan geen of veel kortere animaties.

Een typische CSS-versie ziet er zo uit:

.product-card {
  transition: transform 200ms ease-out;
}

@media (prefers-reduced-motion: reduce) {
  .product-card {
    transition: none;
  }
}

Bij framer-motion is er een ingebouwde useReducedMotion-hook die hetzelfde doet. Vraag Claude er expliciet om, anders vergeet hij het. Toegankelijkheid en animaties zijn een paar dat je actief moet bewaken.

Mijn meest voorkomende use-case: overgenomen WordPress-sites

Een klant stapt over van een vorige developer naar mij. Hij heeft een WordPress-site met aanpassingen die niemand meer kan uitleggen. Mijn eerste week is dan: AI gebruiken om de code te lezen en de waarheid van de fictie te scheiden.

Concreet vorige maand: een klant met een functions.php van 600 regels van een developer die er drie jaar geleden mee gestopt is. De klant kon niet uitleggen wat de helft deed, en sommige regels deden duidelijk niets. Voor de overdracht moest ik weten welke regels essentieel zijn en welke gewoon dood gewicht.

Mijn aanpak: in 30 minuten plakte ik blokken van 50 regels in Claude en vroeg hem per blok om uitleg, plus een advies over of het in 2026 nog werkt zoals het is geschreven. Wat normaal twee dagen leeswerk was, was een ochtend werk plus een middag verifiëren in de browser.

Wat AI bij WordPress-code wel en niet goed doet

Wel: bekende patronen herkennen, deprecated functies signaleren, security-zorgen aanwijzen. Niet: bugs vinden die afhankelijk zijn van runtime-staat, wat alleen optreedt bij specifieke gebruikersinput, of plugin-conflicten in een volle stack.

Bij mij in de praktijk: een AI vindt zonder problemen een gebroken nonce, een ontbrekende sanitize-call of een functie die in WordPress 6.4 is verwijderd. Dat soort lookup-werk is precies waar AI sterk in is: pattern-matching tegen een bekende kennisbank.

Wat AI minder goed doet: ingewikkelde plugin-conflicten waar twee plugins dezelfde hook overschrijven, of bugs die alleen optreden bij een specifieke combinatie van gebruikersinstellingen. Daar moet je nog steeds zelf debuggen, eventueel met een AI als sparringpartner.

Hoe ik AI integreer in mijn dagelijkse WordPress-werk

Twee tools, twee rollen. Claude voor codeanalyse en refactor-voorstellen, ChatGPT voor snelle "hoe doe je dit ook alweer in WP"-vragen. Beide actief tijdens het werken in mijn editor, niet alleen achteraf.

Ik gebruik dit dagelijks in een paar concrete patronen. Bij het beoordelen van een nieuwe plugin van een klant: één Claude-sessie open met de hele plugin-code geladen, dan vraag ik per functie om uitleg en risicoanalyse. Bij het schrijven van een custom blok: ChatGPT staat open in een tab voor snelle syntax-vragen die ik niet meer in mijn hoofd heb.

Wat ik bij klanten merk: een AI als sparringpartner versnelt het werk veel meer dan een AI als productiemiddel. Het idee dat AI volledig zelf code schrijft past niet bij hoe WordPress-werk in elkaar zit, omdat WP zoveel context-specifieke conventies heeft. Maar als sparringpartner is hij goud waard.

De grens: wat ik nooit aan AI overlaat in WordPress

Database-migraties, security-kritieke functies (login, betaalflows, gebruikersdata) en alles wat met klantgegevens te maken heeft. Daar kijk ik altijd zelf, eventueel met AI als tweede paar ogen.

Mijn vuistregel: hoe directer iets impact heeft op data of veiligheid, hoe minder ik AI alleen laat. Een nieuwe display-functie voor een productlijst? Prima, AI mag voorstellen doen die ik scan. Een aanpassing in hoe gebruikers worden geauthenticeerd? Daar zit ik bovenop, AI mag commentaar geven maar niet leiden.

Concreet bij een klant met WooCommerce: ik laat AI kijken naar de presentatie van producten, niet naar hoe betalingen worden afgehandeld. Het verschil tussen een lelijke productpagina en een gehackte webshop is groot. Voor het eerste accepteer ik snelheid, voor het tweede niet.

Je hebt Claude Code geïnstalleerd in één commando

Open je terminal en draai `npm install -g @anthropic-ai/claude-code`. Klaar. De installatie duurt minder dan een minuut. Wat je nodig hebt: Node.js 18 of nieuwer, een werkende npm en een Anthropic-account.

Voor wie nog geen Node.js heeft draaien: installeer eerst nvm (Node Version Manager) op macOS of Linux, of download de Node-installer voor Windows. Met nvm kun je later makkelijk wisselen tussen Node-versies, wat handig is als je meerdere projecten hebt.

Bij mij staat Claude Code op alle drie mijn werkmachines (laptop, desktop, server) en de installatie gaat overal precies hetzelfde. Geen platform-specifieke trucs.

Je bent ingelogd en hebt het juiste model gekozen

Eerste keer Claude Code starten doet hij een login-flow via je browser. Je kiest welk model standaard wordt: Sonnet voor algemeen werk, Opus voor zware taken, Haiku voor snelle hulp. Voor de meeste werkdagen werk ik op Sonnet.

Het login-proces opent een browser-tab waar je je Anthropic-account koppelt. Voor Pro- en Max-abonnees werkt dit direct, geen API-key gedoe. Voor enterprise-gebruikers met een eigen API-key voer je die in via een omgevingsvariabele: export ANTHROPIC_API_KEY=jouwkey.

Modelkeuze in het kort: Sonnet 4.5 of 4.6 is mijn dagelijkse paard, voldoende voor 90 procent van het werk. Opus zet ik aan voor complexere refactor-taken of architectuur-vragen, hij denkt langer en grondiger maar is duurder en trager. Haiku gebruik ik voor snelle eenmalige vragen waar volledigheid niet zo belangrijk is.

Je draait `claude` in je projectmap en hij begrijpt je code

Open je terminal in de map van je project en typ `claude`. Hij start een interactieve sessie waar je vragen kunt stellen over de code, wijzigingen kunt voorstellen of nieuwe features laten bouwen. Hij leest standaard de bestanden in de huidige directory.

Voor de allereerste sessie raad ik aan om iets kleins te doen: vraag Claude om een functie te leggen die hij vindt, of om een README te schrijven voor je project. Dan zie je hoe hij praat en hoe diep hij in je code duikt zonder dat je risico loopt op kapotte code.

Een paar handige toetsen tijdens een sessie: /clear begint opnieuw zonder context, /model wisselt van model, /permissions stelt in welke acties hij wel of niet zelfstandig mag uitvoeren. Bij klantprojecten zet ik permissions altijd op handmatig voor file-edits.

Je hebt een CLAUDE.md aangemaakt met je projectcontext

Een CLAUDE.md is een tekstbestand in de root van je project dat Claude bij elke sessie automatisch leest. Erin zet je je tech-stack, codeer-conventies, wat hij wel en niet mag doen, en eventuele klant-specifieke regels. Vergelijkbaar met DESIGN.md voor designtools.

Mijn standaard CLAUDE.md voor een Laravel-project ziet er ongeveer zo uit:

# CLAUDE.md

## Stack
- PHP 8.3, Laravel 11, MySQL 8
- Frontend: React 18, TypeScript, Tailwind, Vite

## Conventies
- PSR-12 voor PHP
- Eslint + Prettier voor TS
- Componentnamen in PascalCase
- Database-migraties altijd reversible

## Wat NIET
- Geen raw SQL, gebruik Eloquent
- Geen any-types in TypeScript
- Geen wijzigingen in /vendor of /node_modules

Per project pas ik dit aan naar de specifieke setup. Voor wie hier verder over wil lezen: de aanpak lijkt op die van DESIGN.md voor AI-designtools, maar dan voor code in plaats van visuele stijl.

Je hebt een werkroutine die past bij jouw projecten

Hoe ik Claude Code dagelijks gebruik: ochtends voor pull-request reviews en testen, middags voor het schrijven van nieuwe code in samenwerking, einde dag voor documentatie en cleanup. Niet alles tegelijk, niet bij elke regel code.

Concreet mijn werkdag bij een klantproject: ik begin met een prompt zoals “lees alle bestanden in /src en geef een overzicht van wat we nog moeten doen volgens de issues in /docs/todos.md”. Daar krijg ik een lijst en een aanpak. Daarna pak ik de eerste taak en bouw die samen met Claude.

Bij mij is het ritme: drie tot vier productieve coding-sessies van een uur per dag, met pauzes ertussen waarin ik Claude even uitzet en zelf nadenk. Volledig leunen op AI maakt me lui en haalt de scherpte uit mijn code-reviews. Pauzes nemen blijft belangrijk.

Hoe een AI-agent-team er bij mij uitziet

Stel: een klant wil een nieuwe webshop in Laravel met React-frontend. In plaats van één Claude-sessie waarin ik alles vraag, run ik vier sessies parallel: één voor de Laravel-backend, één voor de React-componenten, één voor de tests, één voor de security-review. Elk met eigen instructies en eigen context.

Concreet zien mijn instructies er zo uit. De backend-agent krijgt: “Je werkt in Laravel 11, gebruik Eloquent, hou je aan PSR-12, gebruik RESTful conventies, schrijf nooit raw SQL.” De frontend-agent krijgt: “Je werkt in React 18 met TypeScript en Tailwind, gebruik functionele componenten, geen class components, gebruik Tanstack Query voor server state.”

Door deze focus weet elke agent wat hij wel en niet moet doen. Je krijgt geen rare hybride code waar Laravel-Eloquent-syntax door je React-componenten heen rolt. Het lijkt klein, maar het scheelt veel correctiewerk achteraf.

Wat het concreet oplevert versus één Claude-sessie

Bij mijn laatste klantproject (een MKB-platform met dashboard en API) scheelde de agent-team setup me ongeveer twee dagen werk over een drieweekse sprint. Voornamelijk doordat de agents minder vaak verkeerde patronen suggereerden en doordat ik parallel kon werken in plaats van seriëel.

De winst zit in twee dingen. Eén: minder context-verwarring. Een agent die alleen frontend ziet, suggereert geen backend-oplossingen voor frontend-problemen. Twee: parallel werk. Terwijl de backend-agent een API-endpoint bouwt, kan de frontend-agent alvast de TypeScript-types ervoor opzetten. Dat soort gelijktijdig werk is met één sessie lastig te coördineren.

Het kost wel meer aan abonnementen. Vier parallelle Claude-sessies betekent vier keer Pro of een Max-abonnement. Voor een drieweeks project van een paar duizend euro is dat te overzien, voor een wekelijks klusje niet.

Wanneer ik dit niet inzet

Voor projecten van minder dan een week, voor simpele websites zonder backend, en voor klanten die nog twijfelen over hun eigen requirements. De setup-tijd om elke agent zijn rol uit te leggen is een dagdeel. Bij kleine projecten haal je dat niet terug.

Concreet: een landingspagina met formulier doe ik in één Claude-sessie, klaar binnen een ochtend. Een dashboard met user-management, betalingen, e-mailflows en notificaties? Daar pak ik het agent-team. De drempel ligt bij mij rond een week aan ontwikkelwerk.

Plus: ik gebruik dit nooit met klanten die hun specs nog aan het uitvogelen zijn. Vier agents tegelijk in beweging zetten op iets dat morgen toch weer verandert is verspilling. Eerst klant pinned, dan team uitrollen.

Praktische tips als je dit zelf wilt proberen

Begin klein: twee agents (frontend + backend) op een nieuw greenfield project. Schrijf voor elke agent een korte rol-omschrijving die je standaard plakt. Gebruik git-branches per agent zodat je hun werk apart kunt mergen. Houd één agent eindverantwoordelijk voor de architectuurkeuzes.

Mijn vier-stappen aanpak voor wie dit voor het eerst probeert: één: schrijf voor elke agent een DESIGN.md-achtige instructie met de tech-stack, codeer-conventies en wat hij wel/niet moet doen. Twee: open per agent een eigen Claude Code-sessie of een aparte chat. Drie: laat de architect-agent eerst een algemene aanpak voorstellen, dan pas de uitvoerende agents aan het werk. Vier: review het werk van elke agent door een andere agent.

Die vierde stap is goud waard. Als je security-agent de code van je backend-agent doorleest, vangt hij dingen die in één sessie verloren gaan. Het kost 20 procent extra tijd, je voorkomt de 80 procent issues die je anders pas in productie tegenkomt.

Wat Auto Mode precies doet

Standaard vraagt Claude Code per voorgestelde wijziging om jouw goedkeuring voor hij hem doorvoert. Met Auto Mode aan slaat hij die stap over en past hij wijzigingen direct toe. Je houdt wel het laatste woord via git, maar je leest mee in plaats van vooraf goedkeurt.

Het verschil in een typische sessie: zonder Auto Mode komt Claude met een voorstel, jij leest, jij keurt goed of corrigeert, hij past aan. Met Auto Mode aan: jij geeft een opdracht, Claude bouwt en past direct aan, jij kijkt achteraf wat hij precies heeft gedaan.

Het spaart tijd op repetitieve taken (rename een variabele door 30 bestanden, voeg een veld toe aan alle modellen, herformatteer een hele directory). Het kost tijd op alles waar één verkeerde aanname in een bestand later in 20 andere bestanden door-cascadeert.

Wanneer ik Auto Mode wel gebruik

Voor weekendprojecten, prototypes en wegwerp-experimenten. Alles waar de hele codebase verloren mag gaan zonder dat het iets kost. In zulke setups is snelheid waardevoller dan controle.

Concreet bij mij: ik heb een test-repository waar ik nieuwe AI-frameworks en libraries uitprobeer. Daar staat Auto Mode permanent aan. Wanneer Claude iets misgokt en breekt, gooi ik de map gewoon weg en begin opnieuw. Geen klantgegevens, geen productiedata, niks om te verliezen.

Ook handig: bij codegestuurde refactor-taken in nieuwe greenfield-projecten waar nog geen tests draaien. Daar wint snelheid het van de afwezige veiligheidsnetten.

Wanneer ik Auto Mode altijd uitzet

Voor klantcode, productie-applicaties en alles met test-suites die ik niet wil omver gooien. De extra paar seconden per voorstel zijn een goedkope verzekering tegen het soort fouten dat een uur extra debuggen kost.

Drie concrete situaties waar ik Auto Mode altijd uitlaat: bij elk klantproject (waar mijn naam aan een release hangt), bij elke wijziging in een database-migratie (waar één foute kolom je productiedata kan verliezen), en bij security-gerelateerde code (waar één gemiste check het verschil maakt tussen veilig en gehackt).

Bij mijn klanten zie ik dat developers die Auto Mode standaard aan hebben staan, gemiddeld een halve dag per week kwijt zijn aan het terugdraaien van AI-wijzigingen die ergens fout zijn gegaan. Een halve dag per week is meer dan de tijd die Auto Mode je oplevert. Doe de rekensom.

Mijn werkwijze: Auto Mode aan en uit per opdracht

Ik switch Auto Mode aan en uit per taak, niet per project. Een rename-taak doe ik in Auto Mode, een feature-implementatie doe ik in handmatige mode. Dat klinkt rommelig, maar het is na een paar weken een gewoonte.

Wat dat in de praktijk betekent: voordat ik een opdracht aan Claude geef, vraag ik mezelf “kan deze taak iets stuk maken dat moeilijk te herstellen is?” Bij ja, Auto Mode uit. Bij nee, Auto Mode aan.

Per opdracht switch je via een commando in Claude Code zelf. Dat zijn drie tikken op het toetsenbord, niet meer. Het toelaten van die switching-overhead is de kleine prijs voor het voorkomen van grote correcties achteraf.