Als Drupal developer laat ik dagelijks code schrijven door AI. Het scheelt tijd, en minstens zo belangrijk: het dwingt me om beter na te denken over wat ik precies aan het bouwen ben. Tegelijkertijd zie ik in de praktijk waar het misgaat, en dat gebeurt bijna altijd op dezelfde plek. In dit artikel deel ik hoe ik AI inzet, waar de grenzen liggen en welke regel ik voor mezelf hanteer.
AI is een uitstekende sparringspartner en werkvoorbereider
De grootste winst zit voor mij niet direct in het genereren van code, maar in het gesprek dat eraan voorafgaat. Een nieuwe feature begint bij mij zelden met typen. Het begint met het uitdenken en uitleggen.
Ik beschrijf wat er moet gebeuren, welke randvoorwaarden er zijn en hoe het systeem er nu uitziet. Vervolgens vraag ik door: hoe zou jij dit aanpakken? Welke alternatieven zijn er? Wat zijn de nadelen van deze richting op de lange termijn?
Dat werkt om twee redenen. Ten eerste dwingt het me om mijn eigen aanpak expliciet te maken. Als ik iets niet helder kan uitleggen aan een AI, heb ik het zelf ook nog niet goed genoeg doordacht. Ten tweede krijg ik opties aangedragen waar ik zelf niet direct aan had gedacht. Als mens zijn we namelijk snel geneigd te kiezen voor iets wat we kennen.
AI schrijft prima code, maar struikelt over de architectuur
Bij het daadwerkelijk schrijven van code wordt het verhaal genuanceerder. AI kan prima een functie schrijven, een hook in Drupal implementeren of een service opzetten. Op het niveau van losse stukken code gaat het vaak bijzonder goed.
De problemen ontstaan een niveau hoger. AI heeft de neiging om een oplossing te bedenken die exact het beschreven probleem oplost, maar zonder rekening te houden met de structuur die er al ligt. Ik krijg bijvoorbeeld een compleet nieuwe aanpak voorgesteld voor iets waar in de codebase allang een functie voor bestaat.
Soms wordt er ook een contrib module bij gehaald terwijl het prima met de functionaliteit in core kan. Of er wordt een module voorgesteld die slecht onderhouden wordt en een lange lijst openstaande issues heeft, terwijl je hetzelfde met een paar regels custom code voor elkaar krijgt.
Stuk voor stuk dingen die je als developer wilt voorkomen als je een onderhoudbare codebase wilt houden, ook als we weer een paar jaar verder zijn.
Ergens is het ook wel logisch dat AI dit doet. Het model kijkt namelijk naar de context die het krijgt en produceert iets dat daarbij past. Zonder die context heeft het geen beeld van waar het project over twee jaar staat, welke afspraken er zijn gemaakt of welk technisch compromis er drie jaar geleden bewust is gesloten.
Dat betekent dat hoe meer context ik meegeef, hoe bruikbaarder het advies wordt. Daarom leg ik in een soort handoff document zoveel mogelijk keuzes en beslissingen vast: waarom we voor een bepaalde aanpak hebben gekozen, welke alternatieven zijn afgevallen en welke afspraken er binnen het project gelden. Dat document gaat mee als context, zodat AI die kennis kan meewegen in plaats van er onbedoeld tegenin te werken.
Mijn proces: van sparren tot code review
Concreet ziet mijn werkwijze er zo uit.
- Sparren over de functionaliteit
Hoe zou dit moeten werken vanuit het perspectief van de gebruiker en de beheerder? Welke edge cases zijn er? Wat gebeurt er als iets misgaat? - Sparren over de uitwerking
Hoe bouwen we dit het beste? Welke alternatieven zijn er en wat zijn de afwegingen? Ingrijpende keuzes leg ik vast in een (M)ADR. Dat is een korte notitie in een vast format waarin staat waarom we voor deze richting hebben gekozen. - Een plan opstellen
Uit dat gesprek destilleren we samen een concreet plan. Ik ga pas verder als ik daar voor honderd procent achter sta. Twijfel ik nog over een onderdeel, dan gaan we terug naar stap twee. Een plan waar ik zelf niet in geloof, of dat ik niet helemaal begrijp, ga ik later ook niet kunnen verdedigen of onderhouden. - Uitwerken in de codebase
Pas dan gaan we schrijven. Samen, stap voor stap, met het plan als leidraad. - Automatische tests
Tests draaien is niet optioneel. Ze vangen niet alles, maar ze vangen wel de categorie fouten die je bij het lezen makkelijk over het hoofd ziet. - Volledige review
Alle wijzigingen worden nog een keer helemaal nagekeken en beoordeeld door mijzelf, voordat ze worden doorgevoerd in de codebase. Continu met de vragen in het achterhoofd: klopt dit met het plan, past dit bij de rest van de codebase, en zou ik dit zelf zo geschreven hebben?
De lat voor code kwaliteit en acceptatie gaat omhoog
Omdat code nu sneller te produceren is, verandert er iets aan je rol als developer. Code die er goed uitziet, is niet hetzelfde als code die klopt. En AI is ontzettend goed in doen alsof het goed is, compleet met overtuigende argumenten en voorbeelden. Dat vraagt erom om extra kritisch te zijn bij de vraag of het acceptabel is.
Vroeger liep je vanzelf tegen de grens van je eigen tempo aan. Die grens moet je nu bewust bewaken, zodat je de tijd neemt om de output van AI goed te controleren. Doe je dat niet, dan neem je het al snel klakkeloos aan, simpelweg omdat AI sneller code genereert dan jij kunt nakijken.
De lat gaat dus omhoog. Niet alles wat AI produceert haalt de codebase, sterker nog: een flink deel niet. Er wordt regelmatig geschrapt en herschreven om de codebase overzichtelijk en schoon te houden.
Waar het in de praktijk op neerkomt
Als je AI gebruikt om code te schrijven, moet je bereid zijn die code te onderhouden. Van A tot Z en ook nog over een aantal jaar. Ook als er een bug in zit of als er een uitbreiding nodig is.
Ben je daar niet toe bereid, dan is dat wat mij betreft het signaal dat je niet volledig begrijpt wat AI heeft gemaakt. En code die je niet begrijpt, wil je niet in productie hebben, ongeacht wie of wat hem heeft geschreven.
AI is voor mij een hulpmiddel. Een goed hulpmiddel, dat mijn werk beter maakt. Maar de verantwoordelijkheid voor wat er in de codebase belandt, en waarom, blijft precies waar hij altijd al lag: bij mij, de developer.