Jag vibecodeade en öppen källkod poker river solver under helglovet. Koden är 100% skriven av Codex, och jag gjorde också en version med Claude Code för att jämföra. Överlag gjorde dessa verktyg att jag kunde iterera mycket snabbare inom ett område jag känner väl. Men jag kände också att jag inte kunde lita helt på dem. De gjorde misstag och stötte på buggar, men istället för att erkänna det tyckte de ofta att det inte var någon stor grej eller, ibland, försökte de bara gaslighta mig att tro att inget var fel. I en minnesvärd felsökningssession med Claude Code frågade jag den, som en mental kontroll, vad det förväntade värdet av en "alltid fold"-strategi skulle vara när spelaren har 100 dollar i potten. Den berättade för mig att enligt dess algoritm kostade elbilen -93 dollar. När jag påpekade hur konstigt det var, i hopp om att den själv skulle inse att det finns en bugg, försäkrade den mig om att 93 dollar var nära 100 dollar så det var nog okej. (När jag väl bad den att specifikt överväga blockerare som ett potentiellt problem, erkände den att algoritmen faktiskt inte tog hänsyn till dem korrekt.) Codex var inte mycket bättre på detta, och stötte på sin egen uppsättning (intressant nog) distinkta buggar och algoritmiska misstag som jag var tvungen att noggrant arbeta mig igenom. Som tur var kunde jag ta mig igenom dessa eftersom jag är expert på pokerlösare, men jag tror inte att det finns många andra som hade kunnat göra denna lösare med AI-kodningsverktyg. Den mest frustrerande upplevelsen var att skapa ett grafiskt gränssnitt. Efter ett dussin fram och tillbaka kunde varken Codex eller Claude Code göra det frontend jag bad om, även om Claude Codes var åtminstone vackrare. Jag är oerfaren på frontend, så kanske var det jag bad om helt enkelt inte möjligt, men om så var fallet önskar jag att de hade *sagt* att det var svårt eller omöjligt istället för att upprepade gånger göra trasiga implementationer eller saker jag inte bad om. Det visade för mig hur stor skillnad det fortfarande är mellan att arbeta med en mänsklig lagkamrat och att arbeta med en AI. Efter att de initiala implementationerna var klara och felsökta bad jag Codex och Claude Code att skapa optimerade C++-versioner. På detta ställde sig Codex förvånansvärt bra. Dess C++-version var 6 gånger snabbare än Claude Codes (även efter flera iterationer av uppmaning för ytterligare optimeringar). Codex optimeringar var fortfarande inte lika bra som vad jag kunde göra, men å andra sidan tillbringade jag sex år av min doktorandutbildning med att göra pokerbottar. Överlag tyckte jag att Codex gjorde ett imponerande jobb med detta. Min sista begäran var att fråga AI:erna om de kunde komma på nya algoritmer som kunde lösa NLTH-floder ännu snabbare. Ingen av dem lyckades med detta, vilket inte var förvånande. LLM:er blir snabbt bättre, men att utveckla nya algoritmer för den här typen av saker är ett månadslångt forskningsprojekt för en mänsklig expert. LLM:er är inte på den nivån än.

En viktig lärdom som ARC-AGI har internaliserat, men inte många andra har, är att benchmark-prestanda är en funktion av testtidsberäkning. @OpenAI publicerar benchmarkresultat med ett enda tal eftersom det är enklare och folk förväntar sig att se det, men helst borde alla utvärderingar ha en x-axel.