Je schrijft geen code, je runt een “AI-team”

De meeste mensen gebruiken een Coding Agent alsof ze nog steeds techlead zijn: systeemontwerp persoonlijk bewaken, elke codereview regel voor regel, niks committen zonder alles zelf te hebben gezien. Kwaliteit gegarandeerd, ja. Maar de prijs? Jij bent het grootste knelpunt in de productielijn. Elke beslissing wacht op jou, elk detail gaat langs jou, en de productiviteit van de Agent wordt muurvast gehouden door jouw tijd en aandacht.

Zelfstandige ontwikkelaars die er echt geld mee verdienen, hebben allang een cruciale rolwissel gemaakt: van TL naar EM. In gewone mensentaal: als TL staar je je blind op elke regel code, als EM kijk je alleen of het resultaat werkt. De TL vraagt “is deze code correct”, de EM vraagt “is deze feature geaccepteerd”. Die verschuiving lijkt subtiel, maar schaalt je output van “één persoon” naar “een heel team”.

Waarom loslaten nu kan: de modellen zijn over het kantelpunt

Loslaten vereist dat de code goed genoeg is. Die voorwaarde is dit jaar vervuld: op gangbare publieke benchmarks scoort de topgeneratie modellen boven de tachtig procent correctheid, met een verpletterende voorsprong op de vorige generatie (exacte scores verschillen per meetmethode — check zelf de actuele cijfers op Artificial Analysis en SWE-Bench, en vertrouw geen enkele samenvatting van iemand anders, ook niet van mij).

Wat betekent dat? Dat AI-code met lichte verificatie vrijwel nooit fundamenteel de mist in gaat, en dat de marginale waarde van jouw regel-voor-regel review te laag is geworden om te rechtvaardigen. Doorgaan als TL betekent je duurste uren besteden aan de goedkoopste kwaliteitscontrole. De markt betaalt niet voor jouw “gevoel van zekerheid”. Klanten betalen voor geleverde resultaten.

Route één: vervang micromanagement door “planbevestiging + doelsturing”

Hoe ziet dat er concreet uit? Stap één is je workflow aanpassen. Zodra je weet welke feature je wilt bouwen, loop je eerst met de Agent het technische plan door. Plan akkoord? Dan geef je het doel plus het plan aan de Agent en laat je hem alles doen: code schrijven, geautomatiseerde tests draaien. Jouw enige taak is achteraf de feature zelf accepteren — niet de code inspecteren.

Hier is een prompttemplate die je direct kunt kopiëren:

1
2
3
4

Ik wil bouwen: [feature-beschrijving].
Randvoorwaarden: [tech stack / platform / verplichte compatibiliteit].
Lever eerst een technisch plan met: 1) module-indeling; 2) dataflow; 3) verwachte valkuilen.
Pas na mijn akkoord schrijf je code. Draai daarna zelf de tests en plak de resultaten hier.

Voor de acceptatie gebruik je een checklist die kwaliteit borgt zonder code te openen:

• Hoofdflow handmatig doorlopen, geen fouten op het hoofdpad
• Per randgeval één test (lege input, extreem lange input, geen netwerk)
• Alle door de Agent toegevoegde geautomatiseerde tests slagen
• Bij een bug niet zelf de code induiken: beschrijf het symptoom aan de Agent, laat hem reproduceren, fixen en een test toevoegen — daarna accepteer je opnieuw

De kern van deze aanpak: je verplaatst het verificatiemoment naar voren. Als TL verifieer je op codeniveau, wat belachelijk duur is. Als EM verifieer je op feature-niveau: even klikken, even draaien, klaar in een paar minuten. In de hele cyclus gaat jouw tijd naar maar twee dingen: helder krijgen wat er gebouwd moet worden, en bevestigen dat het klopt.

Route twee: technologiekeuze van “wat kan ik” naar “wat past het best”

De rolwissel heeft een verborgen bonus: je technologiekeuze wordt niet langer gegijzeld door je eigen grenzen. In TL-denken kies je onbewust de stack die je kent, want dan kun je problemen zelf fixen. In EM-denken beoordeel je alleen welke technologie het beste bij het project past — de rest is aan de Agent.

