Code reviewen is een van die dingen die iedereen belangrijk vindt en waar in de praktijk als eerste op wordt bezuinigd zodra het druk is. Een tweede paar ogen op je werk vangt fouten die je zelf niet ziet, want je bent verblind door je eigen aannames. Maar een collega vragen om alles na te kijken kost tijd, en die tijd is er niet altijd. Ik heb daarom Ai ingezet als dat tweede paar ogen, en wel op twee verschillende momenten in het proces. De twee lagen versterken elkaar: de ene helpt me terwijl ik bouw, de andere vangt op wat ik toch vergeet.

Laag één: een review-commando dat zelf zijn specialisten kiest#

De eerste laag gebruik ik tijdens het bouwen zelf. Eén commando start een volledige review van waar ik mee bezig ben. Het slimme zit hem erin dat het niet blind dezelfde controle draait, maar kijkt wat mijn code raakt en op basis daarvan de juiste specialismen erbij haalt.

Raak ik iets aan dat met inloggen of toegang te maken heeft, dan schakelt het een beveiligingsspecialisatie in, met extra aandacht als er gegevens van buiten binnenkomen. Zit er een wijziging aan de database in, dan komt er een specialist bij die naar de datakant kijkt. Verander ik iets aan de gebruikerskant, dan let het op prestaties en gebruikservaring. Het is alsof je één knop indrukt en er precies het juiste panel van experts komt opdraven voor wat jij op dat moment aan het doen bent. De uitkomst is een lijst met bevindingen, en elke bevinding komt met drie dingen: hoe ernstig het is, waar het precies zit, en hoe je het oplost. Geen vage “dit kan beter”, maar concreet en direct bruikbaar.

Een bewuste keuze daarbij: deze review haalt nooit dure, creatieve capaciteiten erbij zoals het genereren van beelden of ontwerpen. Een controle hoort geen ontwerpkosten te maken. Het is een nakijkbeurt, geen productie. Die zuinigheid houdt de review goedkoop genoeg om hem echt elke keer te draaien, en dat is precies het punt: een controle die te duur voelt, sla je over.

Laag twee: een vangnet op elke voorgestelde wijziging#

De eerste laag werkt alleen als ik eraan denk hem te draaien. En daar zit de zwakke plek: op een drukke dag vergeet je dat. Daarom is er een tweede laag die niet van mijn discipline afhangt.

Elke voorgestelde wijziging, elke keer dat iemand code klaarzet om samen te voegen, wordt binnen een kwartier automatisch gereviewd. Dezelfde grondige analyse als bij het commando, maar nu volledig vanzelf. De bevindingen verschijnen als commentaar bij de wijziging, en als er iets ernstigs tussen zit, krijgt de wijziging een waarschuwingslabel dat aangeeft dat er nog wat moet gebeuren. Dat overzicht komt samen op één plek, zodat ik in één blik zie wat er klaarstaat en wat er nog aandacht nodig heeft.

Deze tweede laag is het vangnet onder het vangnet. Als ik de review tijdens het bouwen vergeet, pikt de automatische ronde het alsnog op. Het is de systematische verzekering tegen mijn eigen menselijke slordigheid. En omdat het altijd draait, ontstaat er ook een consistente standaard: alles wordt op dezelfde manier tegen het licht gehouden, ongeacht wie het gemaakt heeft of hoe druk het die dag was.

De realiteit: hard tegenhouden kost geld#

Nu de eerlijke kanttekening, want zonder die kanttekening zou dit verhaal te mooi zijn. Ik wilde eigenlijk dat een wijziging met een ernstige bevinding technisch geblokkeerd zou worden: je kunt het simpelweg niet samenvoegen tot het is opgelost. Dat is de sterkste vorm van een controle, want dan is hij niet te negeren.

Dat bleek niet gratis te krijgen. Zo’n harde blokkade zit bij de gangbare platforms achter een betaald abonnement. Op het gratis plan kun je wel alles zien, de bevindingen, de labels, de rode vlaggen, maar je kunt het samenvoegen niet technisch tegenhouden. De gate is daarmee “zacht”: je ziet dat er iets mis is, maar of je er iets mee doet, blijft een keuze. Dat is een echte beperking, en ik noem hem bewust, want in dit soort automatiseringsverhalen wordt de laatste stap, het echt afdwingen, vaak weggemoffeld. Voor wie dit serieus wil inzetten: reken erop dat het waterdicht dichttimmeren van zo’n controle een betaalde stap kan vereisen. Tot dan leun je op discipline, ondersteund door zichtbaarheid.

Wat telkens de belangrijkste fout bleek#

Het meest leerzame kwam niet uit de techniek maar uit wat de reviews in de praktijk vonden. De fout die telkens weer bovenkwam als de meest ernstige, was geen tikfout of een lelijk stuk code. Het was een tekort in de scheiding tussen klanten.

In software die meerdere klanten bedient, is het essentieel dat de gegevens van de ene klant onmogelijk bij de andere terecht kunnen komen. Die afscheiding moet ijzersterk en systematisch zijn, ingebouwd op een niveau waar je er niet per ongeluk omheen kunt werken. En juist daar zat keer op keer het risico: een stuk code dat de scheiding niet goed afdwong, waardoor in theorie de ene klant bij de gegevens van de andere had kunnen komen. Dat is zo’n beetje het ergste wat er kan gebeuren, veel erger dan een applicatie die crasht, want het raakt vertrouwen en privacy direct.

Dat dit de terugkerende topbevinding was, zegt iets belangrijks: de gevaarlijkste fouten zijn zelden de zichtbare. Een applicatie die niet opstart, merk je meteen. Een lek in de scheiding tussen klanten werkt gewoon, tot het misgaat. Precies daarom is een controle die daar systematisch naar zoekt zo waardevol, want het is exact het soort fout dat je met het blote oog mist.

Wat betekent dit voor jouw bedrijf?#

Ook als je zelf geen software bouwt, zit er een bruikbare les in de manier waarop deze controle is opgezet.

  1. Zet controle op twee momenten neer. Eén die helpt terwijl het werk gebeurt, en één die als vangnet vanzelf draait. De tweede vangt op wat de eerste, door menselijke slordigheid, mist.
  2. Maak controle goedkoop genoeg om altijd te draaien. Een controle die te duur of te omslachtig voelt, sla je over precies wanneer je ‘m het hardst nodig hebt. Houd hem licht.
  3. Wees eerlijk over waar de automatisering stopt. Zichtbaar maken is niet hetzelfde als afdwingen. Weet waar je systeem alleen waarschuwt en waar het echt tegenhoudt, en durf te erkennen dat het sluitende deel soms een betaalde of menselijke stap vereist.
  4. Richt de scherpste controle op wat onzichtbaar kapot kan. De gevaarlijkste fouten zijn die welke gewoon blijven werken tot het te laat is. Laat je controle daar het hardst naar zoeken.

Dit sluit aan bij een thema dat vaker terugkomt in mijn werk: de gevaarlijkste bugs zijn niet de bugs die je ziet. Daar schreef ik eerder over in mijn stuk over de gevaarlijkste bug-klasse van Ai-software.

Wil je verkennen hoe je in jouw bedrijf een tweede paar ogen op je processen kunt zetten, geautomatiseerd waar het kan en menselijk waar het moet? Kijk dan op de consulting-pagina hoe ik werk. En op mijn downloads-pagina vind je gratis werkbladen om die afwegingen concreet te maken.