Wat is Model 2 en hoe sterk is het precies?

Anthropic heeft intern een model in gebruik dat ze Model 2 noemen, ingedeeld in de Mythos-klasse. Op hun interne capaciteitsindex, de AECI, scoort het 1,5 punten hoger dan Claude Mythos 5, het sterkste model dat nu publiek beschikbaar is. Dat klinkt indrukwekkend, maar de sprong is kleiner dan de stap van Mythos Preview naar Mythos 5. Model 2 is op sommige vlakken zelfs zwakker dan Mythos 5. Geen grote generatiesprong dus, eerder een incrementele verbetering.

De AECI is een verzameling interne benchmarks waarmee Anthropic bijhoudt hoe capabel hun modellen zijn. Benchmarks zijn altijd een momentopname: ze meten wat je ervoor kiest te meten. Dat Anthropic zelf zegt dat Model 2 slechts 1,5 punt hoger scoort, is waarschijnlijk eerlijk, maar het is ook hun eigen meetlat.

Wat meer zegt: Anthropic omschrijft het verschil als ‘iets sterker overall, maar zwakker op sommige gebieden’. Dat is geen doorbraak. Het is een fijnafstelling. Ze trekken geen grote conclusies over wat dit model anders maakt. Opvallend voor een bedrijf dat normaal graag over haar modellen communiceert.

Voor de context: als je nu al werkt met Claude Code en de bijbehorende gebruikslimieten, dan is dit het soort model dat intern de basis vormt voor verdere ontwikkeling. Jij ziet het niet, maar het beïnvloedt wel hoe het systeem zich verder ontwikkelt.

Schrijft AI nu de code van een AI-bedrijf zelf?

Ja, en dat is misschien wel het meest concrete gegeven uit dit verhaal. Anthropic meldt dat Claude inmiddels het grootste deel van de code schrijft die in hun eigen productiesystemen draait. Model 2 zit daar middenin, deels via agents die continu doorwerken. Het model is intern gereviewed, maar minder grondig getest dan Mythos 5 publiek is getest. Anthropic ziet geen nieuwe of zorgwekkendere vormen van misalignment.

Misalignment is een term uit AI-veiligheidsonderzoek. Het betekent dat een model doelen nastreeft die niet overeenkomen met wat mensen bedoelen of willen. Anthropic zegt dat de risico’s hierop ‘laag’ zijn voor Model 2, en dat ze bij de interne review niks nieuws of verontrustends hebben gevonden.

Dit is een vrij openhartige mededeling. De meeste AI-labs vertellen je niet welk model ze intern gebruiken, laat staan dat ze zeggen dat het hun eigen productiecode schrijft. Dat Anthropic dit publiceert in een risicoreport, is een teken dat ze hun veiligheidscommunicatie serieus nemen.

Of dat genoeg is? Dat is een andere vraag. Lees ook hoe Anthropic zijn veiligheidsnormen aanscherpt. Dit past in dat patroon: transparantie over wat er intern gebeurt, ook als het ongemakkelijk is.

Wat betekent dit als je nu Claude gebruikt voor je werk?

Eerlijk gezegd: weinig direct. Je hebt geen toegang tot Model 2, en er zijn geen plannen om dat te veranderen. Wat je meeneemt: het beste model van een AI-lab is zelden het model dat jij kunt gebruiken. Dat geldt voor Anthropic, maar ook voor andere labs. De publieke modellen zijn krachtig genoeg voor het meeste werk. Maar denk je dat je het absolute topmodel gebruikt? Dat klopt waarschijnlijk niet.

De kloof tussen intern gebruik en publieke toegang is structureel. Dat is niet per se erg. Labs testen nieuwe modellen eerst intern voor ze ze breed uitrollen. Dat is verantwoord. Maar het betekent ook dat als jij nu Claude Mythos 5 gebruikt, je werkt met een model dat intern al ingehaald is.

Voor de meeste taken maakt dat niks uit. Gebruik je Claude om tekst te schrijven, code te reviewen of vragen te beantwoorden? Dan is Mythos 5 meer dan krachtig genoeg. De 1,5 punten extra die Model 2 scoort op een interne index, vertalen zich niet automatisch naar merkbaar betere output op alledaagse taken.

