Als onderdeel van mijn werk voor Studio Lemon draag ik bij aan open source WordPress-software. Ik ben maintainer van Timber, de template library die veel WordPress-sites gebruiken en wij ook binnen Studio Lemon gebruiken. Daarnaast lever ik een bijdrage aan onder andere ACF Builder. Dat werk speelt zich vaak buiten beeld af, maar veel projecten leunen erop. Juist daar merk ik hoe snel AI onderdeel is geworden van het dagelijks werk.
AI kan een foutmelding samenvatten, helpen zoeken in een grote codebase of een eerste opzet voor documentatie maken. Dat scheelt tijd. Tegelijkertijd is snelheid geen kwaliteitsmaatstaf. In open source moet iemand kunnen uitleggen waarom een wijziging nodig is, wat die kan raken en hoe we weten dat het goed blijft werken. Die verantwoordelijkheid kun je niet aan een prompt uitbesteden.
Meer securityreports, meer werk
Als maintainer zie ik steeds meer beveiligingsmeldingen binnenkomen. Soms gaat het om een verouderde dependency, soms om een risico diep in een pakket waar een project indirect van afhankelijk is. Zo’n melding klinkt vaak alarmerend, maar vertelt nog niet automatisch wat je moet doen.
AI is hierbij een bruikbare eerste lezer. Het kan een securityreport vertalen naar gewone taal, uitzoeken hoe een kwetsbaar pakket in een project terechtkomt of verschillen tussen versies op een rij zetten. Vervolgens begint het werk dat niet te automatiseren is. Komt deze kwetsbaarheid in deze situatie werkelijk voor? Welke update is verstandig? En wat gebeurt er met bestaande websites als we die doorvoeren?
De opkomst van AI-slop pull requests
Bij Timber zie ik ook de andere kant. Er verschijnen vaker pull requests die er op het eerste gezicht verzorgd uitzien, maar waar weinig begrip achter zit. De beschrijving is lang, er zijn veel bestanden aangepast en de uitleg klinkt aannemelijk. Bij nader inzien lost de wijziging geen echt probleem op, of verandert zij meer dan nodig is.
Dat kost tijd in de review. Niet alleen omdat we de code moeten lezen, maar vooral omdat we moeten achterhalen wat de auteur bedoelde en of die de gevolgen overziet. Een door AI voorgestelde wijziging kan tests laten slagen en toch onbedoelde gevolgen hebben. Bijvoorbeeld wanneer een bestaande functie zich subtiel anders gedraagt, of wanneer documentatie een uitzondering weglaat die voor gebruikers juist belangrijk is.
Een goede bijdrage hoeft niet groot of perfect te zijn. Wel moet de indiener het probleem begrijpen, vragen kunnen beantwoorden en bereid zijn om verbeteringen door te voeren.
Hoe ik AI zelf inzet
Ik gebruik AI ook, onder meer voor mijn bijdrage aan pull request #202 in StoutLogic ACF Builder. ACF Builder gebruiken we in ieder Studio Lemon-project om ACF-velden gestructureerd te definiëren. De pull request legt de basis voor betere, automatisch gegenereerde documentatie van de library.
Daar zat veel herhaalwerk in: publieke functies nalopen, uitleg aanvullen, voorbeelden controleren en kijken welke instellingen ACF daadwerkelijk ondersteunt. AI kan helpen om dat werk op gang te brengen en patronen consistent te maken. Maar het bepaalt niet wat de publieke API wordt, en ook niet welke wijziging acceptabel is voor bestaande gebruikers.
Daarom is de bijdrage niet alleen tekst. De code is gecontroleerd met geautomatiseerde tests, codekwaliteitstools en een gegenereerde documentatiereferentie. De 168 tests met 235 controles bleven groen.
Zo wil ik AI inzetten: als een snelle, soms verrassend goede assistent die voorwerk doet en dient als sparringpartner. De richting, review en verantwoordelijkheid blijven bij mensen. Daar wordt open source uiteindelijk beter van.