Een zelfstandig ontwikkelaar beschreef dit traject (volgens zijn eigen post, niet onafhankelijk geverifieerd): voor een ondertitelings-app koos hij eerst Electron omdat hij frontend kende, maar de performance bleef tegenvallen. Daarna stapte hij over op Swift + AppKit — een stack die hij niet kende — en met AI-ondersteuning verliep alles soepel. Voor zijn volgende cross-platform product koos hij meteen Rust, een taal die hij nooit had geschreven. Of dat verhaal klopt moet je zelf beoordelen, maar de onderliggende logica kun je vanavond testen: pak een stack die je niet kent en laat de Agent je door een tooltje van honderd regels loodsen. Kijk of je vastloopt. Kortom: je eigen kennis is geen excuus meer — je kiest gewoon wat optimaal is.

Route drie: maak iteratiesnelheid je concurrentievoordeel — en reken even mee

Draait dit systeem eenmaal, dan krimpt je doorlooptijd van weken naar dagen. De klant geeft ‘s ochtends een wens door en ziet ‘s middags een acceptabele versie. Concurrenten releasen wekelijks, jij dagelijks. Op Marktplaats, Lemon8 en Upwork bieden genoeg mensen AI-ontwikkelopdrachten aan, maar de meesten zitten nog in de fase “AI helpt mij typen”. Met de EM-aanpak speel je in een andere divisie.

Concepten zijn leuk, maar laten we rekenen (conservatieve schatting — vul je eigen tarieven in):

• Voorbeeldopdracht: maatwerk tooltje of mini-app, gemiddelde orderwaarde € 250
• TL-modus: één opdracht kost 5 dagen inclusief aanpassingen, maximaal 4 opdrachten per maand → € 1.000 per maand
• EM-modus: plan + acceptatie kost 1,5 dag, terwijl de Agent draait pak je de volgende opdracht erbij — effectief 2 dagen per opdracht, 8 tot 10 opdrachten per maand → € 2.000–2.500 per maand
• Kostenkant: AI-abonnement maximaal € 40 per maand, rework na acceptatiechecklist circa 10%, reserveer per opdracht een halve dag buffer

Kortom: dezelfde maand, maar ruim € 1.000 verschil — en in EM-modus is je knelpunt het aantal opdrachten, niet je typesnelheid. Zet “werkende versie binnen 48 uur” op je opdrachtpagina en je hebt een onderscheid dat niemand zomaar kopieert.

Het enige echte knelpunt: jij moet weten wat je wilt bouwen

Dit model heeft een eerlijke beperking: zodra je een nieuwe grote versie of productrichting moet bedenken, word jij weer het knelpunt. Hoe sterk de Agent ook is, hij kan alleen uitvoeren wat jij helder hebt gedefinieerd. Geen helder doel, geen enkele bruikbare regel code.

Daarom stelt de EM-modus juist hogere eisen aan jou — niet qua technische diepgang, maar qua productoordeel. Je moet tijd steken in wat klanten zoeken op Marktplaats en Amazon, welke frustraties op Pinterest en Lemon8 terugkomen, welke tool-content op TikTok viral gaat. Alle uren die je bespaart op codereviews investeer je in “helder krijgen wat er gebouwd moet worden”. Dáár hoort de mens in dit model te zitten.

Vandaag beginnen: drie stappen naar de rolwissel

Nog geen opdrachten binnen? Begin dan klein: zet op Marktplaats een advertentie voor “AI-tooltjes op maat”, prijs € 50–100, en doorloop met die eerste opdracht de drie stappen hieronder. Zo bouw je een herbruikbare workflow én een realistisch prijsgevoel.

Stap één: pak een klein lopend project en verbied jezelf om codebestanden te openen. Alleen een plan schrijven, een doel geven en de feature accepteren — één volledige EM-cyclus, met tijdsregistratie. Dat is je eigen eerstehands data, meer waard dan welke case study ook. Stap twee: maak “bug eerst aan de Agent beschrijven voor reproductie en fix” een reflex. Niet zelf de code inspringen, nooit. Stap drie: kies voor je volgende project bewust een stack die je niet kent maar die het beste past, en test of AI je erdoorheen draagt.

Het kantelpunt in AI-codeervermogen is gepasseerd. Het voordeel verschuift van “mensen die met AI kunnen coderen” naar “mensen die een AI-team kunnen aansturen”. Kies vanavond één project en draai de EM-workflow met het template en de checklist hierboven.