Análisis, plan, código, comprobaciones: nuestro ritmo para desarrollar con IA 🤖

Nunca hemos ocultado que usamos mucho la IA en Blocks Beyond The Stars: sin ella, un juego de este tamaño simplemente no sería posible como proyecto de después del trabajo. Pero para nosotros «desarrollar con IA» no significa escribir un deseo, quedarse con el resultado y esperar lo mejor. Con los meses ha surgido un patrón fijo que suena sorprendentemente anticuado, y funciona justo por eso. Hoy lo contamos entero.

Siempre empieza con una persona y una idea. Antes de que la IA haga nada, alguien quiso o notó algo: un jugador que usa la tecla de comentarios para contarnos que aparecen animales dentro de sus muros, o nosotros mismos, cuando Justus dice en plena partida lo que echa en falta. Aquí la IA no se inventa tareas. Se las dan.

Después la IA trabaja por fases. Cuatro, siempre en el mismo orden: análisis, planificación, implementación, verificación. (El quinto paso, las pruebas manuales, viene después, pero eso vuelve a ser trabajo de una persona; ahora lo vemos.) El truco más importante es lo que la IA no puede hacer: escribir código de inmediato. Una IA que se pone a teclear al instante resuelve el problema equivocado a una velocidad impresionante. Por eso toda tarea grande empieza con un análisis: qué hay ya, dónde está realmente la causa, qué más depende de ello. El resultado es texto, no código.

Luego viene el plan, y se lee. Al análisis le sigue la planificación: qué archivos se tocarán, en qué orden, qué trampas se conocen, qué decisiones siguen abiertas. Justo aquí salen las preguntas que conviene responder antes de programar («¿Debería funcionar también en el navegador?», «¿Qué pasa con las partidas guardadas antiguas?»). Solo cuando el plan está en pie llega la implementación, que a menudo es la parte más aburrida de todo. Y así debe ser.

Lo que está relacionado va en un solo lote. Una segunda regla que nos ahorra mucho tiempo: cuando varios problemas se parecen o están conectados (cinco menús de mando que comparten el mismo problema de foco, o quince hallazgos de la misma ronda de pruebas), la IA los recibe agrupados como un solo trabajo, no como quince por separado. Así solo tiene que recorrer una vez el código afectado, las soluciones encajan en vez de contradecirse y nada se cae entre dos trabajos.

Antes de cada lanzamiento: dos rondas de inspección separadas. Después de cada paso de trabajo grande, y siempre antes de que una versión nueva llegue a ti, ponemos a la IA a revisar el resultado una vez más. Pero con dos investigaciones deliberadamente separadas. Primera: ¿están las funciones y correcciones previstas realmente del todo terminadas, o queda por ahí un resto a medias, un caso límite olvidado, una traducción que falta? Segunda, en una pasada aparte: ¿han causado los cambios problemas nuevos en otro sitio? Mezclar las dos en una sola pregunta no funciona: quien busca huecos y daños colaterales a la vez encuentra la mitad de cada cosa. Preguntadas por separado, estas dos cuestiones nos ahorran una enorme cantidad de trabajo repetido; buena parte de lo que aparece en las notas de la versión como «arreglado de paso» sale justo de estas rondas de inspección.

Y al final del todo, una persona prueba otra vez. El quinto paso no es una fase de la IA sino nuestra: las pruebas manuales significan jugar de verdad. Versión recién compilada, un mando de verdad, un niño de verdad jugando. Muchas cosas que sobreviven a todos los análisis mueren en los primeros cinco minutos en el sofá. Porque si algo se siente bien es una pregunta que ningún análisis del mundo puede responder.

Si te fijas bien, no encontrarás magia de IA en este patrón, solo un oficio de ingeniería de toda la vida: primero entender, luego planificar, luego construir, luego comprobar. Y para nosotros el paréntesis que lo rodea es siempre el mismo: una persona tiene la idea, una persona hace la prueba final y la IA trabaja en medio. Lo único nuevo es lo rápido que se ha vuelto ese ciclo. 🔍