AI agent evaluatie: meet niet de demo, meet productiegedrag

Een AI-agent die een demo-output maakt, heeft nog niet bewezen dat hij productiewerk aankan. FrontierCode van Cognition maakt dat verschil zichtbaar: de benchmark meet of code mergewaardig is, niet alleen of de tests groen worden. Voor automation en API-producten is dat de juiste lat.

Wie workflows, video-rendering of agenttaken in productie draait, moet naar regressies, scope, kosten, testbaarheid en overdracht kijken. Een agent die vandaag een JSON-payload omzet in video, maar morgen je webhook-contract breekt, is geen productiviteitswinst.

Wat Cognition aankondigde

Cognition introduceerde FrontierCode als benchmark voor coding agents. De claims zijn stevig: 150 taken, maintainers van 36 open-source repositories, meer dan 40 uur maintainerwerk per taak en een beoordelingslaag die kijkt naar mergebaarheid. De benchmark beloont dus niet alleen functionele correctheid, maar ook testkwaliteit, scope, stijl, codebase-standaarden en onderhoudbaarheid.

De Diamond-subset, de 50 zwaarste taken, blijft volgens Cognition vrijwel onopgelost. Claude Opus 4.8 via Claude Code scoort 13,4%. GPT-5.5 via Codex komt op 6,3%. Claude Opus 4.7 komt op 5,2%. Op Main en Extended liggen de scores hoger, maar ook daar blijft het beeld duidelijk: de beste agents kunnen veel, maar productiecode blijft lastig.

Voor SamAutomation is dit geen abstract benchmarknieuws. De site draait rond JSON-to-video, CapCut API alternatieven, caption automation, n8n workflows en production routes. De recente GSC-sprint focuste op `json-to-video`, `capcut api`, endpointbewijs, payloads, webhooks en pricingroutes. Juist in zo'n omgeving is demo-output te goedkoop geworden. Iedereen kan een voorbeeldpayload laten werken. De vraag is of het endpointcontract, de workflow en de foutafhandeling blijven staan.

Waarom demo-output misleidt

Een demo heeft weinig vijanden. De input is schoon, de context klopt, de API is beschikbaar en niemand vraagt wat er gebeurt bij een timeout. Productie heeft die luxe niet. Een video-render kan falen omdat een asset niet bereikbaar is. Een webhook kan dubbel aankomen. Een agent kan een payload aanpassen waardoor een klantintegratie breekt. Een caption pipeline kan slagen, maar de verkeerde language code opslaan.

Veel agent-evals lijken nog te veel op demo's. Ze vragen: heeft de agent de taak opgelost? Dat is nuttig voor een eerste vergelijking, maar onvoldoende voor een bedrijf dat agent output in een API of workflow giet. Je moet weten of de agent binnen scope blijft, of de kosten voorspelbaar blijven, of de output opnieuw te controleren is en of een developer de wijziging kan reviewen.

Terminal-Bench laat hetzelfde bredere patroon zien vanuit terminaltaken. De benchmark bestaat uit realistische taken in unieke terminalomgevingen met human-written solutions en tests. De paper rapporteert dat frontier agents onder 65% scoren. Dat zegt niet dat agents waardeloos zijn. Het zegt dat realistische omgevingen veel meer eisen dan tekstoutput.

FrontierCode verschuift de vraag

De nuttigste zin uit de FrontierCode-aankondiging is niet de leaderboardscore. De nuttigste vraag is: zou een maintainer deze PR mergen? Die vraag kun je vertalen naar automation:

• Zou een engineer deze workflow deployen zonder extra uitleg?
• Zou een klantintegratie blijven werken als de agentwijziging live gaat?
• Zou de output onder budget blijven bij 10.000 runs?
• Zou je de fout kunnen reproduceren als de agentroute vannacht faalt?
• Zou een collega de wijziging durven aanpassen zonder het hele systeem te herschrijven?

Dat is een betere evaluatie dan “de video is gegenereerd” of “de API call geeft 200”. In een JSON-to-video workflow is de rendering zelf maar één deel. Je hebt een stabiel schema nodig, duidelijke webhook events, foutstatussen, idempotency, retries, assetvalidatie en een manier om usage te meten. Een AI-agent die alleen de payload bouwt, mist vaak die contractlaag.

