SWE-Game pressar kodagenter – ingen når 60 av 100 i spelbygge

Den 7 oktober 2026 lades en reviderad version av SWE-Game på arXiv ut: i 247 uppgifter från 41 körbara referensspel leder Opus5 alla fem uppgiftstyper, men ingen av de sex testade modell- och agentkonfigurationerna når 60 av 100 i någon av de tre uppgifterna där spel byggs eller färdigställs. Poängen är en samlad bedömning av spelprojekten, inte andelen spel som blev godkända.

SWE-Game prövar spel som agenterna ska få att fungera enligt givna krav, inte bara projekt som går att starta. Referensspelen är gjorda i Godot, och uppgifterna omfattar även felrättning och flytt till Unity. Därmed prövas både hur agenten omsätter en beställning i spelmekanik och hur den bevarar beteenden när ett befintligt projekt ändras.

Fem uppgifter med olika startpunkt

I Brief-to-Game får agenten en kort beställning, tillgångar och en video av referensspelet. Den ska själv skriva ett speldesigndokument och därefter bygga spelet. GDD-to-Game börjar med ett färdigt designdokument, medan Skeleton Completion ger agenten ett påbörjat projekt där saknade delar måste fungera ihop med befintliga scener och skript.

De övriga uppgifterna gäller Bug Repair och Godot-to-Unity Porting. Vid reparation startar spelet men beter sig fel; agenten får en beskrivning av symtomen och ska återställa det trasiga utan att förstöra fungerande beteenden. Vid portering ska resultatet vara ett byggbart Unity-projekt som behåller originalets kontroller, spelmekanik och progression.

Skillnaden mellan uppgifterna är viktig för tolkningen av poängen. En kort beställning lämnar fler designbeslut åt agenten än ett färdigt dokument, medan ett påbörjat projekt kräver integration med redan skriven kod. Ett reparationsfall har ett snävare mål men ställer samtidigt krav på att resten av spelet fortsätter fungera. Samma agent kan därför vara stark i en del av arbetet och svagare i en annan.

Opus5 toppar varje uppgift, men byggpoängen släpar

I den fullständiga resultattabellen får Opus5 50,38 poäng i Brief-to-Game, 59,68 i GDD-to-Game och 54,06 i Skeleton Completion. För Bug Repair är totalpoängen 83,46 och för Godot-to-Unity Porting 72,40. Gränsen under 60 gäller alltså de tre bygguppgifterna; reparation och portering har andra resultat och delvis andra bedömningskriterier.

Bakom förstaplatsen skiftar ordningen. Grok4.6 är tvåa i Brief-to-Game, medan GPT-5.6 Luna är tvåa i de fyra övriga uppgifterna. Qwen3.8 Flash, GLM5.3 Flash och Minimax M3 ingår också i jämförelsen. Varje modell kördes med sitt eget agentramverk och sina egna verktyg, så rangordningen gäller de testade kombinationerna snarare än modellerna frikopplade från arbetsmiljön.

Det går heller inte att läsa en totalpoäng som en procentsats för hur många färdiga spel som blev godkända. Byggpoängen väger samman flera delar, däribland mekanik, innehåll, spelbarhet och visuell bedömning. För reparation spelar både återställda fel och bevarade funktioner roll; vid portering bedöms även byggbarhet, struktur och stabilitet. Totalpoängen visar hur konfigurationerna klarade respektive uppgiftstyp inom testets egna kriterier.

Spelet måste reagera rätt, inte bara se rätt ut

SWE-Game kopplar agenternas projekt till ett gemensamt gränssnitt som gör det möjligt att styra spelaren och läsa av tillstånd i spelet. En kontroll kan till exempel låta spelaren träffa ett hinder och undersöka om hälsan förändras eller om spelaren dör enligt kravet. Agenten anger hur dess spelobjekt kopplas till gränssnittet; själva kontrollerna och de förväntade resultaten ligger hos utvärderaren.

Utvärderaren spelar också upp inmatningssekvenser som fungerat i referensspelet och kontrollerar delmål på vägen. Agenten lämnar egna demonstrationer av funktioner, men ett utfall räknas bara om det beror på spelarens handlingar: samma mål ska inte nås i en jämförbar körning utan inmatning. Den ordningen fångar fel som vare sig kompilering eller en stillbild avslöjar: en bana kan synas och gå att starta trots att hinder, skada eller nivåavslut inte följer spelreglerna.

I en genomgång publicerad den 9 oktober redovisas att de körbara kontrollerna nådde 92,59 procents balanserad träffsäkerhet mot mänskligt märkta spelbeteenden från 100 agentbyggda spel, jämfört med cirka 78,41 procent för en videobaserad AI-domare. Balanserad träffsäkerhet väger ihop hur ofta fungerande beteenden godtas och hur ofta fel upptäcks. För spelets utseende används en separat visuell bedömning; en video kan visa presentationen även när den inte avgör om ett spelkrav faktiskt är uppfyllt.

Kraven som försvann ur spelen

I granskningen av levererade spel dominerar två typer av problem: utelämnade krav och felaktig spellogik. I det första fallet saknas något som beställningen kräver. I det andra finns funktionen på plats men reagerar fel när spelaren gör det som ska utlösa den. Integrationsfel mellan skript, scener och resurser förekommer också; då kan en rimlig koddel ändå sluta fungera när den möter resten av projektet.

Felbilden förklarar varför ett körbart spel kan få en låg samlad poäng. Att en figur rör sig eller att en nivå syns säger lite om alla efterfrågade interaktioner, tillgångar och delmål. I referensspelen finns beteenden att jämföra med, och testet kan särskilja en saknad funktion från en funktion som ger fel följd. Det gör resultatet mer konkret än en enda dom över om spelet verkar färdigt.

Resultaten avser en avgränsad samling Godot-spel och en agentkonfiguration per modell. Större projekt och längre utvecklingsförlopp ingår i begränsad omfattning, så placeringarna säger inte hur samma verktyg skulle prestera i all programvaruutveckling. För ett agentbyggt spel ligger den avgörande skillnaden mellan ett startbart projekt och uppfyllda spelkrav i spelarens handlingar och spelets faktiska reaktioner.

Läs också:

• Europas kreatörer pressar EU om AI – upphovsrätt och ersättning står i centrum