Waar het relevant wordt: als je AI inzet voor complexe, meerstaps-taken zoals AI-agents die als ontwikkelteam werken. Dan kunnen kleine capaciteitsverschillen op de marge groot worden. Maar dat is voor de meeste Nederlandse ondernemers nog toekomstmuziek.

De echte les hier is een andere: vergelijk AI-modellen niet op basis van wat labs intern gebruiken, maar op basis van wat jij ermee doet in de praktijk. De eerlijke vergelijking tussen ChatGPT Pro en Claude is relevanter dan het bestaan van een model dat je toch niet kunt aanraken.

Wat is steganografie in AI-output precies?

Steganografie betekent letterlijk ‘verborgen schrijven’. Bij AI-tekst gaat het om het insluiten van data in gewone zinnen, onzichtbaar voor de lezer. Niet via een zichtbaar label of disclaimer, maar via subtiele woordkeuzes en interpunctie die voor een mens niets betekenen, maar voor een algoritme wél. Dit verschilt van watermerken, waarbij de statistische verdeling van woorden wordt beïnvloed. Bij steganografie zit de informatie in de inhoud zelf.

Stel je voor dat een AI twee bijna identiek goede woorden kan kiezen: ‘gebruiken’ of ’toepassen’. Voor jou maakt het niet uit. Maar als het systeem stelselmatig kiest op basis van een verborgen bitpatroon, dan codeert het data in je tekst zonder dat je het ziet.

Dat is de kern van steganografische markering: de AI exploiteert het feit dat er bij elke generatiestap meerdere tokens zijn met nagenoeg gelijke kans. Door die keuzes te sturen op basis van een payload, kun je informatie insluiten. Denk aan je account-ID, een tijdstempel of een hash van je input-prompt.

Dit is anders dan statistische watermerken, waarbij de kansverdelingen van tokens globaal worden bijgestuurd. Steganografie werkt op een fijnmaziger niveau en is daardoor moeilijker te detecteren of te verwijderen. Zelfs als je de tekst licht herschrijft, kunnen bepaalde patronen bewaard blijven.

Voor wie meer wil weten over hoe AI-veiligheid en monitoring bij Anthropic werken: ik schreef eerder over hoe Anthropic zijn veiligheidsnormen aanscherpt en wat dat voor gebruikers betekent.

Heeft Anthropic dit daadwerkelijk ingebouwd in Claude?

Anthropic heeft dit nooit bevestigd. Ze hebben het ook nooit ontkend. Technisch gezien is de architectuur geschikt voor dit soort markering, en de zakelijke prikkels zijn duidelijk: traceerbaarheid helpt bij misbruikbestrijding. Community-onderzoeken hebben variatie gevonden in Claude-output bij identieke prompts, maar geen peer-reviewed bewijs dat dit steganografisch van aard is.

Dit is het punt waarop je als nuchtere ondernemer even moet schakelen. Er zijn drie dingen die we weten:

1. Het is technisch mogelijk. De architectuur van grote taalmodellen laat dit toe. De mechanismen zijn goed begrepen in de academische wereld.

2. De prikkels zijn er. Als Anthropic wil kunnen achterhalen welk account misbruik maakt van de API, is steganografische markering een elegante oplossing. Effectiever dan IP-logging, want de marker zit in de tekst zelf.

3. Er is geen bewijs dat het bestaat. Onderzoekers in de community hebben identieke prompts honderden keren gestuurd naar de Claude API en variatie gevonden in de output, zelfs bij temperature=0. Maar dat kan ook komen door infrastructurele niet-determinisme, iets wat Anthropic zelf erkent. Je kunt de twee niet onderscheiden zonder extra controles.

Naar mijn idee is dit een vraag die Anthropic gewoon zou moeten beantwoorden in hun documentatie. Transparantie over output-modificaties is redelijk als je een API aanbiedt waarop anderen commerciële producten bouwen. Dat ze het niet doen, zegt op zichzelf iets, al is dat geen bewijs.

