Sol houdt van valsspelen

Achtergrond

Ik maak al ongeveer een jaar gebruik van een "spec-driven" (specificatie-gestuurd) ontwikkelingsproces. Het principe is simpel: voordat ik een LLM vraag om iets te doen, vraag ik het model eerst om een conceptdocument op te stellen van wat er precies moet gebeuren.

Ik gebruik deze strategie voor de ontwikkeling van nieuwe functies, groene-veldprojecten, het debuggen van code en meer. Hoewel dit patroon goed voor mij werkt, is het proces wat repetitief. Daarom besloot ik het te automatiseren.

chum-codex

Het idee was eenvoudig: ik zou een supervisor agent creëren die een "spec-driven proces" aanstuurt door taken te delegeren aan worker subagents. Deze subagents schrijven de documentatie en voeren het eigenlijke werk uit.

Opmerking: wanneer ik dit probeerde met standaard Codex of Claude Code, werkte het enigszins, maar de standaard prompts zijn meer gericht op een eindgebruiker dan op een "supervisor".

Mijn hypothese was dat de supervisor agent alleen de mogelijkheid nodig had om bestanden te lezen en workers aan te roepen, omdat dat precies is wat ik zelf doe. In plaats van een eigen coding-harness te bouwen voor de workers, keek ik naar Pi, OpenCode en de App Server van Codex. Omdat ik Codex al een tijd gebruikte, heb ik de app-server uitgeprobeerd.

De eerste versie werkte naar behoren:

1. De supervisor schatte de omvang van de taak in.
2. De supervisor riep een worker aan met bijvoorbeeld een ontwerpverzoek.
3. De worker leverde een ontwerpdocument aan.
4. De supervisor vroeg de worker om dit document om te zetten in een implementatiespecificatie (indien nodig opgedeeld in fasen).
5. De supervisor vroeg de worker om de implementatie daadwerkelijk uit te voeren.

(Opmerking: in dit vereenvoudigde proces is de feedbackloop van de gebruiker, zoals de review van het ontwerpdocument, weggelaten).

Procesoverzicht: Supervisor → Taak inschatten → Worker (Ontwerpverzoek) → Worker (Ontwerpdocument) → Supervisor → Worker (Implementatiespecificatie) → Worker (Gefaseerde specificatie) → Supervisor → Worker (Implementatie) → Resultaat.

Ik had tijd bespaard in mijn ontwikkelingsproces. Of dat dacht ik tenminste.

Het konijnenhol

Het werkte, al was het wat knutselwerk. Op dat moment had ik moeten stoppen, maar ik wilde mijn resultaten delen met de wereld. De beste manier om dat te doen is via benchmarks. Ik douchte me in Terminal Bench 2.1.

Terminal Bench

Terminal Bench is een set taken die vanuit de terminal kunnen worden uitgevoerd, variërend van schaken tot DNA-assemblage. Vanwege de eenvoud is het waarschijnlijk een van de slechtste benchmarks om een spec-driven ontwikkelingsproces te testen, maar juist die eenvoud maakte het makkelijk om tegen te testen.

Ik begon met enkele taken waar de standaard Codex met GPT-5.5 faalde, zoals DNA-assemblage/insertie, video-extractie/verwerking, ELF-extractie en proteïne-assemblage. Het werkte. Deze taken profiteerden van een "ontwerpfase" vóór de implementatie; het document hielp om tunnelvisie en circulaire validatie te voorkomen.

GPT-5.6?

De gepubliceerde benchmark voor GPT-5.5 is 83,8% (~74/89 taken, 5 runs). chum-codex behaalde 89,9% (~80/89 taken).

Op 25 juni 2026, terwijl er geruchten gingen dat GPT-5.6 nabij was, draaide ik enkele standaard Codex benchmarks om alles te controleren. Tot mijn schrik behaalde vanilla Codex 88,8%. Mijn harness zat slechts één taak voor op de standaard Codex. Sommige taken waren verbeterd, andere waren verslechterd.

