Ik heb tijdens de vakantie een open-source poker river solver geprogrammeerd. De code is voor 100% geschreven door Codex, en ik heb ook een versie gemaakt met Claude Code om te vergelijken. Over het algemeen stelden deze tools me in staat om veel sneller te itereren in een domein dat ik goed ken. Maar ik had ook het gevoel dat ik ze niet volledig kon vertrouwen. Ze maakten fouten en ondervonden bugs, maar in plaats van dit te erkennen, dachten ze vaak dat het geen groot probleem was of probeerden ze me soms gewoon te gaslighten door te denken dat er niets aan de hand was. Tijdens een memorabele debug-sessie met Claude Code vroeg ik, als sanity check, wat de verwachte waarde zou zijn van een "altijd fold" strategie wanneer de speler $100 in de pot heeft. Het vertelde me dat volgens zijn algoritme de EV -$93 was. Toen ik erop wees hoe vreemd dat was, in de hoop dat het zelf zou realiseren dat er een bug was, verzekerde het me dat $93 dicht bij $100 was, dus het was waarschijnlijk in orde. (Toen ik het specifiek vroeg om blockers als een potentieel probleem te overwegen, erkende het dat het algoritme ze inderdaad niet goed in aanmerking nam.) Codex was hier niet veel beter in en liep tegen zijn eigen set (interessant genoeg) verschillende bugs en algoritmische fouten aan die ik zorgvuldig moest doorwerken. Gelukkig kon ik hier doorheen werken omdat ik een expert ben op het gebied van poker solvers, maar ik denk niet dat er veel andere mensen zijn die erin geslaagd zouden zijn om deze solver te maken met behulp van AI-codingtools. De meest frustrerende ervaring was het maken van een GUI. Na een dozijn heen-en-weer gesprekken waren noch Codex noch Claude Code in staat om de frontend te maken die ik vroeg, hoewel die van Claude Code in ieder geval mooier was. Ik ben onervaren op het gebied van frontend, dus misschien was wat ik vroeg gewoon niet mogelijk, maar als dat het geval was, dan had ik gewild dat ze me hadden *verteld* dat het moeilijk of onmogelijk was in plaats van herhaaldelijk gebroken implementaties of dingen die ik niet vroeg te maken. Het benadrukte voor mij hoe er nog steeds een groot verschil is tussen werken met een menselijke teamgenoot en werken met een AI. Nadat de initiële implementaties waren voltooid en gedebugd, vroeg ik Codex en Claude Code om geoptimaliseerde C++ versies te maken. Op dit punt deed Codex verrassend goed. Zijn C++ versie was 6x sneller dan die van Claude Code (zelfs na meerdere iteraties van het vragen om verdere optimalisaties). De optimalisaties van Codex waren nog steeds niet zo goed als wat ik kon maken, maar aan de andere kant heb ik 6 jaar aan mijn PhD besteed aan het maken van pokerbots. Over het algemeen vond ik dat Codex een indrukwekkende prestatie had geleverd. Mijn laatste verzoek was om de AI's te vragen of ze nieuwe algoritmen konden bedenken die NLTH rivers nog sneller konden oplossen. Geen van beiden slaagde hierin, wat niet verrassend was. LLM's worden snel beter, maar het ontwikkelen van nieuwe algoritmen voor dit soort dingen is een maandenlang onderzoeksproject voor een menselijke expert. LLM's zijn daar nog niet op dat niveau.

Een belangrijke les die ARC-AGI heeft geïnternaliseerd, maar die niet veel anderen hebben, is dat benchmarkprestaties een functie zijn van de rekentijd tijdens de test. @OpenAI publiceert enkelvoudige benchmarkresultaten omdat het eenvoudiger is en mensen verwachten het te zien, maar idealiter zouden alle evaluaties een x-as moeten hebben.