Hoe ik Codex gebruik om 15 projecten te reviewen zonder de handmatige controle op te geven

Een paar jaar geleden zou het idee om 15 softwareprojecten tegelijk serieus te reviewen voor mij onrealistisch hebben geklonken. Ik bedoel niet 15 repositories openen en even kijken. Ik bedoel echte projecten herhaaldelijk controleren op bugs, verkeerde aannames, SEO-problemen, vertaalfouten, inconsistenties in lokalisatie, ontbrekende tests, regressies en oude code die niet meer bij de rest van het systeem past.

De beperkende factor was nooit typesnelheid. Het was aandacht. Elk project heeft zijn eigen geschiedenis, conventies, edge cases en code die verkeerd lijkt maar bewust zo bestaat. Een zorgvuldige review vereist lezen, zoeken, vergelijken, checks draaien en pas daarna beslissen wat echt moet veranderen.

Codex heeft voor mij de kosten van dat repetitieve werk veranderd. Het kan een eerste ronde door een repository doen, references volgen, gerelateerde bestanden inspecteren, verdachte patronen naar boven halen, tests voorstellen en helpen gebieden te onderzoeken die ik anders één voor één handmatig zou openen. Dat maakt de uiteindelijke beslissing niet automatisch. Het maakt het dure werk vóór die beslissing veel sneller.

De belangrijkste regel die ik heb geleerd is eenvoudig: ik gebruik Codex niet om mezelf uit de review-loop te halen. Ik gebruik het om mijn review-loop groter te maken.

De echte bottleneck is herhaling, niet code schrijven

Bij één project kun je verrassend veel context onthouden. Met veel projecten schaalt dat niet. Dezelfde soorten werk komen steeds terug:

• vergelijkbare bugs zoeken in verschillende componenten;
• controleren of een refactor oude call sites heeft achtergelaten;
• tests reviewen na gedragswijzigingen;
• inconsistenties vinden in metadata, taallogica, headings of interne links;
• localization keys en vertaalde content vergelijken;
• ontbrekende error handling en edge cases zoeken;
• controleren of een “kleine” wijziging meer bestanden raakte dan verwacht;
• diffs lezen die afzonderlijk simpel zijn maar gezamenlijk veel tijd kosten.

Niets hiervan is spectaculair. Alles is belangrijk. En wanneer dezelfde review over meerdere codebases moet worden herhaald, wordt de prijs enorm.

Hier is een AI coding agent voor mij het nuttigst. Hij kan het repetitieve deel van de zoekruimte verwerken, zodat ik meer aandacht overhoud voor oordeel.

Ik begin met inspectie, niet met toestemming om alles te herschrijven

Een makkelijke manier om slechte resultaten te krijgen is een enorme opdracht als “review het hele project en fix alles”. Dat klinkt efficiënt, maar combineert discovery, prioritering, architectuur, implementatie en validatie in één ongecontroleerde taak.

Ik krijg betere resultaten wanneer ik de fasen scheid.

inspect → explain findings → prioritize → change → validate → review diff

Eerst wil ik dat de agent het relevante gebied begrijpt en uitlegt wat hij heeft gevonden. Ik wil concrete bestandspaden, betrokken code, waarom iets verdacht lijkt en wat de mogelijke impact is. Pas daarna wil ik wijzigingen.

Dat is belangrijk omdat AI met veel zelfvertrouwen fout kan zitten. Code kan redundant lijken maar bestaan voor een oude browser, een payment edge case, een migratiepad of een business rule die niet uit één bestand blijkt. Inspectie geeft me de kans om een verkeerde aanname te stoppen voordat die een enorme diff wordt.

Ik behandel bevindingen als aanwijzingen, niet als oordelen

Een goede Codex-review eindigt niet met “ik vond 17 problemen”. Het getal zelf betekent bijna niets. Ik wil bewijs.

Voor een bruikbare bevinding wil ik weten:

• waar het probleem zit;
• waarom het een probleem is;
• welk gedrag kan falen;
• hoeveel vertrouwen de conclusie verdient;
• welke check de conclusie kan bevestigen of ontkrachten;
• wat de kleinste veilige fix is.

