¿Cómo escribir una tarea para un asistente de IA cuyo resultado puedas revisar?
Pide un solo cambio, di dónde va y qué no debe cambiar, da una comprobación que pase o falle y pide un informe de lo que se hizo.
Pide un solo cambio, lo bastante pequeño para probarlo en unos minutos. Di dónde va, qué debe quedar como está, cómo comprobar que funciona y qué quieres que te respondan. Una tarea escrita así vuelve como algo que puedes juzgar: una lista corta de archivos cambiados, una comprobación que pasó o falló y un juego que puedes jugar para confirmarlo. Una tarea vaga vuelve como un cambio grande que «parece terminado», y entonces toda la revisión queda en tus manos.
¿Qué hace que una tarea se pueda revisar?
Cinco partes. La mayoría de las tareas necesitan las cinco, y cada una cabe en una o dos oraciones.
| Parte | Qué escribir | Por qué ayuda a revisar |
|---|---|---|
| 1. El cambio | Una cosa que el juego debe hacer distinto | Puedes ver si ocurrió |
| 2. Dónde | El archivo, la pantalla o la función a la que pertenece | El cambio se queda en un solo lugar |
| 3. Qué no debe cambiar | Controles, partidas guardadas, otras pantallas, bibliotecas | Todo lo que quede fuera de la lista se nota |
| 4. La comprobación | Una prueba, un comando o pasos para jugar | Da un pasa o falla, no una impresión |
| 5. El informe | Archivos cambiados, comprobaciones hechas, qué no se probó | Lees evidencia en lugar de repetir el trabajo |
Nada de esto es nuevo. La guía de GitHub para escribir prompts para Copilot pide una solicitud simple y concreta, dividida en pasos, con uno o dos ejemplos de lo que esperas. Las buenas prácticas de Claude Code ponen primero una comprobación que el asistente pueda ejecutar, porque sin ella «parece terminado» es la única señal que tiene. Así se leían ambas páginas el 25 de octubre de 2026. Lo que sigue las aplica a un juego pequeño.
¿Qué tan pequeña debe ser una tarea?
Lo bastante para describir el cambio en una oración y probarlo en unos minutos. «Agrega una pantalla de pausa» es una tarea. «Agrega una pantalla de pausa, un menú de ajustes y sonido» son tres, y cuando algo se rompa no sabrás cuál fue.
Si una tarea necesita una descripción más larga, pide primero un plan y deja el código para después. La página de Claude Code sugiere justo eso: deja que el asistente lea el código y proponga qué archivos cambiarían, lee el plan tú mismo y solo entonces deja que escriba. Un plan que toca medio proyecto es señal de que la tarea debe dividirse.
Es la misma regla que mantener tu primer juego pequeño: cada función tiene que funcionar con todas las demás, así que una tarea que agrega tres multiplica la revisión.
¿Cómo se ve una tarea vaga junto a una que se puede revisar?
Aquí está un mismo pedido para un pequeño juego de disparos, escrito dos veces.
| Vaga | Revisable |
|---|---|
| «Haz el juego más difícil». | «En el código de las oleadas, haz que cada oleada nueva sea un 10% más rápida que la anterior, hasta el doble de la velocidad inicial. No cambies la velocidad del jugador, las vidas ni los controles». |
| «Arregla el error del puntaje». | «Después de reiniciar, el puntaje empieza en el valor anterior en vez de 0. Encuentra dónde el reinicio restablece el juego, haz que también restablezca el puntaje y agrega una prueba que reinicie dos veces y espere 0». |
| «Agrega controles móviles». | «En pantallas táctiles, muestra botones de izquierda, derecha y disparo que envíen los mismos eventos de teclas que el teclado. Jugar con teclado no debe cambiar. Dime qué pantallas todavía no tienen control táctil». |
La columna de la derecha es más larga, pero cada línea se puede comprobar. La tercera se parece a lo que hicimos al agregar controles táctiles a KittenGalaxy: los botones envían los eventos de teclas que enviaría el teclado, así que el juego en sí no tuvo que cambiar.
¿Cómo le dices al asistente cómo comprobar su trabajo?
Dale algo que responda sí o no.
- Una prueba que el asistente pueda ejecutar, con los casos escritos: «un reinicio deja el puntaje en 0».
- Un comando cuyo resultado se pueda leer: la compilación termina, la página carga sin errores en la consola.
- Pasos que jugarás tú, escritos antes del cambio: «empezar, perder todas las vidas, pulsar reiniciar, el puntaje muestra 0».
Pide al asistente que ejecute la comprobación y muestre la salida, no que diga que pasó. Un resultado de prueba pegado o un registro de consola sin errores se lee en segundos; una frase como «todo funciona» no prueba nada.
Algunas cosas solo puede juzgarlas una persona: si un salto se siente bien o si un nivel es justo. Para esas, escribe qué vas a mirar y juégalo tú. No dejes que el informe del asistente lo reemplace.
¿Qué debe decirte el asistente cuando termina?
Pide en la misma tarea un informe corto, en este orden:
- qué archivos cambiaron y, en una línea cada uno, por qué;
- qué comprobaciones ejecutó y qué devolvieron;
- qué no probó, y por qué;
- cualquier cosa que cambió sin que la pidieras.
El último punto es el más importante. Un cambio más allá del pedido no siempre está mal, pero siempre es algo que no pensabas revisar. Compara la lista de archivos con la parte 3 de tu tarea: un archivo que no debía cambiar es el primer lugar donde mirar.
¿Qué va en un archivo del proyecto en lugar de en cada tarea?
Todo lo que de otro modo repetirías: cómo ejecutar el juego y las pruebas, qué carpetas no se tocan, las reglas del código. La mayoría de los asistentes leen un archivo así al inicio de una sesión (Claude Code lo llama CLAUDE.md). Mantenlo corto; la página de Claude Code advierte que en un archivo largo las reglas importantes se pierden.
Una regla merece estar ahí cuando olvidarla rompe el juego. Las notas que llevamos para KittenGalaxy dicen que, cada vez que se agrega una tecla, una pantalla o un estado del juego, su control táctil se agrega en el mismo cambio, porque si no los jugadores en el teléfono no pueden llegar a él. Así una tarea solo tiene que decir lo que es nuevo.
¿Qué haces cuando el resultado está mal?
Vuelve atrás y pide otra vez con una tarea mejor.
Guarda una versión que funcione antes de cada tarea, como un commit en el control de versiones, para que un mal cambio se deshaga en un paso. Cuando una comprobación falla, puedes pedir una corrección una o dos veces. Si dos correcciones fallan, la página de Claude Code sugiere empezar una sesión nueva con un mejor primer pedido en lugar de corregir una y otra vez, porque los intentos fallidos quedan en la conversación. Deshaz el cambio, agrega a la tarea lo que aprendiste y envíala de nuevo.
Preguntas frecuentes
¿Necesito ser programador para escribir tareas así? No. Las partes 1, 3 y 5 tratan de lo que hace el juego, en palabras simples. Para la parte 2, pregunta al asistente dónde va el cambio antes de pedirle que lo haga.
¿Una tarea larga es mejor que una corta? No por sí misma. Una tarea larga que pide muchos cambios es más difícil de revisar que una corta que pide uno. La longitud ayuda cuando agrega una comprobación o un límite.
¿Debo pedir pruebas en un juego pequeño? Para reglas que se pueden decir con exactitud (el puntaje, las vidas, un temporizador, las partidas guardadas), sí. Cuestan poco de ejecutar después de cada cambio posterior. La sensación y la diversión siguen necesitando jugarse.
¿Y si el asistente me hace preguntas? Respóndelas en la tarea antes de que empiece a escribir. Una pregunta hecha temprano cuesta menos que un cambio equivocado.
¿Cuándo está el juego listo para mostrarlo? Cuando un desconocido puede iniciarlo desde un enlace y terminarlo sin tu ayuda. Entonces puedes enviarlo a HeapPlay, y los desarrolladores verificados pueden registrar cada nueva versión y lo que cambió.
ai-assistants workflow testing
¿Estás haciendo un juego? Envíalo a HeapPlay y mira qué reciben los desarrolladores.