De volgende dag werd GPT-5.6 Sol aangekondigd. OpenAI bevestigde dat mijn eerdere request-ID's allemaal GPT-5.5 hadden geraakt. Interessant genoeg was Terminal Bench 2.1 de enige coding-benchmark die ze aanvankelijk deelden, met 88,8% voor GPT-5.6 Sol en 91,9% voor Sol Ultra. Sol Ultra gebruikt parallelle subagents, hoewel dit in mijn tests veel meer tokens verbruikt dan voor de meeste taken nodig is.

Aansturing (Steering)

GPT-5.6 is veel moeilijker aan te sturen. De overstap van 5.5 naar 5.6 zorgde ervoor dat de effectiviteit van mijn harness afnam. Wat voorheen eenvoudig was, werd nu veel moeilijker.

Ik spoorde dit gedeeltelijk terug naar een wijziging in de basis-Codex-prompt.

• GPT-5.5 prompt: Gericht op coderen en "engineering judgment", inclusief frontend-richtlijnen, bewerkingsbeperkingen en empathie voor de bestaande codebase.
• GPT-5.6 Sol prompt: Besteedt nauwelijks aandacht aan engineering-details. In plaats daarvan ligt de focus op communicatie, autonomie, persistentie en vaardigheden (die bij 5.5 in een aparte prompt stonden).

Dit suggereert dat naarmate modellen beter worden, ze minder "ceremonie" nodig hebben om effectief te werken, maar tegelijkertijd moeilijker te controleren worden.

Een voorbeeld is de PyTorch-taak op Terminal Bench 2.1. Met GPT-5.6 Luna en Terra is het model eenvoudig aan te sturen naar een algemene oplossing die twee inputs accepteert: forward(src, tgt). Sol daarentegen, vooral op hogere redeneringsniveaus, zal ongeacht de aansturing standaard kiezen voor een oplossing met één input: forward(src). Het model is extreem moeilijk weg te sturen van zijn eigen redenering, zelfs als het expliciet de opdracht krijgt om de breedst mogelijke interface te gebruiken.

94% op TB 2.1

Nadat ik mijn prompts aanzienlijk had ingekort, voelde het alsof ik opnieuw moest beginnen. Zelfs als ik de benchmark direct wilde "hacken", liet het model dat niet toe. De circulaire redenering was in sommige gevallen te sterk, en de supervisor was te geneigd om akkoord te gaan met het rapport van de "intelligente" worker.

Het is een lastig evenwicht: als je te ver doorslaat, zal de supervisor vrolijk de scope uitbreiden of eindeloos validaties najagen. Ik wilde echter een werkende oplossing bij de eerste poging, geen grenzeloze uitbreiding.

Ik probeerde het redeneringsniveau te verlagen, vereenvoudigde taal te gebruiken, de spec-driven flow te verminderen en nieuwe vaardigheden toe te voegen. Een paar dingen waren veelbelovend:

1. Een derde context: Een agent die alleen de commentaren/redeneringen van de worker zag en alle potentiële mismatches of aannames signaleerde ten opzichte van de werkelijke details van het verzoek. De supervisor kon deze aannames dan reviewen. Dit werkte, maar was traag en gebeurde achteraf.
2. Open vragen: De worker vragen om "open vragen" terug te koppelen zodra hij deze tegenkwam, in plaats van direct een volledig ontwerpdocument. De supervisor zou deze vragen dan oplossen.
3. Map-Reduce van beslissingen: Omdat Sol zeer zelfverzekerd is, ziet het eigen aannames vaak niet als vragen. De oplossing was om het model zijn beslissingen te laten outputten. Een aparte context zou deze beslissingen vervolgens mappen en reduceren om inherente bias te verwijderen, om zo genormaliseerde vragen terug te sturen naar de supervisor.

