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.

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.