🔁 Repetir no es mejorar: qué le falta a un bucle débil
🧠 Imagínalo así: ir al gimnasio todos los días sin anotar el peso, las repeticiones ni ninguna medida no es entrenar — es solo estar presente. Sin un criterio guardado de una vez a otra, no sabes si progresaste o solo diste vueltas en círculo.
Un ciclo de mejora de verdad no es «volver a mirar de vez en cuando»: es un ciclo con enfoque (un área pequeña a la vez), criterio guardado de un ciclo a otro, prueba que confirma si el cambio funcionó y un registro de lo aprendido. Quita cualquiera de estas cuatro piezas y lo que queda es repetición, no mejora.
✗ Ciclo débil (evítalo)
"Revisa mi app todos los días." Parece disciplina, pero no dice qué revisar, según qué criterio, qué hacer si encuentra algo ni dónde guardar lo descubierto. Sin esas respuestas, el agente repite la misma revisión genérica todos los días o, peor aún, usa un criterio distinto cada vez porque no se guardó ninguno.
Leyenda: a la izquierda, «revisar» solo gira sobre sí mismo, sin criterio ni registro; a la derecha, elegir → probar → registrar termina en una memoria que también alimenta el siguiente ciclo.
✓ Qué garantiza el loop fuerte
- ✓Elige un área pequeña por ciclo, no «toda la app».
- ✓Usa un criterio guardado de un ciclo al siguiente: no reinventa la vara cada vez.
- ✓Solo aplica el cambio si es seguro y reversible.
- ✓Haz una prueba real antes de aceptar que «mejoró».
- ✓Pídele a un verificador que intente encontrar errores.
- ✓Registra la lección en algo que perdure más allá del ciclo.
✗ Qué tiene el loop débil
- ✗"Revisa de vez en cuando" sin decir qué.
- ✗Ningún criterio guardado: cada ciclo reinventa lo que es «bueno».
- ✗Aplica un cambio sin comprobar si es reversible.
- ✗Acepta "parece mejor" sin ninguna prueba.
- ✗Solo la opinión de quien hizo el cambio, sin una segunda revisión.
- ✗Ningún registro: la próxima sesión empieza desde cero.
En una frase: un loop de verdad tiene enfoque, criterio, prueba y registro; sin los cuatro, es solo repetición con apariencia de disciplina.
🛠️ El bucle de 7 pasos — prompt copy-run
🧠 Imagínalo así: es la lista de verificación de boxes de un equipo de F1: cada parada sigue los mismos pasos, en el mismo orden, y termina con una nota sobre qué ajustar en la siguiente. Nadie improvisa la secuencia en cada parada.
El consejo 11 de la guía ofrece la receta concreta para convertir "revisar de vez en cuando" en un ciclo real: 7 pasos fijos, siempre en el mismo orden, que terminan volviendo a la memoria del proyecto (consejo 12, tema 4 más abajo).
Objetivo: darle al agente un guion fijo de verificación continua: lee el criterio guardado antes de actuar y registra la lección aprendida después, en lugar de reevaluarlo todo desde cero en cada ciclo.
A cada ciclo: 1. escolha uma área pequena do sistema; 2. analise com base nos critérios já salvos em memória; 3. proponha uma melhoria; 4. implemente somente se for segura e reversível; 5. rode teste; 6. peça ao verificador para tentar encontrar erro; 7. registre a lição aprendida.
Cómo comprobar: completa un ciclo de principio a fin y confirma al final que existe (a) un registro de criterios que se consultó de verdad en el paso 2 y (b) una nueva línea guardada en el paso 7. Si el paso 7 no dejó rastro en ningún sitio, el siguiente ciclo empezará desde cero: el loop no se cerró realmente.
Leyenda: los 7 pasos giran en círculo, siempre en el mismo orden; las flechas cian discontinuas muestran el vínculo con la memoria: «analizar» lee el criterio guardado, «registrar» guarda la lección aprendida y cierra el ciclo para la siguiente vuelta.
Cruce con la trilha 1 · fuente oficial
"Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification."
Los pasos 5 y 6 de este loop (ejecutar una prueba + pedirle al verificador que encuentre errores) reflejan exactamente esta técnica del módulo 1.4 de la ruta 1, respaldada oficialmente por la documentación de Anthropic. Allí el foco está en cómo delegar técnicamente esa verificación (subagent con contexto fresco); aquí, en el ritmo práctico de cuándo activar esa verificación dentro de un ciclo de mejora continua.
→ Profundiza en el módulo 1.4 — Déjalo actuar + demuestra que terminóEn una frase: 7 pasos fijos, siempre en el mismo orden — el criterio se define en el paso 2, la lección queda registrada en el paso 7.
🗂️ El problema de depender solo del historial del chat
🧠 Imagínalo así: una empresa donde todo el conocimiento importante vive solo en la cabeza de una persona o en un chat que nadie guarda. El día que esa persona se va — o se reinicia el chat — la empresa pierde todo lo que aprendió, aunque haya pasado meses aprendiendo.
En trabajos largos y continuos —un producto que evoluciona durante meses, una marca con campañas cada semana—, el historial de una sola conversación no es una memoria confiable. Una sesión nueva, un contexto que se desbordó o un chat que se borró: cualquiera de esas cosas elimina decisiones y aprendizajes que costó tiempo real conseguir.
Semana 1 — decisión tomada
Tú y el agente deciden, en una conversación larga, que la campaña X funciona mejor con un tono informal.
Semana 3 — sesión nueva
Contexto nuevo, chat diferente. El agente ya no tiene acceso a esa decisión: solo estaba en el historial de la conversación anterior.
Semana 3 — error repetido
El agente sugiere de nuevo un tono formal para la misma campaña porque no sabe que ya se probó y se descartó.
Resultado
Tiempo perdido reaprendiendo algo que ya tenía respuesta, y nadie se da cuenta hasta compararlo con lo que se decidió semanas atrás.
⚠️ El costo compuesto
Cada decisión que solo existe en el chat es una decisión que habrá que retomar desde cero en la próxima sesión larga. Eso no escala: cuanto más dura el proyecto, más cuesta reconstruir el contexto cada vez que la memoria no sobrevive al final de la conversación.
En una frase: el historial del chat es frágil por naturaleza — la memoria real del proyecto debe vivir fuera de la conversación.
📋 Qué poner en la memoria externa
🧠 Imagínalo así: es el manual de a bordo de un proyecto: no guarda cada conversación que hubo, sino solo lo que cualquier persona o agente nuevo tendría que saber para no repetir los mismos errores y decisiones.
El consejo 12 de la guía enumera lo que debe contener una memoria externa para el trabajo continuo: no es un historial sin procesar, sino lo esencial de lo que cambia la próxima decisión. Cada elemento de abajo es algo que puedes comprobar si ya está registrado o no en tu proyecto hoy.
Público objetivo
A quién atiende el proyecto y qué sabe o quiere esa persona.
Tono de comunicación
Cómo se comunica el proyecto, de manera formal o informal, y por qué.
Ofertas
Lo que se vende u ofrece en este momento.
Campañas que funcionaron
Qué ya se probó y dio resultado, y qué no funcionó.
Reglas técnicas
Restricciones, estándares e integraciones que no se pueden romper.
Decisiones estratégicas
Qué ya se decidió y no hace falta volver a plantear cada vez.
Errores recurrentes
Qué ya falló más de una vez y cómo evitar que vuelva a ocurrir.
Procesos de trabajo
Cómo se hacen las cosas aquí, paso a paso.
Prompts validados
Qué ya funcionó bien y se puede reutilizar.
Estándares de calidad
Qué diferencia lo «aceptable» de lo «realmente listo» en este proyecto.
En una frase: una buena memoria externa no guarda toda la conversación: guarda solo lo que cambia la próxima decisión.
🔗 El bucle que lee y escribe en la memoria en cada ciclo
🧠 Imagínalo así: un profesional con experiencia no vuelve a aprender el trabajo cada lunes: consulta sus propias notas antes de decidir y vuelve a anotar lo que aprendió antes de irse. Eso es exactamente lo que une ambos consejos.
Por sí solo, el ciclo de 7 pasos (recomendación 11) ya es mejor que "revisar de vez en cuando". Pero solo se convierte en un sistema de trabajo real cuando los pasos 2 y 7 apuntan a un lugar concreto: el paso 2 lee la memoria externa (recomendación 12) antes de analizar, y el paso 7 escribe en ella después de aprender algo. Sin ese vínculo, el ciclo reinicia el criterio en cada vuelta: exactamente el problema del tema 3.
🔗 Dónde el loop se conecta con la memoria
- •Paso 2 — analiza con base en los criterios ya guardados: 📖 lee el público objetivo, las reglas técnicas, los estándares de calidad y las decisiones ya tomadas.
- •Paso 6 — pídele al verificador que intente encontrar errores: 📖 lee los errores recurrentes ya registrados para no repetir el mismo fallo.
- •Paso 7 — registra la lección aprendida: ✍️ registra una entrada nueva (decisión/lección, por qué importa, dónde aplicarla, qué evitar, fecha).
Ejemplo combinado: revisando la incorporación de usuarios de un producto
- Elige un área pequeña: solo la pantalla de bienvenida del onboarding.
- 📖 lee en la memoria: tono de comunicación + estándar de calidad ya validado para esta pantalla.
- Propone: reemplazar un párrafo largo por 3 viñetas, siguiendo el tono guardado.
- Impleméntalo: es reversible (basta con deshacer el commit).
- Haz la prueba: 5 usuarios reales completan el onboarding; mide el tiempo hasta el primer clic.
- El verificador (otro agente/persona) intenta encontrar problemas: comprueba si algún punto eliminó información que cambiaba la decisión del usuario.
- ✍️ registra en la memoria: «las viñetas cortas redujeron un 20% el tiempo hasta el primer clic — aplicar al resto del onboarding. Fecha: hoy.»
En una frase: el ciclo sin memoria se reinicia cada vez; el ciclo que lee y escribe en la memoria acumula información: cada ciclo empieza siendo más inteligente que el anterior.
⚠️ Errores comunes de estos 2 consejos — lista de verificación rápida
🧠 Imagínalo así: una agenda que nadie actualiza es peor que no tener agenda: todos confían en ella creyendo que está al día. La memoria externa desactualizada tiene el mismo riesgo: parece una fuente de verdad, pero miente.
✓ Hacer
- ✓Mantén la memoria breve y destilada: solo lo que cambia la siguiente decisión.
- ✓Actualizar la nota existente en vez de duplicar la información nueva.
- ✓Definir siempre un área pequeña por ciclo del bucle.
- ✓Confirmar una prueba real antes de aceptar que «mejoró».
- ✓Dejar que quien verifica sea alguien o algo distinto de quien implementó.
- ✓Revisar la memoria de vez en cuando para quitar lo que quedó obsoleto.
✗ Evitar
- ✗Dejar que la memoria se convierta en un historial de chat pegado en un archivo (basura, no memoria).
- ✗Duplicar la misma decisión en tres archivos diferentes que divergen con el tiempo.
- ✗Ejecutar el ciclo en un área demasiado grande para abarcarla en un solo ciclo.
- ✗Aplicar un cambio «porque parece mejor», sin ejecutar una prueba.
- ✗Dejar que el mismo agente que implementó valide su propio trabajo.
- ✗Nunca vuelvas a consultar la memoria: también envejece.
En una frase: un loop sin memoria es sordo; la memoria sin loop está muerta: los dos consejos solo funcionan completos y juntos.
🧾 Resumen del Módulo
Próximo módulo:
2.7 — Bonus: el prompt maestro.