Vi testede vores selv-hostede LLM'er og byggede ved et uheld et spil

Det lyder som starten på en vittighed: en cybersikkerhedsvirksomhed sætter sig for at teste sine AI-modeller og ender med et spil. Men det er faktisk det, der skete, og det rejser et rimeligt spørgsmål, som jeg forventer fra partnere inden for en uge efter, at denne blog går live. Hvorfor bygger I et spil, når jeres AI-agent ikke engang er færdig?

Lad mig svare, før nogen spørger. Vi byggede slet ikke et spil. Vi testede store sprogmodeller, og et spil er, hvad der kom ud af det.

Den forskel betyder mere, end den lyder til. De fleste MSP’er og IT-ledere, jeg taler med, arbejder sig gennem de samme spørgsmål som os: hvilke store sprogmodeller kan vi stole på, bør vi hoste dem selv, og hvad bør vores folk lave, mens AI-kodningsagenter taster? Vores tilfældige spil, biproduktet af en simpel one-shot-promptingtest, viste sig at være et overraskende nyttigt perspektiv på alle tre.

Hvordan blev en modeltest til et spil?

Vores Lead SRE har en standardtest for hver ny model. Han giver den én fast prompt: byg et komplet platformsspil i ét hug. Det er one-shot prompting; én instruktion, ingen efterfølgende rettelser, ingen håndholdning. Hvor tæt en model kommer, fortæller meget om dens ræsonnement, kvaliteten af dens kode og dens evne til at holde sammen på en stor opgave. Vi kører den test på de selv-hostede open source-LLM’er, vi bruger, og fordi vi løbende udskifter de modeller, efterhånden som bedre dukker op, er en test, der forbliver præcis den samme, mere værd end nogen leaderboard.

Denne gang gik han videre. I stedet for at stoppe ved one-shot-resultatet lod han modellen trække på vores offentlige website og den information, den eksponerer gennem Model Context Protocol (MCP), og bad den om at væve det ind i spillet. I sidesessioner, mens andre AI-kodningssessioner kørte, voksede eksperimentet til Lighthouse Run: seks baner og 24 zoner fulde af referencer til vores sektor, endebosser, en scanningsrapport ved slutningen af hver bane og en semi-tilfældigt genereret Daily Scan-bane, der ændrer sig hver dag. Hele spillet lever i én selvstændig HTML-fil, og projektet omkring det inkluderer tests, så AI’en kan køre og verificere sine egne ændringer.

Jeg har spillet et par baner. De er ikke nemme, hvilket jeg mener som et kompliment. Du kan prøve det på https://guardian360.net/lighthouse-run/; skru op for lyden, og det virker også på en telefon eller med en controller.

Hvorfor teste en LLM med en one-shot-prompt?

Fordi vores indtryk af AI er upålidelige. I en undersøgelse af 349 tekniske medarbejdere, offentliggjort i maj 2026, fandt METR, at deltagerne selv rapporterede en median ændring på 1,4 til 2 gange i værdien af deres arbejde som følge af AI-værktøjer og en median hastighedsændring på 3 gange. METR advarer selv mod at tage det for pålydende: deres studie fra tidligt i 2025 fandt, at folk overvurderede AI’s effekt på deres tidsforbrug på opgaver med 40 procentpoint i gennemsnit.

Hvis erfarne tekniske folk fejlvurderer de værktøjer, de bruger hver dag, er en poleret leverandørdemo ikke et solidt grundlag for at vælge en model. En fast, gentagelig prompt er grov, men den er ærlig. Samme opgave, hver model, resultater side om side. Et værksted, der prøvekører hver bil på samme rute, lærer mere end et, der stoler på brochuren.

Hvad laver ingeniører, mens AI-agenter taster?

Agentdrevet arbejde er ikke længere et eksperiment. JetBrains’ 2026 Developer Ecosystem Survey af mere end 15.000 professionelle udviklere fandt, at pr. maj til juli 2026 brugte 90 % AI-kodningsagenter på arbejdet mindst ugentligt, og 68 % brugte dem dagligt.

Det ændrer formen på en ingeniørs dag. Mindre tid bruges på at taste, mere bruges på at instruere, gennemgå og vente. METR stødte ind i dette, da de forsøgte at gentage deres produktivitetsforskning. De så en betydelig stigning i udviklere, der valgte ikke at deltage, fordi de ikke ville arbejde uden AI, og fandt, at deres tidsmålinger var upålidelige for udviklere, der brugte flere AI-agenter samtidigt.

Det er præcis sådan, vores Lead SRE arbejder. Flere sessioner kører parallelt, og der er huller, mens hver enkelt bliver færdig. Hvad der sker i de huller, er et ledelsesspørgsmål. Du kan lade som om, de ikke findes, fylde dem med mere af det samme eller lade folk bruge dem til at teste idéer. Vi har en kultur med hurtig prototyping: byg småt, test hurtigt, behold det, der virker, og smid det væk, der ikke gør. De huller er, hvor hypoteser bliver testet billigt.

Hvorfor er valg af model en sikkerhedsbeslutning?

At vælge en AI-model er ikke længere blot et spørgsmål om kapacitet; det er et sikkerhedsspørgsmål. Veracodes 2026 GenAI Code Security Report testede mere end 100 modeller og fandt, at de i gennemsnit havde en sikkerhedsbeståelsesrate på 56 %, stort set uændret fra 2025, selv da syntaksbeståelsesrater nærmede sig 100 %. Kodningsfokuserede modeller var ikke sikrere end generelle. Veracodes egen konklusion er, at valg af model stille og roligt er blevet en sikkerhedsbeslutning.

For en virksomhed, der arbejder med cybersikkerhed, afgør det sagen. Vi kan ikke vælge modeller på omdømme eller på benchmarks offentliggjort af deres skabere. Vi er nødt til selv at se, hvordan en model opfører sig på en substantiel opgave, hvilket er præcis, hvad en one-shot-test viser. At hoste modeller selv giver os kontrol over, hvor vores data havner. Og at bygge tests ind i projektet betyder, at AI’en kan tjekke sit eget arbejde, i stedet for at vi skal stole på det. Som Veracode udtrykker det, bør AI-genereret kode behandles som enhver anden ikke-gennemgået kode.

Hvad kan MSP’er og IT-ledere tage med fra dette?

Den første lektie er at teste, før du stoler. Vælg én substantiel, gentagelig opgave, der afspejler dit eget arbejde, og kør hver model, du overvejer, gennem den. Den behøver ikke at være et spil; den skal bare være den samme hver gang.

Den anden er at behandle AI-output som ikke-gennemgået kode. Byg verifikation ind i processen, ideelt så AI’en kan køre tests mod sit eget arbejde, og hold et menneske ansvarligt for det, der går i produktion.

Den tredje er at give eksperimentering rammer frem for at forbyde det. Småt, selvstændigt, tidsafgrænset og med et klart formål. Inden for de rammer er et uventet resultat en kærkommen bonus snarere end en bekymrende afledning.

Gode eksperimenter leverer mere, end du ledte efter

Vi ledte efter et pålideligt svar på, hvilke modeller vi kan stole på. Det fik vi, og et spil, vi er en anelse for stolte af. Giv det et forsøg; der er et par skjulte ekstra ting for dem, der ved, hvor de skal kigge, og for dem, der kender deres internet-memes.

Og fortæl mig så: hvordan tester du de AI-modeller, dit team er afhængigt af, før du stoler på dem?