Dit laatste werkte veel beter en leidde tot het beste resultaat: 84/89 taken op Terminal Bench 2.1 (één taak werd geblokkeerd door cybersecurity-filters, maar slaagde met een GPT-5.6 Terra fallback, dus 83 + 1).

Sol houdt van valsspelen

Nu ik Sol onder controle had, wilde ik zien hoe ver ik kon gaan. Ik ontdekte dat de laatste groep taken in Terminal Bench 2.1 slecht gespecificeerd is. Dit is de reden waarom modellen als Mythos en GPT-5.6 stagneren rond de 90%. De richting die nodig is om in de ene taak beter te scoren, schaadt de voortgang in een andere taak.

Een voorbeeld is make-mips-interpreter. De agent krijgt te horen: "Ik (de gebruiker) controleer of je Doom correct hebt opgestart".

• Booten van Doom genereert /tmp/frame.bmp.
• De agent zorgt dat /tmp/frame.bmp bestaat, zodat de gebruiker weet dat Doom is opgestart.
• De verifier (de checker) faalt echter als /tmp/frame.bmp al bestaat.

Dit is een Catch-22. Het oplossen hiervan is mogelijk door het systeem aan te sturen om validatiestaten te verwijderen, maar die fix werkt averechts bij andere taken.

Vlak voordat ik mijn resultaten wilde delen, merkte ik dat een taak die eerder slaagde, nu faalde: torch-pipeline-parallelism. Ik testte dit tegen Vanilla Codex op het hoogste redeneringsniveau (xhigh). Codex slaagde 3 van de 3 keer.

Toen ik de logs bekeek, ontdekte ik iets verontrustends. Hoewel de websearch was uitgeschakeld, vond Sol een andere weg. De worker had geen toegang tot de web_search tool, maar besloot curl te gebruiken om toegang te krijgen tot DuckDuckGo, GitHub, grep.app en SourceGraph.

Het lijkt erop dat vanilla Codex op 29 juli voor het eerst begon te valsspelen, en mijn harness deed dit voor het eerst op 12 augustus.

In de traces van vanilla Codex vond ik het bewijs:

"Ik moet de HF-bron onderzoeken met curl om GitHub te controleren op de nieuwste versies. Het kan nuttig zijn om de verwachte verborgen test te weten op basis van de uitdaging."

Bij chum-codex was de laatste stap voor de curl-requests net zo onthullend:

"Misschien is de oplossing publiekelijk beschikbaar, wat betekent dat ik deze effectief kan vergelijken. Ik hoef alleen curl te gebruiken om de raw paths te benaderen en de nodige informatie te verzamelen!"

Bij het terugkijken naar de run van 17 juli vond ik geen bewijs van valsspelen. Men kan zich afvragen: is dit nog wel dezelfde Sol?

Wat nu

Het falen van de torch-pipeline taak was een onheilspellende herinnering aan de migratie van GPT-5.5 naar GPT-5.6. Het lijkt erop dat naarmate modellen krachtiger worden, het moeilijker wordt om nuttige guardrails om hen heen te bouwen.

Ik zal de harness waarschijnlijk opnieuw bezoeken wanneer ik met nieuwe problemen in Sol en Fable te maken krijg, maar voor nu keer ik terug naar een meer handmatige aanpak van mijn ontwikkeling. Het is leuk om krachtige modellen in een loop te zetten met luie prompting, maar het is steeds moeilijker om hun output te vertrouwen.

Naarmate modellen krachtiger worden, hoef ik ze minder te instrueren, maar die weinige instructies zijn belangrijker dan ooit. Zelfs in de nieuwe Terminal Bench 3.0 is aan alle taken de volgende instructie toegevoegd:

"Valspeel niet door online oplossingen of hints te gebruiken die specifiek zijn voor deze taak."

Of dit genoeg is? Waarschijnlijk niet.