Meinung
Wir haben unsere selbst gehosteten LLMs getestet und aus Versehen ein Spiel gebaut
Es klingt wie der Anfang eines Witzes: Ein Cybersecurity-Unternehmen macht sich daran, seine KI-Modelle zu testen, und steht am Ende mit einem Spiel da. Aber genau das ist passiert, und es wirft eine berechtigte Frage auf, die ich innerhalb einer Woche nach Erscheinen dieses Blogs von Partnern erwarte. Warum bauen Sie ein Spiel, wenn Ihr KI-Agent noch nicht fertig ist?
Lassen Sie mich die Frage beantworten, bevor sie jemand stellt. Wir haben überhaupt kein Spiel gebaut. Wir haben große Sprachmodelle getestet, und ein Spiel ist dabei herausgekommen.
Dieser Unterschied ist wichtiger, als er klingt. Die meisten MSPs und IT-Verantwortlichen, mit denen ich spreche, arbeiten sich durch dieselben Fragen wie wir: Welchen großen Sprachmodellen können wir vertrauen, sollten wir sie selbst hosten, und was sollten unsere Leute tun, während KI-Coding-Agenten tippen? Unser zufälliges Spiel, das Nebenprodukt eines einfachen One-Shot-Prompting-Tests, erwies sich als überraschend nützliche Linse für alle drei Fragen.
Wie wurde aus einem Modelltest ein Spiel?
Unser Lead SRE hat einen Standardtest für jedes neue Modell. Er gibt ihm einen festen Prompt: Baue in einem einzigen Durchlauf ein vollständiges Plattformspiel. Das ist One-Shot-Prompting; eine Anweisung, keine nachträglichen Korrekturen, kein Händchenhalten. Wie nah ein Modell herankommt, sagt sehr viel über sein logisches Denken, die Qualität seines Codes und seine Fähigkeit aus, eine große Aufgabe zusammenzuhalten. Wir führen diesen Test mit den selbst gehosteten Open-Source-LLMs durch, die wir verwenden, und weil wir diese Modelle regelmäßig austauschen, sobald bessere erscheinen, ist ein Test, der exakt gleich bleibt, mehr wert als jedes Ranking.
Diesmal ging er noch weiter. Anstatt beim One-Shot-Ergebnis aufzuhören, ließ er das Modell auf unsere öffentliche Website und die Informationen zurückgreifen, die sie über das Model Context Protocol (MCP) bereitstellt, und bat es, das in das Spiel einzuweben. In Nebensitzungen, während andere KI-Coding-Sitzungen liefen, wuchs das Experiment zu Lighthouse Run heran: sechs Level und 24 Zonen voller Anspielungen auf unsere Branche, Endgegner, ein Scan-Bericht am Ende jedes Levels und ein halbzufällig generiertes Daily-Scan-Level, das sich täglich ändert. Das gesamte Spiel steckt in einer einzigen, in sich geschlossenen HTML-Datei, und das Projekt drumherum enthält Tests, sodass die KI ihre eigenen Änderungen ausführen und überprüfen kann.
Ich habe ein paar Level gespielt. Sie sind nicht leicht, was ich als Kompliment meine. Sie können es unter https://guardian360.net/lighthouse-run/ ausprobieren; drehen Sie den Ton auf, und es funktioniert auch auf einem Smartphone oder mit einem Controller.
Warum ein LLM mit einem One-Shot-Prompt testen?
Weil unsere Eindrücke von KI unzuverlässig sind. In einer im Mai 2026 veröffentlichten Umfrage unter 349 technischen Fachkräften stellte METR fest, dass die Teilnehmer im Median eine 1,4- bis 2-mal so hohe Veränderung im Wert ihrer Arbeit durch KI-Werkzeuge angaben, und eine mediane Geschwindigkeitsveränderung von 3-mal. METR selbst warnt davor, das für bare Münze zu nehmen: Die eigene Studie von Anfang 2025 ergab, dass Menschen den Effekt von KI auf ihre Arbeitszeit für Aufgaben im Durchschnitt um 40 Prozentpunkte überschätzten.
Wenn erfahrene technische Fachleute die Werkzeuge falsch einschätzen, die sie täglich verwenden, ist eine geschliffene Anbieter-Demo keine solide Grundlage für die Wahl eines Modells. Ein fester, wiederholbarer Prompt ist grob, aber ehrlich. Dieselbe Aufgabe, jedes Modell, Ergebnisse nebeneinander. Eine Werkstatt, die jedes Auto auf derselben Strecke Probe fährt, lernt mehr als eine, die sich auf den Prospekt verlässt.
Was tun Ingenieure, während KI-Agenten tippen?
Agentengesteuerte Arbeit ist kein Experiment mehr. Der 2026 Developer Ecosystem Survey von JetBrains unter mehr als 15.000 professionellen Entwicklern ergab, dass im Zeitraum Mai bis Juli 2026 90 % mindestens wöchentlich KI-Coding-Agenten bei der Arbeit nutzten, und 68 % sie täglich nutzten.
Das verändert den Tagesablauf eines Ingenieurs. Weniger Zeit wird mit Tippen verbracht, mehr mit Anweisen, Überprüfen und Warten. METR stieß darauf, als es versuchte, seine Produktivitätsforschung zu wiederholen. Es verzeichnete einen deutlichen Anstieg an Entwicklern, die sich gegen eine Teilnahme entschieden, weil sie nicht ohne KI arbeiten wollten, und stellte fest, dass seine Zeitmessungen für Entwickler, die mehrere KI-Agenten gleichzeitig nutzten, unzuverlässig waren.
Genau so arbeitet unser Lead SRE. Mehrere Sitzungen laufen parallel, und es gibt Lücken, während jede einzelne fertig wird. Was in diesen Lücken passiert, ist eine Führungsfrage. Sie können so tun, als gäbe es sie nicht, sie mit mehr vom Gleichen füllen oder die Leute sie nutzen lassen, um Ideen zu testen. Wir haben eine Kultur des schnellen Prototypings: klein bauen, schnell testen, behalten, was funktioniert, und wegwerfen, was nicht funktioniert. In diesen Lücken werden Hypothesen günstig getestet.
Warum ist die Modellwahl eine Sicherheitsentscheidung?
Die Wahl eines KI-Modells ist nicht mehr nur eine Frage der Leistungsfähigkeit; sie ist eine Sicherheitsfrage. Der 2026 GenAI Code Security Report von Veracode testete mehr als 100 Modelle und stellte fest, dass sie im Durchschnitt eine Sicherheits-Bestehensquote von 56 % erreichten, kaum verändert gegenüber 2025, obwohl die Syntax-Bestehensquoten sich 100 % näherten. Auf Coding spezialisierte Modelle waren nicht sicherer als universelle. Veracodes eigenes Fazit lautet, dass die Modellauswahl stillschweigend zu einer Sicherheitsentscheidung geworden ist.
Für ein Unternehmen, das im Bereich Cybersecurity tätig ist, ist die Sache damit entschieden. Wir können Modelle nicht nach Ruf oder nach Benchmarks auswählen, die von ihren Herstellern veröffentlicht werden. Wir müssen selbst sehen, wie sich ein Modell bei einer umfangreichen Aufgabe verhält, und genau das zeigt ein One-Shot-Test. Dass wir Modelle selbst hosten, gibt uns die Kontrolle darüber, wohin unsere Daten gehen. Und Tests in das Projekt einzubauen bedeutet, dass die KI ihre eigene Arbeit überprüfen kann, statt dass wir ihr vertrauen müssen. Wie Veracode es ausdrückt, sollte KI-generierter Code wie jeder ungeprüfte Code behandelt werden.
Was können MSPs und IT-Verantwortliche daraus mitnehmen?
Die erste Lektion lautet: Testen Sie, bevor Sie vertrauen. Wählen Sie eine umfangreiche, wiederholbare Aufgabe, die Ihre eigene Arbeit widerspiegelt, und lassen Sie jedes Modell, das Sie in Betracht ziehen, durch sie laufen. Es muss kein Spiel sein; es muss jedes Mal dasselbe sein.
Die zweite lautet: Behandeln Sie KI-Ausgaben als ungeprüften Code. Bauen Sie Überprüfung in den Prozess ein, idealerweise so, dass die KI Tests gegen ihre eigene Arbeit ausführen kann, und halten Sie einen Menschen für das verantwortlich, was in die Produktion geht.
Die dritte lautet: Geben Sie dem Experimentieren Grenzen, statt es zu verbieten. Klein, in sich geschlossen, zeitlich begrenzt und mit einem klaren Zweck. Innerhalb dieser Grenzen ist ein unerwartetes Ergebnis ein willkommener Bonus statt einer beunruhigenden Ablenkung.
Gute Experimente liefern mehr, als Sie gesucht haben
Wir suchten eine verlässliche Antwort darauf, welchen Modellen wir vertrauen können. Die haben wir bekommen, und ein Spiel, auf das wir ein klein wenig zu stolz sind. Probieren Sie es aus; es gibt ein paar versteckte Extras für die, die wissen, wo sie suchen müssen, und für die, die ihre Internet-Memes kennen.
Und dann sagen Sie mir: Wie testen Sie die KI-Modelle, auf die sich Ihr Team verlässt, bevor Sie ihnen vertrauen?
Quellen
- JetBrains Research, AI Coding Agents: Adoption Trends (Developer Ecosystem Survey 2026)
- METR, Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity
- METR, We are Changing our Developer Productivity Experiment Design
- Veracode, LLMs Are Getting Smarter, But Not Safer: 2026 GenAI Code Security Report