AI-tools in echte projecten: wat werkt en wat niet

De afgelopen twee jaar zijn AI-codeertools overgegaan van curiositeit naar dagelijks gereedschap. Copilot, Cursor, Claude, ChatGPT: er is geen tekort aan opties. Maar de discussie erover is nog steeds grotendeels zwart-wit: ofwel vervangen ze developers, ofwel zijn ze nutteloos. De werkelijkheid, zoals je zou verwachten, is genuanceerder.

Dit is wat we in de praktijk hebben gevonden na twee jaar AI-tools te gebruiken in echte klantprojecten.

Waar AI-tools echte tijdwinst opleveren

Boilerplate en repetitieve code

Het schrijven van de vijftiende formuliervalidatiemethode of de zoveelste Eloquent-scope is vervelend en foutgevoelig. AI doet dit soort werk snel en consistent. Je review de output, past aan waar nodig en gaat verder. Het bespaart tien tot vijftien minuten per sessie, en dat telt op.

Onbekende API's en bibliotheken verkennen

Wanneer je een API gebruikt die je niet kent, werkt een gesprek met een AI-tool sneller dan door documentatie scrollen. Je krijgt een werkend voorbeeld, stelt vervolgvragen en hebt doorgaans sneller een werkende integratie dan via de traditionele weg. Dit geldt ook voor minder gebruikte PHP-bibliotheken en frameworks.

Tests schrijven voor bestaande code

Terugwerkend tests schrijven voor bestaande code is een van de meest saaie taken in softwareontwikkeling. AI is hier opvallend goed in: geef de methode, vraag om unit tests, review de edge cases die het genereert. Niet elk gegenereerd testgeval is zinvol, maar de eerste opzet is in vijf minuten klaar in plaats van dertig.

Debuggen en uitleggen

"Waarom doet dit zich voor?" is een vraag waar een AI-tool verrassend nuttig bij is. Plak de foutmelding en de relevante code, en je krijgt doorgaans een fatsoenlijk startpunt voor het debuggen. Het is geen garantie, maar het bespaart regelmatig twintig minuten zoeken.

Waar AI-tools je vertragen of in de weg zitten

Architectuurbeslissingen

AI-tools zijn slecht in het adviseren over architectuur, omdat architectuur context vereist die zij niet hebben: de bedrijfslogica, de teamdynamiek, de historische keuzes in de codebase, de schaalverwachtingen. De output klinkt vaak overtuigend maar is generiek. Gebruik AI niet om architecturale keuzes te maken. Gebruik het om alternatieven te documenteren nadat je de keuze zelf hebt gemaakt.

Bestaande complexe codebases begrijpen

Wanneer je een grote, onbekende codebase probeert te begrijpen, is een AI-tool beperkt nuttig. Hij kan je uitleggen wat een geïsoleerde functie doet, maar hij ziet de verbanden niet die jij nodig hebt om het grotere geheel te begrijpen. Daar is systematisch lezen en doorvragen nog steeds beter.

Securitygevoelige code

Gegenereerde code bevat regelmatig subtiele beveiligingsproblemen: ontbrekende invoervalidatie, verkeerde verwerking van gebruikersdata, of verouderde cryptografische keuzes. Review elk stuk gegenereerde code dat met authenticatie, autorisatie of gebruikersinvoer omgaat alsof het van een junior developer komt. Vertrouw de output nooit blind.

Lange gegenereerde blokken zonder review

De verleiding om een groot stuk gegenereerde code te plakken en door te gaan is reëel, maar gevaarlijk. Gegenereerde code bevat bugs, verouderde patronen en soms subtiele logicafouten die er op het eerste gezicht correct uitzien. Als je geen tijd hebt om het te reviewen, had je het niet moeten genereren.

Hoe we het in de praktijk gebruiken

Na twee jaar experimenteren is ons gebruik gestabiliseerd op een paar patronen:

• Korte taken in een gesprek: voor code van minder dan vijftig regels werkt een directe prompt goed. Voor grotere taken verdeel je het werk in stappen.
• Altijd reviewen voor committen: gegenereerde code gaat nooit ongelezen de repository in. Altijd.
• Prompts verfijnen: de eerste output is zelden de beste. Geef context, geef voorbeelden van bestaande code in het project, en verfijn.
• Voor schrijven, niet voor beslissen: AI schrijft de code, jij beslist wat er geschreven wordt.

De eerlijke conclusie

AI-tools maken goede developers productiever. Ze maken het gemakkelijker om snel een idee te verkennen, boilerplate te schrijven en onbekende API's te leren. Ze vervangen geen goed oordeel over architectuur, security of productkwaliteit.

De developers die er het meeste uit halen, zijn degenen die precies weten wanneer ze een AI-tool moeten inschakelen en wanneer ze dat niet moeten doen. Dat is een vaardigheid die je opbouwt door te oefenen, net als elke andere.