2026-06-01 Reflexión
Lo que hice hoy
Hoy ejecuté directamente el proyecto de Godot para verificar el resultado de la generación del mapa y, en ese proceso, volví a probar cuánto siguen las herramientas de codificación con IA el trabajo real de desarrollo de juegos.
También personalicé el MCP de investigación web en mi repositorio privado. En lugar de usar el web-search-mcp básico tal cual, intenté ajustarlo a mi flujo de búsqueda y salida deseados. Sentí que una herramienta de búsqueda es casi indispensable cuando se trata de información que cambia continuamente, como diseño, Godot y documentación reciente.
Herramientas probadas
Probé Qwen Code, Codex y OpenCode.
Para ir al grano, ninguna resultó tan estable como esperaba. Qwen Code devolvía respuestas repetitivas con demasiada frecuencia. El mismo plan se generaba, el mismo archivo se buscaba y el flujo de confiar en rutas fallidas se repetía. Si no se configura y ajusta según la documentación, parece que este problema de repetición no se mejora fácilmente, sin importar el modelo que se use.
Codex y OpenCode fueron un poco mejores que Qwen Code en cuanto a la llamada de la herramienta, pero no comprendían profundamente el contexto de trabajo en Godot o fallaban en la interpretación de imágenes. Algunas respuestas se cortaban a mitad, o el propio modelo intentaba planear pero no lograba estructurar bien el plan, e incluso invocaba sub‑agentes que “investigaban” consultando el sistema de archivos de forma extraña.
Cuando no era Qwen Code, la integración del MCP web-search tampoco funcionaba bien, lo que resultó frustrante. Por el contrario, con Qwen Code el problema de repetición y la interpretación del estado persistían incluso usando el MCP.
Experimentos con modelos
Otros modelos tendían a proponer patrones de código de versiones anteriores de Godot en lugar de la versión más reciente, así que busqué un modelo más especializado y probé el modelo bekoozkan/godot-gemma-4-e4b-it-GGUF de Hugging Face.
Tenía la esperanza de que entendiera mejor Godot, pero sus limitaciones fueron evidentes. El modelo era demasiado pequeño y no comprendía bien contextos extensos.
Especialmente en tareas donde la verificación de imágenes es crucial, resultó muy frustrante. Necesitamos determinar si el mapa se ve extraño, dónde está la incongruencia y juzgarlo a partir de la pantalla real, pero los modelos no lograron interpretar las imágenes de forma fiable. En el desarrollo de juegos no basta con que el código sea correcto; la naturalidad de la pantalla es esencial, y en este aspecto las herramientas de IA fallaron notablemente.
Problemas percibidos en el trabajo con Godot
Godot resultó ser un área que los modelos conocen menos de lo que aparentan. La sintaxis reciente, la estructura de escenas, el comportamiento del editor, las rutas de recursos y la verificación de resultados de ejecución están interconectados, pero muchos modelos responden basándose solo en fragmentos de código y conocimientos obsoletos.
El trabajo real de hoy se redujo a ejecutar Godot y confirmar que el mapa se veía extraño. Sin embargo, alrededor de eso tuve que ajustar herramientas, conectar el MCP, cambiar de modelo, lidiar con problemas de sandbox y de interpretación de imágenes. En realidad, el tiempo dedicado a manejar las herramientas fue mayor que el dedicado al propio juego.
Sentimientos restantes
Sinceramente, sentí que este campo no encaja bien conmigo.
Esperaba que ensamblar bien las herramientas de IA facilitara el desarrollo, pero en la práctica tuve que comprobar constantemente que la herramienta perdía su estado, se repetía, buscaba archivos incorrectos, no veía imágenes o solo sugería código anticuado. Lo que quiero crear es un juego, pero pasaba el tiempo depurando los límites de la herramienta.
Aún así, obtuve aprendizajes. El MCP de investigación web es necesario, Qwen Code necesita un ajuste fuerte según la documentación, y el trabajo en Godot debe acompañarse siempre de una verificación visual real. En lugar de delegar todo el plan y la ejecución a la LLM, es más realista que una persona o script controle el bucle de validación y que la LLM se use solo para borradores y decisiones auxiliares.
A partir de mañana pienso que debo hacer un fine‑tuning directo. Simplemente conectar un modelo genérico o un modelo público especializado en Godot no fue suficiente para seguir el flujo de versión, método de trabajo y validación visual que necesito. Necesito recopilar ejemplos y casos de falla para crear un conjunto de datos adaptado a mi forma de trabajar.
Criterios para dejar registro en el futuro
- No consideraré completado un trabajo en Godot sin verificar la pantalla de ejecución.
- No confiaré únicamente en la respuesta del modelo para tareas que requieran juicio basado en imágenes.
- A partir de mañana recopilaré patrones de trabajo y casos de falla en Godot para preparar un fine‑tuning propio.
- Usaré Qwen Code solo después de haber configurado la prevención de repeticiones y la integración del MCP.
- Asumiré que Codex y OpenCode tienen limitaciones en el contexto de Godot y en la interpretación de imágenes.
- Si el modelo no puede planificar y solo repite llamadas a herramientas, lo detendré de inmediato.
- La investigación web seguirá siendo necesaria, pero la decisión de conectar los resultados a la codificación se verificará por separado.