Check ook hoe Claude zich gedroeg tijdens beveiligingstests waarbij het ongeautoriseerde acties uitvoerde: ook daar stelde Anthropic’s eigen monitoring zich vragen bij transparantie.

Wat kan er verborgen zitten in Claude’s output?

Als steganografische markering bestaat in Claude, dan zijn de meest waarschijnlijke payloads je API-sleutel of account-ID, een tijdstempel of sessie-identifier, misbruikmarkeringen en mogelijk een hash van je input-prompt. Kortere antwoorden hebben minder ruimte voor zo’n payload. Langere teksten bieden meer kanaal-capaciteit voor verborgen data.

Kijk even wat dit concreet zou betekenen. Je vraagt Claude via de API om een productomschrijving te schrijven. Die tekst publiceer je op je webshop. Als die tekst een verborgen marker draagt die herleidbaar is naar jouw API-sleutel, dan is elk stuk content dat je publiceert potentieel gelinkt aan jouw identiteit.

Dat hoeft geen probleem te zijn als je netjes binnen de gebruiksvoorwaarden werkt. Maar het roept wel vragen op:

• Wat gebeurt er als jouw API-sleutel wordt gestolen en de dief content genereert die via jou herleidbaar is?
• Wat als je content distribueert namens klanten en die content markers draagt die naar jou wijzen?
• Wat betekent dit voor sectoren waar anonimiteit of bronbescherming juridisch relevant is?

De payloads met de hoogste waarschijnlijkheid zijn account-identifiers en tijdstempels. Die zijn compact en passen in een beperkte steganografische bandbreedte. Een volledige prompt-hash zou meer bits vereisen en is dus minder waarschijnlijk bij korte antwoorden.

Let op: dit zijn hypothetische scenario’s gebaseerd op de technische mogelijkheden, niet op bevestigde implementaties. Maar hypothetisch of niet, het is de moeite waard om je beleid hierop aan te passen.

Kun je zelf testen of Claude markers in output zet?

Je kunt variatie in Claude-output analyseren door identieke prompts meerdere keren te sturen bij temperature=0 en de resultaten te vergelijken. Als de output verschilt, kan dat wijzen op steganografische markering, maar ook op infrastructurele niet-determinisme. De twee zijn moeilijk te onderscheiden zonder gecontroleerde omgeving met meerdere API-accounts.

De methodologie die onderzoekers hanteren is simpel in opzet. Je stuurt dezelfde prompt tientallen keren naar de API, met temperature op nul zodat de output zo deterministisch mogelijk is. Dan analyseer je op welke posities de output verschilt en of dat patroon correleert met je account of sessie.

Praktisch probleem: Anthropic garandeert geen deterministische output, ook niet bij temperature=0. Floating-point berekeningen op verschillende servers kunnen kleine variaties veroorzaken die niets met steganografie te maken hebben. Je hebt dus minimaal twee verschillende API-accounts nodig om te vergelijken of de variatie account-gebonden is.

Een basistest in Python ziet er zo uit:

pip install anthropic

Daarna stuur je dezelfde prompt twintig keer en sla je elke response op. Vergelijk de resultaten op tokenniveau. Als je bij identieke prompts meerdere verschillende antwoorden ziet, is dat het startpunt voor verder onderzoek, maar geen bewijs op zichzelf.

Eerlijk gezegd: tenzij je een specifieke compliance-reden hebt om dit te onderzoeken, is de kans klein dat je als individuele ondernemer de infrastructuur hebt om dit goed te controleren. Behandel het als een open vraag en pas je werkwijze aan op basis van dat risico, niet op basis van bewijs dat je zelf niet kunt leveren.

Wat doe je nu als je de Claude API zakelijk gebruikt?

Je hoeft niet te stoppen met Claude. Maar je kunt wel bewuster omgaan met wat je met de output doet. Behandel gegenereerde tekst als potentieel herleidbaar, werk nooit met een gedeelde API-sleutel voor meerdere klanten, en houd je ogen open als Anthropic ooit documentatie publiceert over output-modificaties.

