Imagina una “arena” donde dos modelos de inteligencia artificial se enfrentan, generan código o diseños al mismo tiempo y un juez automático determina quién hizo el mejor trabajo. Esa es la idea central de esta aplicación: ejecutar modelos en paralelo, medir tiempo y tokens, mostrar resultados en pantalla dividida y que Gemini actúe como juez para evaluar objetivamente las entregas. El objetivo: tener un flujo práctico y reproducible para crear comparativas entre modelos, probar prompts y automatizar la evaluación de resultados.
Tabla de contenidos
- ⚙️ Qué es y por qué construir una arena de modelos
- 🧭 Arquitectura general: cómo está montada la app
- 🧩 Herramientas que utilicé (y enlaces útiles)
- 🧠 Diseño del prompt: el ingrediente que lo hace funcionar
- 🔁 Modos de operación: manual vs autónomo
- 🛠️ Integración con Open Router: cómo obtener y usar la API Key
- 🧪 Ejecución de batallas y debugging en tiempo real
- 📁 Versionado y deploy: GitHub + Hostinger
- 🚧 Problemas comunes y soluciones rápidas
- 💡 Buenas prácticas para comparar modelos
- 🔎 Un ejemplo práctico: tres rondas de prueba
- 🧭 Consejos rápidos para replicar este proyecto
- 📚 Recursos y links (útiles para comenzar)
- 🚀 Conclusión y próximos pasos
⚙️ Qué es y por qué construir una arena de modelos
Una arena de modelos no es solo espectáculo. Es una herramienta de experimentación con valor práctico:
- Comparación directa: ver en paralelo cómo diferentes modelos interpretan el mismo prompt.
- Evaluación automática: usar a Gemini para puntuar y comparar resultados sin depender únicamente de la revisión humana.
- Iteración rápida: ajustar prompts, filtrar modelos y volver a ejecutar en segundos.
- Deploy y uso real: publicar la aplicación para que otros prueben sus propios prompts y modelos.
Este enfoque es útil para equipos de producto, desarrolladores de prompts, investigadores y cualquier persona interesada en medir la calidad real de generación en tareas concretas (landing pages, dashboards, componentes UI, tablas de precios, etc.).
🧭 Arquitectura general: cómo está montada la app
La aplicación sigue una arquitectura sencilla pero poderosa:
- Interfaz creada en Google AI Studio usando vibe coding (la herramienta genera una app React/Bit basada en el prompt).
- Integración con Open Router para acceder a múltiples modelos desde un solo endpoint y una sola API key.
- Gemini como evaluador: lo usamos para comparar resultados y, en modo autónomo, decidir el ganador.
- Deploy automático desde GitHub a Hostinger Cloud para publicación y pruebas externas.
En la práctica esto significa que la app funciona como un motor: recibe un prompt, envía la misma instrucción a dos modelos (o más), muestra las respuestas en columnas simultáneas, mide métricas (tiempo, tokens, coste estimado) y permite evaluar manual o automáticamente.
🧩 Herramientas que utilicé (y enlaces útiles)
Estas son las piezas clave y dónde encontrarlas:
- Google AI Studio (para generar la app con vibe coding): https://aistudio.google.com
- Open Router (para acceder a múltiples modelos y obtener una API Key unificada): https://openrouter.ai
- Hostinger Cloud (para deploy desde GitHub): https://hostinger.com/rodrigo
- Prompt completo (compartido en Google Docs): https://docs.google.com/document/d/1Zfu8Q-Z5UPRxPO1jVB4WqN31R5cYl71d_m3f682wpjU/edit?usp=sharing
- Playlist con más proyectos y ejemplos: https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
Nota: Open Router permite probar modelos de distintos proveedores con la misma interfaz. Esto facilita la comparación sin crear cuentas separadas para cada proveedor.
🧠 Diseño del prompt: el ingrediente que lo hace funcionar
Un prompt limpio, estructurado y exhaustivo acelera la creación de la app. En este caso el prompt cumple varias funciones:
- Define el rol del asistente (generador de UI y gestor de la arena).
- Indica cómo debe interactuar con Open Router (endpoint, formato de requests, uso de API key).
- Detalla modos de operación: versus (manual), autónomo (IA decide) y review.
- Especifica la interfaz: lista de modelos filtrable, ejecución simultánea, medición de tiempo, tokens y coste, render inmediato del resultado.
- Pide capacidad para buscar y añadir logos automáticamente desde fuentes libres como Wikipedia.
El resultado: Google AI Studio genera una app con pantallas para elegir modelos, definir misiones (prompts tipo «componente básico», «landing page», «dashboard») y ejecutar batallas entre modelos. Cuando el prompt está bien hecho, la primera versión de la app funciona desde el primer intento.
“Un prompt bien hecho hace que generes una herramienta a la primera.”
🔁 Modos de operación: manual vs autónomo
La app tiene dos modos principales:
- Versus manual: el usuario inicia la batalla y decide cuándo y cómo revisar los resultados. Ideal para revisiones humanas o para ajustar parámetros en vivo.
- Autónomo: la app lanza las ejecuciones y Gemini actúa como juez automático. Gemini evalúa criterios definidos (claridad, cumplimiento del prompt, organización del contenido, calidad del código) y declara un ganador.
En el modo versus surgieron problemas de UX que se solucionaron con prompts adicionales durante la creación. Por ejemplo, inicialmente la app no mostraba el resultado de un modelo hasta que el otro terminaba. Se añadió una regla para que cada columna muestre el resultado parcial (frame renderizado, tiempo, tokens) tan pronto como el modelo termine, incluso si el otro sigue procesando.
🛠️ Integración con Open Router: cómo obtener y usar la API Key
El flujo básico para usar Open Router fue este:
- Crear cuenta en Open Router: https://openrouter.ai
- Ir al menú de usuario y generar una API Key en la sección «Keys».
- Copiar la API Key y pegarla en la aplicación (donde se solicita la OpenRouter API Key).
- Filtrar modelos por precio o por etiquetas (por ejemplo, free) para evitar costos altos durante pruebas.
Open Router ofrece acceso a modelos gratuitos y de pago. Para pruebas rápidas conviene filtrar por «free». Esto permite probar modelos como «Nova 2 Lite» de Amazon o «Kimi K2» sin incurrir en gastos significativos.
🧪 Ejecución de batallas y debugging en tiempo real
La experiencia práctica mostró varios puntos valiosos:
- Al ejecutar dos modelos simultáneamente, es importante que la UI muestre resultados tan pronto como estén disponibles. Los iframes que contenían el código generado a veces ocultaban barras de desplazamiento por el encabezado simulado. La solución fue refactorizar el componente de vista previa para usar Flexbox y scroll independiente por columna.
- Algunos modelos generan código inválido o incompleto. Implementar manejo de errores (retries automáticos, mensajes claros en español o el idioma deseado) mejora la experiencia.
- Medir tiempo real de ejecución y tokens consumidos ayuda a comparar eficiencia además de calidad. Un modelo más rápido no siempre gana en calidad, pero es un factor relevante en producción.
- El modo autónomo con Gemini reduce la carga manual, pero siempre es buena idea tener un modo de revisión humana para casos más subjetivos.
📁 Versionado y deploy: GitHub + Hostinger
Una vez la app funciona localmente en Google AI Studio, el siguiente paso fue versionarla y publicarla. Google AI Studio facilita exportar y vincular un repositorio en GitHub. El flujo seguido fue:
- Crear el repo desde Google AI Studio (puede quedar privado o público).
- Guardar cambios y hacer «stage and commit» directamente desde la plataforma.
- Conectar Hostinger Cloud con GitHub para deploy automático. Hostinger detectó el framework (aplicaciones React/Bit generadas por Google AI Studio) y propuso la configuración por defecto.
- Añadir variables de entorno necesarias (por ejemplo, gemini-api-key) en el panel de despliegue de Hostinger antes de compilar.
Hostinger Cloud permite desplegar aplicaciones Node.js directamente desde GitHub. Si necesitas una opción más técnica, también existe la alternativa de VPS, pero el plan Cloud simplifica mucho el proceso para quienes no quieren gestionar servidores manualmente.
Enlace para Hostinger: https://hostinger.com/rodrigo
🚧 Problemas comunes y soluciones rápidas
Aquí tienes una lista de problemas que aparecieron en el camino y cómo se resolvieron:
- No se muestra el resultado hasta que ambos modelos terminan
Solución: ajustar la lógica para renderizar cada columna tan pronto como su modelo termine. Mostrar tiempo, coste y tokens inmediatamente. - Código inválido generado por un modelo
Solución: capturar errores, mostrar mensaje de “código inválido” y permitir reintento automático o manual. - Barras de scroll ocultas por el header simulado
Solución: refactorizar el componente de vista previa para usar Flexbox y permitir scroll independiente en cada iframe. - Deploy falla por configuración del build
Solución: pedir a la herramienta que ajuste automáticamente el build para el entorno de deploy (prompt corto que indica “ajusta lo mínimo necesario para que funcione en un despliegue”).
💡 Buenas prácticas para comparar modelos
Comparar modelos no es solo lanzar prompts y ver quién genera cosas bonitas. Considera métricas y criterios bien definidos:
- Fidelidad al prompt: ¿cumple con los requisitos? (estructura, secciones, estilos, elementos solicitados).
- Claridad y organización: ¿está bien organizado y legible el código o el contenido generado?
- Completitud: ¿entrega todas las secciones solicitadas (header, hero, features, pricing, footer)?
- Rendimiento: tiempo de respuesta y tokens consumidos.
- Robustez: manejo de errores, validación y consistencia de formato.
Definir estos criterios de antemano permite que la evaluación de Gemini sea coherente. También ayuda a elegir modelos según la prioridad: calidad vs coste vs velocidad.
🔎 Un ejemplo práctico: tres rondas de prueba
En la prueba se ejecutaron tres rondas rápidas con prompts del tipo “componente básico”, “landing page” y “dashboard”. De forma resumida:
- Una ronda sufrió problemas porque uno de los modelos no respondió correctamente; la app reintentó automáticamente y el fallo quedó registrado como “System Failure” en español.
- Otra ronda mostró a Nova 2 Lite ganando 3-0 frente a un modelo gratuito sencillo por consistencia en resultado y tiempo.
- Una ejecución posterior con modelos distintos resultó en empate técnico: ambos generaron dashboards completos pero con estilos distintos (uno con un look más cyberpunk, otro más sobrio).
El valor de este ejercicio no fue solo el ganador final, sino ver cómo se comportan distintos modelos en tareas concretas y cómo ajustar la interfaz y la lógica para mostrar información útil (scroll independiente, tiempos, tokens y frame renderizado).
🧭 Consejos rápidos para replicar este proyecto
- Empieza por definir claramente los modos de operación: versus manual y autónomo.
- Escribe un prompt maestro que describa la UI, endpoints, manejo de errores, métricas y UX deseada.
- Usa Open Router para centralizar acceso a modelos y filtrar por “free” para pruebas tempranas.
- Implementa render incremental: cada columna debe mostrar su resultado cuando esté listo.
- Incluye un modo de reintento y mensajes claros en el idioma principal de la app.
- Versiona en GitHub y configura deploy automático a Hostinger Cloud, añadiendo variables de entorno necesarias.
📚 Recursos y links (útiles para comenzar)
Guarda estos enlaces para seguir el mismo flujo:
- Google AI Studio: https://aistudio.google.com
- Open Router: https://openrouter.ai
- Hostinger con descuento: https://hostinger.com/rodrigo
- Prompt usado y documentación: https://docs.google.com/document/d/1Zfu8Q-Z5UPRxPO1jVB4WqN31R5cYl71d_m3f682wpjU/edit?usp=sharing
- Playlist de proyectos (más ejemplos): https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
🚀 Conclusión y próximos pasos
Crear una arena de modelos es una forma práctica de entender las fortalezas y limitaciones de distintas IAs en tareas reales. Con Google AI Studio puedes prototipar la interfaz rápidamente; con Open Router obtienes acceso a muchos modelos con una sola API; y con Hostinger puedes publicar y probar tu aplicación en producción sin complicarte con servidores.
Si vas a replicar este proyecto, prioriza:
- Un prompt bien estructurado que sirva como especificación completa.
- Una UX que muestre resultados parciales y métricas útiles.
- Automatización del deploy para iterar rápido.
El próximo paso natural es ampliar la arena: más modelos, métricas adicionales (por ejemplo, cobertura semántica), datasets de referencia y un modo de torneo donde múltiples modelos compitan en rondas eliminatorias.
¿Quieres probar lo mismo ahora?
Comienza por obtener tu API en Open Router: https://openrouter.ai. Luego genera tu proyecto en Google AI Studio: https://aistudio.google.com. Si vas a publicar la app, usa Hostinger Cloud para deploy automático: https://hostinger.com/rodrigo. Y si prefieres tener el prompt listo, aquí está: https://docs.google.com/document/d/1Zfu8Q-Z5UPRxPO1jVB4WqN31R5cYl71d_m3f682wpjU/edit?usp=sharing
Gracias por llegar hasta aquí
Si sientes curiosidad por experimentar con prompts, evaluación automática y comparativas de modelos, este proyecto es una base sólida. Crea, rompe, arregla y vuelve a publicar: ese ciclo es el corazón del aprendizaje práctico con IA.
