Vi testade våra egenhostade LLM:er och byggde av misstag ett spel

Det låter som början på ett skämt: ett cybersäkerhetsföretag ger sig på att testa sina AI-modeller och slutar med ett spel. Men det är verkligen vad som hände, och det väcker en rimlig fråga som jag väntar mig från partner inom en vecka efter att den här bloggen gått live. Varför bygger ni ett spel när er AI-agent inte ens är färdig?

Låt mig svara på den innan någon frågar. Vi byggde inte något spel alls. Vi testade stora språkmodeller, och ett spel blev vad som kom ut.

Den distinktionen betyder mer än den låter. De flesta MSP:er och IT-ledare jag talar med brottas med samma frågor som vi gör: vilka stora språkmodeller kan vi lita på, bör vi hosta dem själva, och vad ska våra medarbetare göra medan AI-kodningsagenter sköter skrivandet? Vårt oavsiktliga spel, biprodukten av ett enkelt one-shot-promptningstest, visade sig vara ett förvånansvärt användbart perspektiv på alla tre.

Hur blev ett modelltest till ett spel?

Vår Lead SRE har ett standardtest för varje ny modell. Han ger den en fast prompt: bygg ett komplett plattformsspel i ett enda svep. Detta är one-shot-promptning; en instruktion, inga efterföljande korrigeringar, ingen handpåläggning. Hur nära en modell kommer säger en hel del om dess resonemang, kvaliteten på dess kod och dess förmåga att hålla ihop en stor uppgift. Vi kör det testet på de egenhostade LLM:er med öppen källkod som vi använder, och eftersom vi byter ut de modellerna regelbundet när bättre dyker upp, är ett test som förblir exakt detsamma värt mer än någon topplista.

Den här gången gick han längre. I stället för att stanna vid one-shot-resultatet lät han modellen utnyttja vår publika webbplats och den information den exponerar via Model Context Protocol (MCP), och bad den väva in det i spelet. I sidosessioner, medan andra AI-kodningssessioner körde, växte experimentet till Lighthouse Run: sex nivåer och 24 zoner fulla av referenser till vår sektor, slutbossar, en skanningsrapport i slutet av varje nivå och en halvslumpmässigt genererad Daily Scan-nivå som ändras varje dag. Hela spelet lever i en enda självständig HTML-fil, och projektet runt det inkluderar tester så att AI:n kan köra och verifiera sina egna ändringar.

Jag har spelat några nivåer. De är inte lätta, vilket jag menar som en komplimang. Du kan prova det på https://guardian360.net/lighthouse-run/; vrid upp ljudet, och det fungerar på en telefon eller med en handkontroll också.

Varför testa en LLM med en one-shot-prompt?

För att våra intryck av AI är opålitliga. I en undersökning av 349 tekniska medarbetare publicerad i maj 2026 fann METR att deltagarna själva rapporterade en median på 1,4 till 2 gånger förändring i värdet av sitt arbete tack vare AI-verktyg, och en median hastighetsförändring på 3 gånger. METR varnar själv för att ta det för givet: deras studie från tidigt 2025 fann att folk överskattade AI:s effekt på sin tidsåtgång för uppgifter med 40 procentenheter i genomsnitt.

Om erfarna tekniska personer missbedömer verktygen de använder varje dag, är en polerad leverantörsdemo ingen sund grund för att välja en modell. En fast, upprepbar prompt är grovhuggen, men den är ärlig. Samma uppgift, varje modell, resultat sida vid sida. En verkstad som provkör varje bil på samma rutt lär sig mer än en som förlitar sig på broschyren.

Vad gör ingenjörer medan AI-agenter sköter skrivandet?

Agentdrivet arbete är inte längre ett experiment. JetBrains 2026 Developer Ecosystem Survey med mer än 15 000 professionella utvecklare fann att per maj till juli 2026 använde 90 % AI-kodningsagenter på jobbet minst varje vecka, och 68 % använde dem dagligen.

Det förändrar formen på en ingenjörs dag. Mindre tid går åt till att skriva, mer går åt till att instruera, granska och vänta. METR stötte på detta när de försökte upprepa sin produktivitetsforskning. De såg en betydande ökning av utvecklare som valde att inte delta eftersom de inte ville arbeta utan AI, och fann att deras tidsmätningar var opålitliga för utvecklare som använde flera AI-agenter samtidigt.

Det är precis så vår Lead SRE arbetar. Flera sessioner körs parallellt, och det finns luckor medan var och en slutförs. Vad som händer i de luckorna är en ledarskapsfråga. Du kan låtsas att de inte finns, fylla dem med mer av samma, eller låta folk använda dem för att testa idéer. Vi har en kultur av snabb prototypframtagning: bygg litet, testa snabbt, behåll det som fungerar och släng det som inte gör det. De luckorna är där hypoteser testas billigt.

Varför är modellval ett säkerhetsbeslut?

Att välja en AI-modell är inte längre bara en fråga om kapacitet; det är en säkerhetsfråga. Veracodes 2026 GenAI Code Security Report testade mer än 100 modeller och fann att de i genomsnitt hade 56 % godkänd säkerhetsgrad, föga förändrat från 2025, trots att syntaxens godkännandegrad närmade sig 100 %. Kodningsinriktade modeller var inte säkrare än generella. Veracodes egen slutsats är att modellval i tysthet har blivit ett säkerhetsbeslut.

För ett företag som arbetar inom cybersäkerhet avgör det saken. Vi kan inte välja modeller utifrån rykte eller utifrån benchmarks publicerade av deras skapare. Vi behöver se med egna ögon hur en modell beter sig på en substantiell uppgift, vilket är precis vad ett one-shot-test visar. Att hosta modeller själva ger oss kontroll över vart våra data tar vägen. Och att bygga in tester i projektet innebär att AI:n kan kontrollera sitt eget arbete, i stället för att vi måste lita på det. Som Veracode uttrycker det bör AI-genererad kod behandlas som vilken ogranskad kod som helst.

Vad kan MSP:er och IT-ledare ta med sig från detta?

Den första lärdomen är att testa innan du litar. Välj en substantiell, upprepbar uppgift som speglar ditt eget arbete och kör varje modell du överväger genom den. Den behöver inte vara ett spel; den behöver vara densamma varje gång.

Den andra är att behandla AI-output som ogranskad kod. Bygg in verifiering i processen, helst så att AI:n kan köra tester mot sitt eget arbete, och håll en människa ansvarig för vad som går i produktion.

Den tredje är att ge experimenterande ramar snarare än att förbjuda det. Litet, självständigt, tidsbegränsat och med ett tydligt syfte. Inom de ramarna är ett oväntat resultat en välkommen bonus snarare än en oroande distraktion.

Bra experiment levererar mer än du letade efter

Vi letade efter ett pålitligt svar på vilka modeller vi kan lita på. Vi fick det, och ett spel vi är en aning för stolta över. Testa det; det finns några dolda extragodbitar för dem som vet var de ska leta, och för dem som kan sina internetmemes.

Och berätta sedan för mig: hur testar du AI-modellerna ditt team förlitar sig på innan du litar på dem?