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.