Dit is vooral belangrijk voor security, SEO en business logic. Een agent kan iets aanwijzen dat onderzoek verdient, maar een security-achtige uitleg is nog geen bewezen kwetsbaarheid. Een SEO-waarschuwing is niet automatisch een rankingprobleem. Een vreemde conditie is niet automatisch dead code.

AI verlaagt de kosten om kandidaten te vinden. Verificatie beslist nog steeds wat echt is.

De validation loop maakt het workflow betrouwbaar

Codegeneratie is het zichtbare deel van AI-assisted development, maar validatie maakt het bruikbaar in productie.

Na een wijziging wil ik dat de codebase antwoordt. Afhankelijk van het project kan dat bestaan uit:

• TypeScript of een andere compiler/type checker;
• lint;
• unit- en integratietests;
• build checks;
• gerichte searches naar oude namen of call sites;
• handmatige review van de uiteindelijke diff;
• handmatige verificatie van gebruikersgedrag.

De exacte commands zijn minder belangrijk dan de loop. De agent maakt een aanname, het repository geeft bewijs terug en de volgende beslissing gebruikt dat bewijs.

Daarom vind ik sterk getypeerde projecten prettig voor AI-assisted work. Ik schreef apart waarom TypeScript zo goed werkt met Codex in echte softwareontwikkeling: types zetten veel verkeerde aannames meteen om in machineleesbare feedback.

Sommige reviewcategorieën passen bijzonder goed bij AI

Bugs en regressies

Een agent kan een waarde door bestanden volgen, callers inspecteren, vergelijkbare implementaties vergelijken en branches vinden die niet overeenkomen. Dat helpt om de bron van een symptoom te beperken. Ik verifieer het gedrag nog steeds voordat ik de conclusie accepteer.

Tests

AI is nuttig om gedrag te vinden dat veranderde zonder overeenkomstige testcoverage, edge cases voor te stellen en uit te leggen wat een bestaande test werkelijk beschermt. Het kan ook tests zichtbaar maken die implementatiedetails testen in plaats van echt gedrag.

SEO

Technische SEO bevat veel consistentiewerk: metadata, taalalternates, indexability, interne links, templates, sitemap generation, redirects en pagina-conventies. Een agent kan die regels over een grote codebase sneller vergelijken dan ik elke route handmatig kan openen. Maar technische correctheid is iets anders dan de moeilijkere vraag of de content zelf verdient te ranken.

Lokalisatie en vertalingen

Dit is een van de meest repetitieve gebieden van een meertalig product. AI kan keys vergelijken, ontbrekende waarden vinden, taalvermenging detecteren, placeholders controleren en laten zien waar een locale structureel is afgeweken. Dat is veel sneller dan grote translation objects met de hand lezen, hoewel belangrijke copy menselijk oordeel nodig blijft hebben.

Consistentie na refactoring

Grote refactors mislukken vaak op saaie manieren: een oude import blijft staan, één route gebruikt nog de oude veldnaam, één test fixture heeft nog de oude shape. Repository-brede search gecombineerd met een agent die de bedoeling van de wijziging begrijpt is hier erg nuttig.

Parallel werken helpt alleen wanneer taken onafhankelijk zijn

Het is verleidelijk om veel agents te starten en alles tegelijk te laten veranderen. Dat kan throughput verhogen, maar ook conflicten en tegenstrijdige aannames vermenigvuldigen.

Ik zie parallelisme als een coördinatieprobleem. Onafhankelijke audits zijn goede kandidaten: één project kan op lokalisatie worden gecontroleerd terwijl een ander op tests wordt reviewed, of aparte repositories kunnen tegelijk worden onderzocht. Twee agents die zonder gezamenlijk plan dezelfde architectuur herschrijven zijn iets anders.

Hoe meer paralleliteit, hoe belangrijker grenzen worden: een duidelijk project, duidelijke taak, duidelijke definition of done en een resultaat dat apart reviewed kan worden.

Het doel is niet zoveel mogelijk agents actief hebben. Het doel is zoveel mogelijk nuttige, verifieerbare vooruitgang.

Wat ik niet blind delegeer