Wat de FrontierCode ranking wel en niet zegt

De Diamond-ranking zegt dat zelfs sterke model-harness combinaties moeite hebben met de hardste codekwaliteitstaken. Het is verleidelijk om daar meteen modelkeuzes uit te halen: Claude bovenaan, GPT-5.5 tweede, Gemini daarachter. Dat is te simpel. De rows combineren model en tooling. Claude Code, Codex, Gemini CLI, mini-swe-agent en Devin geven elk een andere werkomgeving.

Voor productie-automation is de harness vaak net zo belangrijk als het model. Een agent met goede shelltoegang, repo-instructies, tests en rollbackregels kan betrouwbaarder zijn dan een beter model zonder context. Omgekeerd kan een sterk model schade doen als het zonder budgetcaps of scope-instructies wordt losgelaten op een workflow.

Cognition meldt ook dat GPT-5.5 op sommige runs minder tokens gebruikt dan Claude Opus 4.8. Dat detail is relevant voor automation. Kosten zijn geen bijzaak wanneer een agent niet één keer draait, maar honderden keren per dag. Een eval die geen tokenbudget, runtime, retries of mislukte runs bekijkt, mist een groot deel van de businesscase.

Een betere eval voor automation teams

Als je AI-agents inzet in workflows, test dan in vijf lagen.

1. Contract

Leg vast welke input en output mogen bestaan. Voor een JSON to Video API betekent dat: verplichte velden, asset URLs, duration, captions, status events en webhook payloads. Laat de agent niet stilletjes nieuwe velden introduceren zonder versiebeleid.

2. Regressie

Test bestaande payloads opnieuw. Een agent die een nieuwe templatevariant toevoegt, mag oude templates niet breken. Dit klinkt saai, maar hier zit het verschil tussen demo en product.

3. Scope

Geef de agent expliciet toestemming voor een beperkt deel van de code of workflow. Als de taak over captions gaat, hoeft hij pricing, auth of routing niet aan te raken.

4. Kosten en duur

Meet tokens, API-kosten, renderduur en retries. Een agent die de taak oplost met vier keer zoveel calls kan in een benchmark acceptabel lijken en in productie te duur zijn.

5. Overdracht

Laat de agent een korte changelog, testbewijs en rollbackroute opleveren. Geen roman. Gewoon: wat is aangepast, hoe is het getest, welke risico's blijven open.

Wat we nog niet weten

FrontierCode houdt de taken prive. Dat helpt tegen contaminatie, maar maakt onafhankelijke reproductie lastig. Cognition gebruikt ook rubrics en LLM-gebaseerde kwaliteitschecks voor zachte criteria. Dat is logisch voor codekwaliteit, maar teams moeten beseffen dat zo'n beoordeling niet hetzelfde is als een pure unit-testscore.

De benchmark gaat over coding agents in repositories. Automation workflows hebben extra variabelen: externe API's, rate limits, credentials, no-code nodes, queuegedrag, billing en gebruikersfouten. Je kunt FrontierCode dus niet een-op-een op SamAutomation toepassen. Je kunt de beoordelingsfilosofie wel gebruiken.

Mijn oordeel

FrontierCode is nuttig omdat het de discussie verplaatst van “kan een agent iets maken?” naar “durf je dit te onderhouden?” Dat is precies de discussie die automation teams moeten voeren. Demo's zijn goedkoop. Productiegedrag is duur om achteraf te repareren.

Voor SamAutomation hoort elk agent- of workflowexperiment daarom langs dezelfde lijn: contract, regressie, scope, kosten en overdracht. Een agent die die vijf punten niet kan bewijzen, mag hooguit een concept maken. Geen live wijziging, geen klantworkflow, geen API-contract.

Lees daarnaast de bestaande gids over n8n workflow template requirements als je workflows inkoopt of laat genereren. Voor API-routes zijn de pagina's over JSON-to-Video en CapCut API alternatieven betere startpunten dan losse benchmarkclaims.

Bronnen

• Cognition: FrontierCode blog en methodiek
• Cognition: FrontierCode leaderboarddata
• SWE-bench: software engineering benchmark
• METR: maintainer review van SWE-bench-passing PRs
• Terminal-Bench: terminaltaken voor AI agents