Capítulo 12: El Capstone (Construyendo un Juego)
¿Puede Nanocode construir algo en realidad?
El “Desafío Cero Código”: construir un juego clásico de Snake usando Python y Pygame. La regla: no se permite escribir ni una sola línea de Python. Solo puedes hablarle al agente en inglés.
 |
Aparte: Esta demo implica muchas llamadas a la API. Si alcanzas los límites de tasa (HTTP 429), el agente reintentará automáticamente. Para sesiones largas, considera usar un modelo local a través de Ollama para evitar los límites por completo. |
Paso 1: Preparación
Desde la raíz de tu proyecto (el directorio que contiene nanocode.py y .env), crea un directorio de trabajo para el juego:
|
Aparte: Trabajamos en un subdirectorio para que el |
1 mkdir -p snake_game
2 cp nanocode.py snake_game/
3 cp .env snake_game/
4 cd snake_game
Si estás usando el repositorio de código del libro, copia desde ch11 en su lugar:
1 mkdir -p snake_game
2 cp resources/code/ch11/nanocode.py snake_game/
3 cp .env snake_game/
4 cd snake_game
Instalar Pygame:
1 pip install pygame
|
Aparte: Los comandos de shell anteriores son para macOS/Linux. En Windows, usa |
Paso 2: El Arquitecto (Plan Mode)
Inicia el agente. Comenzamos en plan mode porque queremos un plano antes de poner los ladrillos.
1 python nanocode.py
El Prompt:
1 Build a classic Snake game using Pygame. Include a score counter and Game Over screen with a restart option. Put ALL code in ONE file: snake.py. Write the plan in PLAN.md.
El agente usará write_plan para crear PLAN.md. Léelo. Debería describir la clase Snake, la clase Food y el bucle del juego, todo en un único archivo.
Si el plan parece razonable, pasa al Paso 3.
Paso 3: El Constructor (Modo de Acción)
Cambia al modo de acción:
1 /mode act
El prompt:
1 Implement the plan in snake.py. All code in one file.
Observa la terminal:
1 → Writing snake.py
El agente está generando código basándose en el contexto que almacenó en PLAN.md.
Paso 4: La Prueba de Realidad
Antes de ejecutar el juego, aumenta el tiempo límite. Los 30 segundos predeterminados no son suficientes para jugar una partida completa: el bucle principal de Pygame se bloquea hasta que cierras la ventana. Establece la variable de entorno antes de lanzarlo:
1 export NANOCODE_TIMEOUT=300
El Prompt:
1 Run the game with: python snake.py
El agente ejecuta run_command. Aparece una ventana. Juegas a Snake.
Si se bloquea con un error: Los LLMs son no determinísticos. Es posible que tu agente produzca un error en el primer intento. Si el juego falla con un error como AttributeError: 'Snake' object has no attribute 'draw', no lo corrijas tú mismo. Permite que el agente vea el stderr.
El prompt:
1 The game crashed. Read the error and fix it.
El agente leerá el traceback, usará read_file para encontrar el bug, usará edit_file para parchearlo y lo ejecutará de nuevo.
Paso 5: El Pivote (Feature Creep)
El juego funciona, pero es feo. La serpiente no es más que cuadrados verdes. Pongamos a prueba la capacidad del agente para refactorizar.
El Prompt:
1 The game looks boring. Make the snake change color as it eats food, increase speed every 5 points, and search the web for 'cool retro game color palettes' to apply.
El agente debería:
- Usar
search_webpara buscar paletas de colores - Usar
read_filepara entender la lógica de renderizado actual - Usar
edit_filepara inyectar las nuevas funcionalidades - Ejecutar el juego para verificarlo
Qué Sale Mal
Tus resultados serán distintos a los míos: los LLMs son no deterministas. Pero esto es lo que suele ocurrir y en qué debes fijarte.
Fallos habituales en la primera ejecución:
ModuleNotFoundError: No module named 'pygame'— el agente olvidó que necesitas instalarlo, o ejecutó el script en un entorno diferente. Dile que primero ejecutepip install pygame.AttributeErroren un método que el agente definió pero escribió mal en el punto de llamada. El agente corrige estos errores rápidamente en cuanto ve el traceback.- Errores de desfase por uno en la detección de colisiones. La serpiente atraviesa las paredes o muere un píxel demasiado pronto. Estos requieren 2-3 iteraciones de editar-ejecutar-corregir.
El arco típico de una sesión:
En mis pruebas, el agente suele conseguir un juego funcional (aunque poco vistoso) en 2-4 iteraciones. La primera escritura produce algo que falla. La segunda o tercera corrección logra que funcione. El paso de incorporación de funcionalidades extra (cambios de color, incrementos de velocidad) añade otras 3-5 iteraciones mientras el agente lee su propio código, hace ediciones quirúrgicas y verifica cada cambio.
Al final, la conversación tiene entre 15 y 20 rondas. Si usas Claude, presta atención al activador de compactación: alrededor de la ronda 12-15 verás “(Compacting conversation…)” cuando el recuento de tokens se acerque al umbral del 75%. Tras la compactación, el agente pierde algo de detalle sobre las rondas iniciales, pero sigue trabajando. Este es el sistema del Capítulo 9 justificando su valor.
Dónde le cuesta al agente:
El sistema de coordenadas de Pygame y el bucle de eventos son complicados. A veces el agente escribe código que renderiza correctamente, pero no gestiona bien la entrada del teclado, o dibuja la serpiente en el orden incorrecto de modo que la cabeza aparece detrás del cuerpo. Son el tipo de errores que un humano detecta al instante, pero que el agente no puede ver: no tiene feedback visual, solo stdout y stderr. Si el juego se ejecuta sin errores pero se ve mal, tendrás que describir el error visual: “La serpiente se renderiza al revés: la cabeza debería estar al frente.”
El objetivo no es la perfección en el primer intento. Es que el agente converja: escribir, ejecutar, leer el error, corregir, repetir, usando cada herramienta que construimos a lo largo de once capítulos.
Antes de entregar el snake.py definitivo, léelo. El agente escribe código que funciona, pero un humano debería igualmente auditarlo en busca de cosas que el bucle de pruebas no puede detectar: números mágicos en el código, casos límite que faltan (¿qué pasa si se redimensiona la ventana?) y si el código está estructurado de una manera que querrías mantener. El agente es un redactor rápido, no un revisor final.
Conclusión
Planificar, implementar, fallar, depurar, corregir, ejecutar de nuevo: cada capítulo demostrando su utilidad.
¿Y a partir de aquí, adónde va?
Epílogo
Todo el conjunto son unas 750 líneas de Python. Sin frameworks. nanocode.py es tuyo. Haz con él lo que quieras:
- Integración con Git que haga commits automáticos tras pasar los tests
- Depuración basada en capturas de pantalla para trabajo de frontend (Claude puede leer imágenes)
- Entrada de voz mediante Whisper para que puedas hablar en lugar de escribir
- MCP para conectarte a servicios externos que tu equipo ya utiliza
- Sub-agentes que bifurcan conversaciones y trabajan en subtareas en paralelo
Los agentes de producción como Claude Code, Cursor y Copilot hacen más que esto: respuestas en streaming (ver Apéndice A), ejecución de herramientas en paralelo, tree-sitter parsing, entornos de ejecución aislados, ventanas de contexto que abarcan miles de archivos. La distancia entre 750 líneas y 750.000 es real. Pero la arquitectura es la misma: un cerebro, un bucle, herramientas, memoria y un arnés de seguridad. Ahora ya sabes qué hay detrás del telón.
Los modelos seguirán mejorando. El arnés —el bucle, las herramientas, las comprobaciones de seguridad— esa parte es ingeniería. Y esa parte no va a desaparecer.