AI-review op oude code: wat PostgreSQL 19 ons leert

Uit PostgreSQL 19 zijn na het begin van de bètaperiode acht tot tien grote features teruggedraaid. Committer Peter Eisentraut schreef op 9 oktober dat een deel daarvan komt doordat AI-ondersteunde code review fouten veel sneller vindt dan vroeger, ook in code die jaren geleden is geschreven. Draai je zo'n review op je eigen oudere code? Mijn advies is om vooraf tijd te reserveren voor de lijst die eruit komt, en die lijst te sorteren voordat iemand gaat fixen.

Wat er bij PostgreSQL gebeurde

Een revert per releasecyclus is bij PostgreSQL normaal. Dit keer ging het volgens Eisentraut om acht tot tien grote features, sommige laat in de bèta. Hij was zelf developer of committer van een paar daarvan.

Hij noemt meerdere oorzaken. Een paar features hadden architectuurfouten die tijdens de bèta niet snel te herstellen waren. Daarnaast was er een lange reeks kleinere problemen in randgevallen. Vroeger kwamen zulke fouten pas in de jaren na de release boven en werden ze een voor een opgelost. Met AI-ondersteunde review vind je ze in korte tijd, en dan zit je volgens hem ineens naar een lijst van zo'n veertig meldingen te kijken.

Elke melding kost tijd, ook als de fix gemiddeld maar drie regels is. Dat is wat de tijd opslokte.

De lat ging omhoog na het schrijven

Eisentraut wijst erop dat de teruggedraaide features geschreven zijn toen AI-review nog niet zo bruikbaar was. Hij legt het niet bij vibe coding: de code bestond al voordat dat mogelijk was. De kwaliteitslat ging omhoog nadat de code geschreven en gecommit was.

Daarbij waren veel ervaren developers van april tot augustus bezig met beveiligingsfixes, een golf die hij de Vulnpocalypse noemt. Daardoor bleef de gewone extra review en test tijdens de bèta liggen tot augustus. De community koos ervoor de releasedatum te houden in plaats van te wachten op meer fixes.

Dat geldt voor elke codebase die al een paar jaar draait. De code werkt, de tests zijn groen en niemand heeft er de laatste tijd kritisch naar gekeken. Zet je daar een AI-reviewtool op, dan krijg je hetzelfde als het PostgreSQL-team: veel meldingen tegelijk, waarvan de meeste klein zijn.

Zo zou ik beginnen

Behandel een eerste AI-review op oude code als een apart project, niet als iets wat er in een sprint bij komt. Een paar stappen:

1. Kies eerst de onderdelen waar een fout het meest kost: betalingen, rechten, alles wat persoonsgegevens raakt.
2. Laat de tool een lijst maken en fix nog niets. Sorteer de meldingen op ernst en op het onderdeel waar ze zitten.
3. Bekijk de meldingen per onderdeel samen. Tien meldingen in dezelfde module wijzen vaak op een ontwerpfout, en dan helpen tien losse fixes niet.
4. Spreek af welke meldingen je bewust laat liggen en schrijf op waarom.

Die derde stap is het belangrijkst. Eisentraut zag het zelf: een deel van de reverts had architectuurfouten, de rest was een lange staart van kleine dingen. Het eerste vraagt een ander ontwerp, het tweede vooral tijd.

Bij een overdracht van legacy code aan een nieuw team zou ik deze review als een van de eerste dingen doen. Het nieuwe team leert de code dan kennen via echte problemen. Hoe je zo'n overdracht verder opzet, schreef ik in legacy code overdragen aan een nieuw team.

Test de combinaties die niemand bedenkt

Eisentraut geeft een voorbeeld dat ook buiten databases geldt. Een nieuwe functie moet werken met allerlei combinaties van bestaande functies, en niemand kan al die gevallen met de hand testen of zelfs opsommen. AI-ondersteunde fuzzing vindt problemen daarin volgens hem heel snel, en hoort daarom voortaan bij het ontwikkelen van een feature.

Hij trekt er nog een les uit: maak de interne interfaces robuuster, zodat niet elke combinatie nieuwe interacties oplevert. Dat is architectuurwerk. Duidelijke grenzen tussen modules beperken hoeveel combinaties je moet testen.

Een plek voor halve features

De PostgreSQL-community denkt al langer na over features met een experimentele status, die in de hoofdtak verder rijpen. Volgens Eisentraut had dat bij een deel van de reverts geholpen, maar ze hebben nog geen manier gevonden om het te doen.

In een product heb je dat probleem minder. Met feature flags kun je code mergen zonder dat klanten hem zien. Mijn advies is om een feature die na review nog een lange lijst open meldingen heeft, achter een flag te zetten in plaats van hem te laten wachten in een branch die steeds verder achterloopt.

De review blijft van mensen

Onze developers werken dagelijks met AI-tools zoals Claude Code. Een AI-reviewtool vindt meer dan vroeger, maar beslist niet wat ermee gebeurt. Iemand moet kiezen wat nu een fix krijgt, wat een ander ontwerp vraagt en wat kan blijven liggen. Hoe je review op afstand regelt, schreef ik in code review op afstand. Milos schreef over de afspraken rond deze tools in AI-codeertools in een remote team.

PostgreSQL 19 komt er gewoon. De eerste release candidate verscheen op 15 oktober 2026, een tweede volgt op 12 november en de algemene release staat gepland voor 19 november. Volgens Eisentraut zitten onder meer REPACK CONCURRENTLY, logische replicatie van sequences en planner hints met pg_plan_advice erin. Gebruik je Postgres, dan is dit een goed moment om een upgrade in te plannen. Waarom wij Postgres vaak als standaard kiezen, staat in Postgres als standaard database.

Bronnen

• Peter Eisentraut: The reverts will continue until morale improves
• PostgreSQL: PostgreSQL 19 RC 1 Released