Mijn standpunt hierover is pragmatisch. Ik gebruik Claude zelf voor allerlei werk, van code schrijven tot teksten opstellen. Ik ga daar niet mee stoppen op basis van een onbevestigde hypothese. Maar ik pas mijn werkwijze op een paar punten aan:

Gebruik nooit één API-sleutel voor meerdere klanten. Als die sleutel in output-markers zit, dan is content van klant A herleidbaar naar dezelfde sleutel als content van klant B. Dat is een privacyprobleem, ongeacht of steganografie bestaat.

Publiceer nooit onbewerkte API-output in gevoelige contexten. Als je in een sector werkt waar bronbescherming, anonimiteit of vertrouwelijkheid wettelijk relevant is (journalistiek, juridisch, medisch), dan wil je sowieso niet onbewerkte AI-tekst publiceren zonder review. Dat geldt ongeacht steganografie.

Houd Anthropic’s documentatie in de gaten. Als ze ooit iets publiceren over output-markering, wil je dat weten. Zet een Google Alert op ‘Anthropic output marking’ of ‘Claude watermarking’.

Voor wie werkt met Claude Code op enterprise-niveau: de limieten zijn verruimd, maar de transparantievragen rondom output blijven hetzelfde. Vraag het na bij je accountmanager als je een enterprise-deal hebt.

Wat is er precies veranderd

Anthropic heeft de capaciteit voor Claude Code uitgebreid na deals met grote afnemers. Concreet betekent dat hogere usage-limieten op alle abonnementsniveaus, plus minder snel ratelimit-fouten tijdens lange coding-sessies.

De aanleiding is enterprise-vraag: SpaceX en een paar andere grote afnemers hebben deals gesloten die de capaciteit aan de Anthropic-kant flink omhoog hebben getrokken. Die extra ruimte komt deels ook beschikbaar voor de gewone Pro- en Max-abonnementen.

Eerlijk gezegd merkte ik de oude limieten alleen wanneer ik een hele middag aan één klantproject werkte met veel grote files in context. Wie Claude Code een paar keer per dag gebruikt voor losse vragen, loopt ze nooit aan. Voor de zware gebruikers verandert het wel iets.

Voor wie is dit relevant

Vooral voor developers die Claude Code als hoofdtool gebruiken bij grote refactors of in agentische workflows met meerdere parallelle taken. Voor occasionele gebruikers is het verschil nauwelijks merkbaar.

Bij mijn klanten zie ik dat de meeste developers Claude Code een paar uur per dag inzetten, met regelmatige pauzes. Die groep merkt geen verschil, want zij hebben de limieten zelden geraakt.

Wat wel verandert: agentische workflows die zelfstandig meerdere stappen uitvoeren (lees, schrijf, test, commit) werken nu langer door zonder onderbreking. Dat is winst voor wie Claude in CI/CD-pijplijnen gebruikt of als achtergrond-assistent op meerdere repositories tegelijk laat draaien.

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.

Hoe ik dit voor het eerst gebruikte

Een klant stuurde me een Figma-link met een dashboard-design dat ik in React moest bouwen. In plaats van handmatig elke component over te tikken, plakte ik de link in Claude met de instructie om het op te bouwen volgens mijn vaste stack. Tien minuten later had ik 80 procent werkende code.

De setup is simpel als je het eenmaal hebt gedaan. Je gebruikt de Figma MCP-server (open-source, een halve dag installatie) of je exporteert het frame als afbeelding plus design-tokens. Claude heeft dan toegang tot de structuur van het design en de specifieke kleuren, fonts en spacing.

De winst van die eerste ervaring: een dashboard waar ik normaal een halve werkdag mee bezig was, was binnen anderhalf uur live. Niet pixel-perfect, niet helemaal volgens mijn smaak, maar werkend en op klanten-stijl. De rest was handmatig finetunen.

Wanneer dit echt goed werkt

Bij design systemen met duidelijke components, herhaalbare patterns en consistente naamgeving. Een Figma-bestand met losse "schermen" zonder component-structuur geeft veel slechtere code. Hoe schoner de Figma, hoe beter de output.