• Architectuurbeslissingen: het model kan opties voorstellen, maar langetermijntrade-offs hangen vaak af van context buiten de repository.
• Securityconclusies: bevindingen vragen verificatie, threat context en vaak specifieke tooling.
• Business rules: code kan intern consistent zijn en toch verkeerd productgedrag implementeren.
• Grote destructieve refactors: een enorme diff is moeilijker te begrijpen en makkelijker te snel goed te keuren.
• Production deployment: groene tests verwijderen operationeel risico niet.
• Final review: ik wil weten wat veranderde voordat ik mijn naam eraan verbind.

Niet omdat AI in deze gebieden nutteloos is, maar omdat een plausibel fout antwoord er bijzonder duur kan zijn.

AI-review vervangt statische analyse niet

Ik zie Codex ook niet als vervanging voor compilers, linters, tests, scanners of monitoring. Die tools hebben een voordeel dat AI niet heeft: ze zijn smal, deterministisch en herhaalbaar.

Het sterkste workflow combineert ze. Codex kan over context redeneren en voorstellen waar je moet kijken. Statische tools dwingen precieze regels af. Tests verifiëren gedrag. Logs en monitoring tonen de werkelijkheid. Menselijke review verbindt al die signalen met productintentie.

Zonder zulke feedback systems zou ik AI minder vertrouwen, niet meer.

De grootste productiviteitswinst is betere verdeling van aandacht

Het is makkelijk om te zeggen “Codex bespaart tijd”, maar dat beschrijft voor mij te weinig.

De schaarse resource in softwareontwikkeling zijn niet keystrokes. Het is hoogwaardige aandacht. Voor AI coding agents ging veel daarvan op aan repetitieve discovery: dezelfde patronen zoeken, vergelijkbare bestanden lezen, references volgen, controleren dat een wijziging overal doorgevoerd is en dezelfde audit in een andere repository herhalen.

Nu kan ik meer van die first pass delegeren en mijn aandacht bewaren voor moeilijk automatiseerbare beslissingen: is de finding belangrijk, past de fix bij de architectuur, verbetert de gebruikerservaring, is het risico acceptabel en wil ik dit werkelijk shippen?

Daarom voelt het onderhouden en reviewen van veel projecten nu anders. Ik review niet minder. In veel gevallen kan ik meer reviewen omdat het mechanische deel niet het hele budget opeet.

Het workflow dat ik vertrouw

1. Definieer een smal reviewdoel. Bugs, tests, SEO, lokalisatie, refactor of een andere concrete zorg.
2. Laat de agent inspecteren voor hij edit. Ik wil eerst bewijs en betrokken locaties.
3. Prioriteer findings. Niet elk theoretisch probleem verdient een codewijziging.
4. Houd wijzigingen begrensd. Kleine coherente diffs zijn makkelijker te valideren.
5. Draai machinechecks. Typecheck, lint, tests, build, search of projectspecifieke validatie.
6. Lees de diff handmatig. Ik zoek onnodige rewrites, verkeerde aannames, gemiste edge cases en wijzigingen buiten scope.
7. Verifieer belangrijk gedrag. Vooral gebruikers, geld, security, SEO en productie-infrastructuur.
8. Ga pas daarna naar het volgende project. Parallelisme helpt, maar onopgeloste onzekerheid mag niet verspreiden.

Vijftien projecten voelen niet meer als vijftien keer zoveel reviewwerk

Codex heeft 15 projecten niet simpel gemaakt en verantwoordelijkheid niet verwijderd. Het veranderde de relatie tussen schaal en repetitieve inspanning.

Ik kan diepere first passes, bredere consistentiechecks, meer testideeën en systematischere audits uitvoeren zonder elke minuut zelf door elk bestand te zoeken. Daarna kan ik de bespaarde aandacht gebruiken voor beslissingen die nog steeds een developer nodig hebben.

Dat is het soort AI-assisted development dat ik waardevol vind: geen autopilot, geen blind vertrouwen en geen “genereer code tot iets groen wordt”. Het is een strakkere loop tussen inspectie op machineschaal en oordeel op mensenschaal.

Voor mij is dat de echte leverage van Codex. Het elimineert review niet. Het maakt serieuze review mogelijk over een schaal die vroeger veel moeilijker te onderhouden was.