Claude test 35 keer tot ik er ziek van word

Vanochtend zat ik naar mijn revenue-data te kijken. Zesentachtig NULLs op dertienduizendzevenhonderdvijftig records. Een halve procent. Niet veel, maar genoeg om te denken: welke bedrijven hebben volgens mij geen omzet?

Eerste check liet rare namen zien. ExxonMobil. Kroger. Ecolab. Universal Music Group. Allemaal multinationals met evident substantiële omzet.

Eerste reactie van mij: bug. Er zit iets fout in mijn ingest. Ik ga code lopen herzien.

Maar voor ik dat deed, deed Claude wat Claude altijd doet.

Claude geeft een SQL query voor ik kan nadenken

"Erik, voordat we de code reviewen, even checken of die NULLs random verdeeld zijn of in een patroon zitten. Plak deze query in Supabase."

SELECT EXTRACT(YEAR FROM fiscal_date) as jaar,
       EXTRACT(QUARTER FROM fiscal_date) as kwartaal,
       COUNT(*) as null_count
FROM fundamentals
WHERE revenue IS NULL
GROUP BY 1, 2
ORDER BY null_count DESC;

Ik kopieer. Ik plak. Ik run. Ik krijg een tabel terug. Eén regel springt eruit: 45 NULLs in Q4 2019. De rest van de NULLs verdeeld over vele kwartalen, één of twee per stuk.

Stuur ik door naar Claude. Antwoord komt direct: "Dit is geen bug. Dit is de COVID-corruptie van begin 2020. Veel financial data providers hebben Q4 2019 cijfers nooit goed verwerkt door de chaos in maart. Welke 45 tickers precies?"

Volgende query. Plak, run, output terug.

"Een mix van sectoren. Klassiek random pattern. Bevestigt mijn vermoeden. Voor jouw use case maakt het niet uit: Value gebruikt recente quarters, Quality gebruikt 5-year averages, eventuele 2019-backtest forward-filled. Geen aanpassing nodig."

Drie minuten. Klaar.

Hoe ik vroeger zou hebben gewerkt

Vroeger, en met "vroeger" bedoel ik vóór dit project, zou ik bij die zesentachtig NULLs een paar dingen kunnen doen. Negeren. Of er een dag induiken om uit te zoeken wat er aan de hand is. Of, en dit is wat de meeste mensen doen, ik zou wat handmatig kijken naar drie tickers, het OK genoeg vinden, en doorgaan.

In geen van die scenarios zou ik binnen drie minuten zeker weten dat het geen bug was, dat het een specifiek historisch patroon was, en dat het mijn systeem niet raakt.

Want mijn hoofd werkt niet zo snel.

Het verschil zit niet in de tools

Iedereen denkt: AI is slim, dus dingen gaan sneller. Klopt. Maar het echte verschil zit niet in de snelheid van het denken. Het zit in de discipline van het checken.

Claude heeft een SQL klaar voor ik kan nadenken. Niet omdat Claude slimmer is dan ik. Maar omdat Claude geen moeite heeft om het te schrijven. Geen koffie nodig, geen "even mijn gedachten verzamelen", geen ergernis dat hij twintig minuten daarvoor ook al een SQL moest tikken.

En dat is precies de discipline die ik zelf niet had. In mijn vorige werkende leven heb ik dingen gebouwd zonder dit niveau van inspectie. Iets werkte. Klaar. Volgende. Het feit dat je elke aanname kon testen in plaats van vertrouwen, daar deed je gewoon niet aan. Niet omdat dat slim was, maar omdat het zoveel werk was dat niemand het deed.

Nu is het geen werk meer. Het kost drie minuten.

Tests 35 keer tot je er ziek van wordt

Mijn werkwijze met Claude is letterlijk vastgelegd in instructie-bestanden in mijn project. Eén van de regels: bij elke twijfel, eerst een check schrijven. Eerst een test. Eerst data laten zien.

En Claude houdt zich daaraan. Soms te goed.

Soms wil ik gewoon door. "Het werkt nu, ga verder." En dan zegt Claude: "Voordat we verder gaan, even checken of de input nu wel een ints array is en niet een floats array. Plak deze 5-regel test in." En dan zit ik daar te zuchten. Ja Claude, ik weet het, ints. Beetje. Misschien.

Drie keer per dag word ik er een beetje ziek van.

Maar elke keer, elke keer, vindt dat ene test of die ene check iets dat ik over het hoofd had gezien. Een rare null. Een type mismatch. Een edge case bij Nederlandse aandelen die anders is dan bij Amerikaanse. Iets wat in een ander leven een week debugging op een vrijdag had geweest.

Wat dit anders maakt dan vroeger ontwikkelen

Toen ik nog Kadenza had, een data-consultancy, zag ik genoeg trajecten waar dingen in productie gingen die niemand had getest. Het werkte. Op één machine. Voor één klant. Op één moment. En dan ging het mis bij de eerstvolgende edge case en stond er een rapport in een mail met de subject line "URGENT".

Met AI verandert dat niet automatisch. Een AI kan ook gewoon code uitspugen die ongetest in productie eindigt. Het verschil zit in hoe je de AI instrueert. In de regels die je vastlegt. In de discipline die je afdwingt.

Claude test razendsnel. Ik analyseer langzaam. Samen halen we een tempo waar geen senior developer aan tippen kan in haar eentje. Niet omdat ik zo slim ben. Omdat het tempo van checken is veranderd. En dat verandert wat je je kunt veroorloven te testen.

Dat is het echte verhaal van werken met AI. Niet de slimme antwoorden. De obsessieve checks.