Contexto Técnico: Qué Demostró Realmente el 'Dog-Game'
Leí el análisis de Caleb Leak sobre el “dog-game” y no vi una linda historia sobre un perro, sino un experimento muy limpio de ingeniería de procesos. El perro Momo genera pulsaciones aleatorias de teclado, y Claude (a través de Claude Code) las interpreta como requisitos del juego, construyendo proyectos completos en Godot 4.6 con lógica en C#.
La clave no es un “prompt mágico”, aunque el enfoque es fuerte: cualquier tontería se trata como los "comandos ocultos de un diseñador genial". El verdadero poder reside en el ciclo de verificación cerrado (verification loop): generar → compilar → ejecutar herramientas → obtener feedback observable (capturas de pantalla, scripts de entrada, revisiones de escenas/shaders) → corregir.
El segundo pilar son los límites (boundaries). Leak fija el motor (Godot 4.6) y el lenguaje (lógica 100% C#), reduciendo drásticamente el espacio de errores. Para mí, esto parece un contrato arquitectónico: el modelo puede “fantasear”, pero solo dentro de límites predefinidos y con validación obligatoria de los resultados.
Técnicamente, esto es muy similar a cómo construyo contornos de fiabilidad en asistentes corporativos. No "pedimos que escriba código", sino que obligamos al código a pasar por puertas medibles. En el dog-game, estas puertas son simples (capturas/linter/autocompletado), pero convierten la generación en un ciclo de calidad gestionable.
Impacto en el Negocio y la Automatización: Quién Gana y Quién Paga
Si hoy practicas el vibe-coding en el desarrollo de productos, básicamente estás trasladando el riesgo a tu equipo: “ya lo arreglaremos luego”. En el sector real, esto se convierte rápidamente en lanzamientos retrasados, degradación de la calidad y mayores costes de mantenimiento. He visto esto en proyectos donde la IA se utilizó como un “acelerador” pero sin ciclos de control: la velocidad inicial se transformó en caos final.
Los ganadores son las empresas que no invierten en “otro modelo más”, sino en la automatización de la IA en torno al desarrollo: pruebas, análisis estático, compilaciones, verificación de migraciones, entornos sandbox y políticas de acceso. Así es como la "implementación de la IA" deja de ser un juguete y se convierte en un proceso de producción.
Los perdedores son los que compran "programación con IA" como una suscripción y creen que es suficiente. Una suscripción no crea control de calidad; la arquitectura del pipeline sí. En términos de arquitectura de IA, yo lo plantearía así: el modelo no es el ejecutor, sino un generador de hipótesis, mientras que el ejecutor es tu ciclo de verificación.
En Nahornyi AI Lab, solemos empezar con una pregunta: ¿qué artefactos generados pueden verificarse automáticamente mañana mismo? Pueden ser pruebas unitarias/integración, pruebas de contratos de API, lints, SAST/escaneo de secretos, ejecución de scripts de interfaz de usuario o comparación de métricas de rendimiento. Una vez establecidas las puertas, la “integración de inteligencia artificial” en el SDLC se vuelve predecible en cuanto a riesgos y presupuesto.
Visión Estratégica: Los Límites como la Nueva “Especificación” de la IA
Mi conclusión menos obvia del dog-game: los límites son una nueva forma de especificación. Antes, redactábamos los requisitos en Confluence y esperábamos que el desarrollo los implementara "más o menos". Ahora, los límites pueden formalizarse de tal manera que el modelo físicamente no pueda desviar el proyecto: archivos permitidos, dependencias aceptables, bloqueo de llamadas de red, un núcleo de API estricto y contratos inmutables.
Observo un patrón similar en las implementaciones empresariales: los mejores resultados no provienen del “agente más inteligente”, sino de un sistema en el que el agente choca constantemente con las mediciones. Si no hay mediciones (no hay pruebas, no hay observabilidad, no hay criterios de aceptación), la IA generará basura con total seguridad, y además parecerá convincente.
El siguiente paso que pronostico para 2026: los ciclos de verificación se convertirán en productos estándar en lugar de ingeniería a medida. Surgirán “ciclos” estandarizados para dominios típicos (personalizaciones de ERP, ETL, RPA, frontend), pero la ventaja competitiva seguirá siendo de aquellos que sepan diseñarlos para su contexto, sus datos y sus normativas.
Si necesitas soluciones reales de IA para negocios y no solo una demostración, te plantearía la tarea de la siguiente manera: construir un contorno mínimo de límites + verificación alrededor de los errores más costosos. Esto proporciona un ROI rápido y disciplina al equipo más que cualquier “regla de uso de IA”.
Qué Recomiendo Hacer en la Práctica
- Fijar los límites: stack tecnológico, dependencias, zonas de edición, restricciones, formato de PR.
- Construir un ciclo de verificación: compilación, pruebas, lint, escaneos de seguridad, revisiones mínimas e2e.
- Habilitar la “retroalimentación de la máquina”: asegurar que el modelo lea los reportes de las herramientas, no las opiniones humanas.
- Introducir métricas: tasa de aprobación de puertas, tiempo de resolución, defectos post-lanzamiento.
Este análisis ha sido elaborado por Vadym Nahornyi, experto principal de Nahornyi AI Lab en arquitectura de IA, automatización de IA e integración de IA en procesos del mundo real. Si deseas convertir la programación con IA de una improvisación a un sistema de calidad gestionable, te invito a discutir tu proyecto: analizaré tu SDLC actual, te propondré una arquitectura de ciclo de verificación y te ayudaré a lanzarla a producción sin romanticismos, pero con resultados medibles.