Welke stacks werken goed met AI-codeertools?

AI-codeertools schrijven de beste code in stacks met statische types, vaste conventies, snelle tests en een veelgebruikt framework. In mijn ervaring werken TypeScript met een gangbaar framework, C# met ASP.NET Core en Python met type hints goed. Een eigen framework zonder types en zonder tests werkt slechter. Dat ligt minder aan de taal dan aan hoeveel feedback de tool krijgt.

Types geven direct feedback

Een tool als Claude Code werkt in een lus: code schrijven, controleren en herstellen wat faalt. Hoe meer fouten de controle vindt, hoe beter het resultaat, en een typechecker is de snelste controle die je hebt.

Mündler en collega's onderzochten in 2025 TypeScript die door taalmodellen was gegenereerd. Gemiddeld 94 procent van de compileerfouten kwam uit de typecheck. In een taal zonder statische types zie je diezelfde fouten pas als de code draait, of als een gebruiker ze vindt.

GitHub legt in het Octoverse-rapport van 2025 een verband tussen de groei van TypeScript en AI. In augustus 2025 werd TypeScript voor het eerst de taal met de meeste maandelijkse bijdragers op GitHub. Volgens GitHub stappen developers over op getypeerde talen omdat werken met AI-agents daar betrouwbaarder door wordt.

Werk je in Python of PHP, dan haal je een deel van dit voordeel met type hints en een checker als mypy, pyright of PHPStan in CI.

Types helpen alleen als de data aan de randen klopt. Valideer wat binnenkomt uit API's en formulieren met een schema, bijvoorbeeld met Zod in TypeScript of Pydantic in Python. Dan kan de tool verderop op de types vertrouwen.

Conventies helpen de tool kiezen

Frameworks met vaste conventies, zoals Next.js, Laravel, Django of ASP.NET Core, vertellen de tool waar dingen horen. Een route staat op een vaste plek, een migratie ook, dus de tool hoeft niet te raden.

Consistentie binnen je eigen codebase telt nog zwaarder. Zijn er drie manieren om een API-call te doen, dan kiest de tool er een, en misschien de verkeerde. Ruim zulke dubbele patronen op, of schrijf op welke de goede is.

Laat ook een formatter en een linter automatisch draaien. De tool ziet dan meteen wat er aan de stijl niet klopt, en jij hoeft er in de review niets meer over te zeggen.

Populaire frameworks leveren betere code op

Taalmodellen hebben veel publieke code gezien, en van React, Django of Spring Boot bestaat veel meer publieke code dan van een nichebibliotheek. Dat zie je terug in wat het model schrijft. In mijn ervaring verzint een model vaker functies die niet bestaan als het framework weinig gebruikt wordt.

Hetzelfde geldt voor nieuwe versies. Een versie die na de trainingsdatum uitkwam, kent het model minder goed, waardoor het terugvalt op oudere patronen. Zet in je instructiebestand welke versie je gebruikt en wat er anders is, of geef de tool de documentatie van die versie mee.

Tests moeten snel en betrouwbaar zijn

Een tool die zijn eigen werk kan testen, levert betere code op. Daarvoor moeten de tests wel snel zijn en elke keer hetzelfde resultaat geven. Een suite die twintig minuten duurt of af en toe zonder reden faalt, geeft de tool geen bruikbaar signaal.

Mijn advies is om één commando voor de unittests te hebben dat binnen een minuut klaar is. Zet dat commando in het instructiebestand, dan draait de tool het na elke wijziging.

Bij een bug werkt een vaste volgorde goed: laat de tool eerst een test schrijven die faalt, en pas daarna de fix. Dan weet je dat de test echt iets controleert.

Schrijf de afspraken op

Claude Code leest aan het begin van elke sessie CLAUDE.md. Veel andere tools, zoals Cursor, Codex en de coding agent van GitHub Copilot, lezen AGENTS.md, een open formaat dat nu onder de Linux Foundation valt. Claude Code leest AGENTS.md ook als er geen CLAUDE.md is. Zet erin hoe je bouwt en test, welke conventies gelden en welke mappen de tool met rust laat. Welke afspraken je verder als team maakt, beschreef ik in mijn stuk over AI-codeertools in een remote team.

Oudere stacks vragen meer controle

Bij .NET Framework met Web Forms, PHP zonder types of bedrijfslogica in stored procedures heeft de tool minder houvast. Het kan wel, maar je moet meer controleren.

Herschrijven is zelden de oplossing. Voeg types en tests toe rond de code die je aanpast, en leg vast hoe het systeem in elkaar zit. Daar hebben de tool en de volgende developer allebei iets aan. Voor zulke stacks zoek je ook andere mensen. Maarten schreef over developers vinden voor oudere stacks.

Kies je stack niet om de tool

Een AI-tool is één factor bij een stackkeuze. Wat je team kent en welke code er al ligt, wegen zwaarder. Een team dat goed is in Laravel, haalt met AI-tools meer uit Laravel dan uit een stack die het maar half kent. Met welke stacks wij werken, zie je op onze technologiepagina.

Bronnen

• GitHub, Octoverse 2025
• Mündler e.a., Type-Constrained Code Generation with Language Models (2025)
• Claude Code, CLAUDE.md en AGENTS.md
• AGENTS.md