AI Development

AI-agents als ontwikkelteam: hoe ik dit bij klanten inzet

• 7 min leestijd • Sepp •
AI-agents als ontwikkelteam: hoe ik dit bij klanten inzet

Foto: cottonbro studio via Pexels

Kort antwoord

Met AI-agents bedoel ik gespecialiseerde Claude- of ChatGPT-rollen die elk één deel van je project doen: een agent voor frontend, een voor API-werk, een voor tests, een voor security-review. Door elke agent specifieke context te geven over jouw stack, krijg je gerichtere output dan met één generieke AI-sessie. Bij mijn klanten gebruik ik dit voor projecten vanaf middelgrote complexiteit. Voor een simpele landingspagina is het overkill.

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.

Conclusie

Mijn eerlijke kijk: AI-agent-teams zijn geen hype als je ze gericht inzet op het juiste type project. Voor MKB-bouwwerk vanaf een week is het bij mij een vaste werkwijze geworden, niet een experiment. De winst zit niet in dat AI ineens slimmer wordt, maar in dat je AI dwingt zich te beperken tot één rol per keer. Dat is een eenvoudig idee met een groot effect. Probeer het eens op een nieuw project, begin met twee agents, en kijk of het bij jouw werkwijze past.

Veelgestelde vragen

Niet per se. Met één Pro-account kun je meerdere chats parallel openen, elk met eigen rol-instructie. Voor zware setups met vier of meer agents tegelijk loop je tegen ratelimits aan, daar werkt een Max-account beter. Of een combinatie van Claude Pro plus ChatGPT Pro voor verschillende agent-rollen.

Ja, het concept werkt op elke AI met een chat-context. Bij ChatGPT gebruik je Custom GPTs voor de rol-instructies, bij Claude gebruik je Projects of system-prompts. Het verschil zit in hoe goed elke AI grote contexten vasthoudt. Claude is op dit moment beter in lange code-context, ChatGPT in algemene gesprekken.

Door een centrale "architect"-agent of een gedeeld document waar alle agents naar verwijzen. Bij mij is dat een DESIGN.md (zie ook mijn artikel over DESIGN.md voor AI-tools) plus een korte API-contract-file die elke agent leest voor hij iets aanmaakt. Dat voorkomt dat je frontend praat met een API-endpoint dat de backend nooit heeft gebouwd.

Technisch ja, in agent-mode of via tools zoals GitHub Copilot Workspace. Bij mijn klantprojecten doe ik dat niet: ik laat agents code voorstellen, ik commit zelf. Dat houdt mijn naam aan elke commit en ik blijf eindverantwoordelijk voor wat er in de repository belandt. Voor experimentele zelf-projecten kan autonoom committen wel.

Dat gebeurt regelmatig en is meestal nuttig. De security-agent zegt "deze API heeft authenticatie nodig", de backend-agent denkt "deze endpoint is publiek". Conflict is een signaal dat de architectuurkeuze nog niet helder is. Op die momenten stop ik de uitvoering en kies eerst zelf wat het wordt, daarna laat ik beide agents weer doorwerken.

Meer over Webdevelopment