Wat de output kwalitatief onderscheidt: of de designer in Figma met components heeft gewerkt of met losse rechthoeken en tekstvelden. Een Figma-bestand met “Button/Primary”, “Card/Default” en “Input/WithLabel” als components geeft Claude direct herhaalbare React-componenten terug. Een bestand met 20 versies van een knop die elk net iets anders zijn, geeft 20 versies van dezelfde knop in code.

Mijn tip aan klanten en designers: investeer in de Figma-setup vóór de developer eraan komt. Een halve dag componenten netjes inrichten in Figma scheelt later twee dagen handmatige React-arbeid. Dat is een hele goede ROI.

Wat Claude nog niet goed doet

Animaties, complexe state-handling, en alles wat dynamisch reageert op data. Een Figma toont meestal een statische staat. Claude raadt redelijk goed wat dynamisch zou moeten zijn, maar voor productie-kwaliteit is dat altijd handmatig nawerk. Plus: design-tokens vertaalt hij niet altijd naar jouw setup.

Concreet bij een laatste project: Claude zette de visuele kant van een filters-paneel goed neer, maar de logica voor het opslaan van de filterstatus, het synchroniseren met URL-params en het handelen van loading-states moest ik zelf bouwen. Dat is werk dat in geen enkele Figma staat, dus dat is logisch.

Wat ik er bij klanten over zeg: gebruik dit voor de eerste 80 procent van het visuele werk. De laatste 20 procent (interactie, edge-cases, prestatie-optimalisatie) blijft mensenwerk. Wie deze grens niet trekt, levert demo-kwaliteit op aan klanten en raakt klant en project allebei kwijt.

Hoe Extensions in de praktijk werken

Stel je voor: je zegt "Hé Siri, schrijf een korte mail naar Pieter dat de afspraak van morgen verzet wordt naar volgende week dinsdag." In iOS 27 kun je instellen dat dit soort verzoeken naar de AI van jouw keuze gaan in plaats van naar Siri zelf.

Apple heeft Siri jarenlang als beperking gezien naast wat ChatGPT of Claude konden. Extensions is hun antwoord: laat de gebruiker zelf kiezen, en houd Siri voor de basics (timers, muziek, navigatie).

In de praktijk: je opent Instellingen, kiest welke AI je wilt voor welke type vraag, en daarna routeert iOS automatisch. Eenvoudige opdrachten blijven bij Siri, complexere of taalrijkere taken gaan naar de gekozen AI. Apple-stijl: niet schreeuwerig, gewoon instelbaar.

Welke AI past bij welk werk

ChatGPT is sterkst in gespreksachtige interactie en algemene kennis. Claude is sterker in langere schrijftaken en code-reflectie. Gemini integreert het diepst met Google Workspace. Voor de meeste ondernemers is ChatGPT de veiligste eerste keuze.

Wat ik bij klanten zie: wie veel onderweg dicteert en samenvatten wil, kiest ChatGPT. Wie hele e-mails laat schrijven of code wil bespreken, voelt zich sneller thuis bij Claude. Wie diep in Google Calendar, Docs en Gmail leeft, profiteert het meest van Gemini.

Mijn eigen voorkeur op de iPhone: Claude voor schrijfwerk, Siri voor de korte commando’s. ChatGPT staat ook geïnstalleerd voor wanneer ik iets wil opzoeken in een gesprekvorm. Drie installs, een paar tikken om te switchen.

Wat dit zegt over de telefoon-AI-toekomst

Apple geeft de keuze terug aan de gebruiker en heeft daarmee het AI-assistent-spel weer open gezet. Op middellange termijn betekent dit waarschijnlijk dat AI-bedrijven beter geïntegreerde mobile-experiences gaan bouwen, omdat ze nu directe toegang hebben tot Siri-events.

Voor jou als ondernemer is de directe winst klein: je krijgt een paar extra opties in de instellingen. Voor de bredere markt is dit groter: AI-bedrijven hebben nu een prikkel om hun mobile-experience serieus aan te pakken, niet alleen hun web-app.

Ik verwacht dat we komend jaar betere voice-experiences zullen zien van Anthropic en OpenAI specifiek voor mobiel gebruik. Voor wie veel onderweg werkt is dat goed nieuws.

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.