Tutorial 4 Prompting and Reviewing es

Tutorial 4 · Prompting y revisión

Meta: la meta-habilidad. Ya puedes construir una función con un agente — este capítulo trata de hacerlo sin fricción y de forma repetible: escribir prompts que acierten a la primera, revisar diffs con eficiencia, iterar cuando algo sale mal y mantener el impulso entre sesiones.

← Anterior: Tutorial 3 Tu primera tarea con el agente · Siguiente: Tutorial 5 Localización

---

Haz prompts como líder, no como buscador

El agente es un ingeniero júnior rápido, literal y entusiasta. Lidéralo como liderarías a uno bueno:

• Enuncia la meta y las restricciones. “Agrega endorse” es débil. “Agrega endorse siguiendo el patrón de connect, solo RNG con semilla, con pruebas, la barrera se queda en verde” es fuerte. Las restricciones son cómo obtienes código que encaja.
• Apunta a ejemplos. “Sigue el patrón de renderConnect” gana a un párrafo de descripción. El código existente es la mejor especificación.
• Pide un plan antes de editar en cualquier cosa no trivial. Redirigir un plan es barato; deshacer diez archivos editados es caro.
• Una tarea por prompt. Juntar “agrega endorse, además refactoriza el RNG, además actualiza el README” produce un diff enredado y difícil de revisar.
• Dale la barrera de pruebas. “Ejecuta npm test y no lo consideres terminado hasta que esté en verde” convierte al agente en algo que revisa su propio trabajo.

Revisa el diff cada vez

La velocidad es el punto de un agente — pero la velocidad sin leer es cómo se publican bugs. Construye un reflejo de revisión rápido y consistente:

1. Alcance: ¿cambió solo lo que debía? Líneas no relacionadas que se mueven son una señal de alerta.
2. Patrones: ¿coincide con el código de alrededor, sin dependencias nuevas ni E/S dentro de src/?
3. Las reglas del proyecto: aquí eso es solo RNG con semilla (busca Math.random en el diff), texto visible en los paquetes de idioma (no incrustado), y las líneas de la tarjeta nunca exceden el ancho al que ajusta el diseño.
4. Accesibilidad: ¿la salida nueva sobrevive a --accessible? Ejecuta lockedin --accessible <your command> y comprueba que se lea como texto plano y limpio — sin glifos decorativos nuevos que se cuelen por a11yFilter.
5. Pruebas: ¿hay una prueba nueva, y de verdad fallaría si la función se rompiera? Pregunta: “¿Qué línea cambiaría para hacer que esta prueba nueva falle?”
6. Ejecútalo: npm test, luego corre el comando y mira la salida.

No necesitas entender cada carácter — pero debes entender cada decisión. Si no puedes explicar un cambio, pídele al agente que lo explique antes de aceptarlo.

Itera cuando no está en verde

Una barrera en rojo es un paso normal, no un fracaso. El arreglo es feedback preciso:

“npm test falla con: [paste the exact error]. La prueba de ancho de renderEndorse espera que cada línea de la tarjeta tenga ≤ 60 columnas visibles. Arréglalo sin debilitar la prueba.”

Pega el texto real del error. “Está roto” hace que el agente adivine; el stack trace hace que lo arregle. Y prefiere continuar la misma conversación en vez de empezar de cero — el agente ya tiene el contexto de lo que acaba de escribir. Si dos o tres iteraciones no convergen, da un paso atrás y replantea: la tarea puede ser demasiado grande para un solo prompt.

Mantén el impulso entre sesiones

El trabajo real abarca más de una sesión. Dos hábitos mantienen efectivo a un agente con el tiempo:

• Memoria / convenciones. Si tu agente admite memoria persistente o un archivo de instrucciones del proyecto, registra ahí las reglas que siempre debe seguir (p. ej., “toda la aleatoriedad debe usar pick/shuffle”, “el texto visible va en los paquetes de idioma”, “corre npm test antes de declarar terminado”). Enuncias una convención una vez en vez de en cada prompt.
• Una nota de traspaso. Este repo mantiene un documento de estado corto y saneado en docs/HANDOFF.md: qué es el proyecto, cómo está construido, cómo se prueba y qué sigue. Cuando vuelves (o le pasas el trabajo a un compañero — u otro agente), esa nota reconstruye el contexto en segundos. Pídele al agente que la mantenga actualizada como parte de un cambio.

Barreras que vale la pena mantener

• La barrera no es negociable. Pruebas en verde antes de publicar cualquier cosa. Es lo que te deja moverte rápido y confiar en la salida.
• Tú eres quien revisa y responde. El agente escribe; tú decides. Aceptar un diff significa que respondes por él.
• Pasos pequeños y verificables superan a un salto gigante. Cada cambio aceptado debería dejar la app funcionando.

---

✅ Pruébalo con tu agente

1. Escribe una especificación de un párrafo para un comando mentor (“da consejos no solicitados”), con restricciones incluidas, y haz que el agente lo construya con las pruebas primero — plan, pruebas, código, barrera — revisando en cada paso.
2. Pídele al agente que actualice docs/HANDOFF.md para mencionar el comando nuevo.
3. Rompe algo a propósito (p. ej., borra una entrada de un pool), corre npm test y practica darle al agente el fallo exacto para arreglar.

---

A dónde ir después

• Ojea el código real en src/lockedin.js — ya conoces su forma.
• Lee docs/HANDOFF.md para las notas de estado y arquitectura del propio proyecto.
• Disfruta los chistes en la Referencia de comandos.

Ese es el tutorial. Ya puedes dirigir a un agente de IA para construir y cambiar software real detrás de una barrera de pruebas — usando el ejemplo más presumido imaginable. ¿De acuerdo? 👇