Probamos nuestros LLM autoalojados y acabamos construyendo un juego sin querer

Suena como el comienzo de un chiste: una empresa de ciberseguridad se propone probar sus modelos de IA y termina con un juego. Pero eso es justo lo que pasó, y plantea una pregunta razonable que espero de los partners dentro de la semana siguiente a la publicación de este blog. ¿Por qué estáis construyendo un juego cuando vuestro agente de IA todavía no está terminado?

Déjame responderla antes de que nadie la haga. No estábamos construyendo un juego en absoluto. Estábamos probando grandes modelos de lenguaje, y lo que salió fue un juego.

Esa distinción importa más de lo que parece. La mayoría de los MSP y responsables de IT con los que hablo se enfrentan a las mismas preguntas que nosotros: en qué grandes modelos de lenguaje podemos confiar, si deberíamos alojarlos nosotros mismos y qué deberían estar haciendo nuestras personas mientras los agentes de programación con IA teclean. Nuestro juego accidental, el subproducto de una simple prueba de prompting one-shot, resultó ser una lente sorprendentemente útil sobre los tres.

¿Cómo se convirtió una prueba de modelo en un juego?

Nuestro Lead SRE tiene una prueba estándar para cada modelo nuevo. Le da un prompt fijo: construye un juego de plataformas completo de una sola vez. Esto es prompting one-shot; una sola instrucción, sin correcciones de seguimiento, sin llevarlo de la mano. Lo cerca que llegue un modelo te dice mucho sobre su razonamiento, la calidad de su código y su capacidad de mantener una tarea grande como un todo coherente. Ejecutamos esa prueba en los LLM de código abierto autoalojados que usamos, y como reemplazamos esos modelos con regularidad a medida que aparecen otros mejores, una prueba que se mantiene exactamente igual vale más que cualquier ranking.

Esta vez fue más allá. En lugar de detenerse en el resultado one-shot, dejó que el modelo se nutriera de nuestro sitio web público y de la información que este expone a través del Model Context Protocol (MCP), y le pidió que lo tejiera dentro del juego. En sesiones paralelas, mientras otras sesiones de programación con IA estaban en marcha, el experimento creció hasta convertirse en Lighthouse Run: seis niveles y 24 zonas llenas de referencias a nuestro sector, jefes finales, un informe de escaneo al final de cada nivel y un nivel Daily Scan generado de forma semialeatoria que cambia cada día. Todo el juego vive en un único archivo HTML autocontenido, y el proyecto que lo rodea incluye pruebas para que la IA pueda ejecutar y verificar sus propios cambios.

He jugado unos cuantos niveles. No son fáciles, lo cual digo como un cumplido. Puedes probarlo en https://guardian360.net/lighthouse-run/; sube el sonido, y también funciona en un móvil o con un mando.

¿Por qué probar un LLM con un prompt one-shot?

Porque nuestras impresiones sobre la IA no son fiables. En una encuesta a 349 trabajadores técnicos publicada en mayo de 2026, METR encontró que los participantes autoinformaron una variación mediana de 1,4 a 2 veces en el valor de su trabajo debido a las herramientas de IA, y una variación mediana de velocidad de 3 veces. El propio METR advierte contra tomar eso al pie de la letra: su estudio de principios de 2025 encontró que las personas sobrestimaban el efecto de la IA en el tiempo dedicado a sus tareas en 40 puntos porcentuales de media.

Si personas técnicas con experiencia juzgan mal las herramientas que usan cada día, una demo pulida de un proveedor no es una base sólida para elegir un modelo. Un prompt fijo y repetible es tosco, pero es honesto. La misma tarea, cada modelo, resultados uno al lado del otro. Un taller que prueba cada coche en la misma ruta aprende más que uno que se fía del folleto.

¿Qué hacen los ingenieros mientras los agentes de IA teclean?

El trabajo impulsado por agentes ya no es un experimento. La Developer Ecosystem Survey 2026 de JetBrains, a más de 15.000 desarrolladores profesionales, encontró que, a fecha de mayo a julio de 2026, el 90 % usaba agentes de programación con IA en el trabajo al menos semanalmente, y el 68 % los usaba a diario.

Eso cambia la forma del día de un ingeniero. Se dedica menos tiempo a teclear y más a instruir, revisar y esperar. METR se topó con esto cuando intentó repetir su investigación de productividad. Vio un aumento significativo de desarrolladores que optaban por no participar porque no querían trabajar sin IA, y constató que sus mediciones de tiempo no eran fiables para desarrolladores que usaban varios agentes de IA de forma concurrente.

Así es exactamente como trabaja nuestro Lead SRE. Varias sesiones corren en paralelo, y hay huecos mientras cada una termina. Lo que ocurre en esos huecos es una cuestión de liderazgo. Puedes fingir que no existen, llenarlos con más de lo mismo, o dejar que la gente los use para probar ideas. Tenemos una cultura de prototipado rápido: construir pequeño, probar rápido, quedarse con lo que funciona y descartar lo que no. Esos huecos son donde las hipótesis se prueban de forma barata.

¿Por qué la elección del modelo es una decisión de seguridad?

Elegir un modelo de IA ya no es solo una cuestión de capacidad; es una cuestión de seguridad. El GenAI Code Security Report 2026 de Veracode probó más de 100 modelos y encontró que promediaban una tasa de aprobado de seguridad del 56 %, apenas cambiada respecto a 2025, incluso cuando las tasas de aprobado de sintaxis se acercaban al 100 %. Los modelos enfocados en programación no eran más seguros que los de propósito general. La propia conclusión de Veracode es que la selección del modelo se ha convertido silenciosamente en una decisión de seguridad.

Para una empresa que trabaja en ciberseguridad, eso lo zanja. No podemos elegir modelos por su reputación ni por los benchmarks que publican sus creadores. Necesitamos ver por nosotros mismos cómo se comporta un modelo en una tarea sustancial, que es precisamente lo que muestra una prueba one-shot. Alojar los modelos nosotros mismos nos da control sobre a dónde van nuestros datos. Y construir pruebas dentro del proyecto significa que la IA puede comprobar su propio trabajo, en vez de que nosotros tengamos que confiar en ella. Como dice Veracode, el código generado por IA debería tratarse como cualquier código sin revisar.

¿Qué pueden sacar de esto los MSP y los responsables de IT?

La primera lección es probar antes de confiar. Elige una tarea sustancial y repetible que refleje tu propio trabajo y pasa por ella cada modelo que consideres. No hace falta que sea un juego; hace falta que sea la misma cada vez.

La segunda es tratar la salida de la IA como código sin revisar. Construye verificación en el proceso, idealmente de forma que la IA pueda ejecutar pruebas contra su propio trabajo, y mantén a una persona responsable de lo que entra en producción.

La tercera es dar a la experimentación unos límites en lugar de prohibirla. Pequeña, autocontenida, acotada en el tiempo y con un propósito claro. Dentro de esos límites, un resultado inesperado es un extra bienvenido en vez de una distracción preocupante.

Los buenos experimentos entregan más de lo que buscabas

Buscábamos una respuesta fiable sobre en qué modelos podemos confiar. La obtuvimos, y además un juego del que estamos un poco demasiado orgullosos. Pruébalo; hay unos cuantos extras ocultos para quienes saben dónde mirar, y para quienes conocen sus memes de internet.

Y luego dime: ¿cómo pruebas los modelos de IA de los que depende tu equipo antes de confiar en ellos?