Loop Engineering for Product Managers

Puntos clave

1. Tesis central. la próxima competencia del PM no es la ingeniería de prompts sino Loop Engineering — "diseñar un sistema que mejora cada vez que se ejecuta," no escribir el prompt perfecto cada vez.
2. Definición de loop. un ciclo repetido — cambiar lo que moldea al agente → ejecutarlo → evaluar → conservar si la calidad sube / revertir en caso contrario → consolidar el aprendizaje para que la siguiente versión parta con ventaja.
3. El punto de entrada del PM = artefactos. (no código): skill de revisión de PRD, resumidor de llamadas con clientes, rúbrica de evaluación, checklist de lanzamiento, flujo de investigación, CLAUDE.md, plantilla de prompt, marco de priorización. Son duraderos, reutilizados y codifican criterio; moldean al agente a lo largo de decenas de ejecuciones.
4. Acumulación bidireccional. un buen artefacto afina el trabajo cada semana; uno malo lo ralentiza, silenciosamente. "Un prompt puntual te puedes permitir que salga mal. Una rúbrica de la que dependen diez personas, no."
5. El problema que el prompting no resuelve — el DRIFT. el CLAUDE.md no deja de crecer, la skill de revisión se endurece, el checklist se hincha hasta quedar medio ignorado, los criterios de evaluación cambian sin que nadie sepa cuándo ni por qué. Un mes después el agente "parece peor": "probablemente el modelo no empeoró. Tus artefactos derivaron, y nadie los estaba vigilando."
6. Anatomía de un loop — 5 partes. (1) disparador (cuándo empieza), (2) acción (qué hace el agente), (3) prueba (cómo se sabe que es mejor), (4) memoria (dónde se guarda el aprendizaje), (5) condición de parada (cuándo se detiene).
7. La condición de parada es la más crítica. (sobre todo en loops recursivos): muchos sistemas fallan no porque el modelo sea malo, sino porque el loop no tiene una salida limpia (scope creep, trabajo inventado, un resumen seguro de sí mismo sin ninguna prueba). Un buen loop de PM debe poder decir: nada cambió / el input es demasiado escaso / está bloqueado / no se alcanza el umbral de calidad / requiere una decisión humana. "Un loop que puede decir 'stop' es un loop que se puede dejar corriendo."
8. Las evals se convierten en trabajo del PM. no un benchmark gigante — se parte de ejemplos conocidos. Ej.: 3 PRD sólidos / 3 débiles → ¿el artefacto detecta las brechas reales sin quisquillosidad, preservando la intención?; 5 llamadas ya comprendidas → ¿capta el dolor real, cita con precisión, distingue la señal fuerte del ruido?; 2 lanzamientos pasados (1 limpio, 1 fallido) → ¿habría detectado lo que falló? Pregunta: "¿este artefacto mejoró frente al criterio de producto ya conocido?" (no "¿el agente parece inteligente?").
9. La capa de memoria = GitHub. no para convertir a los PM en ingenieros, sino por el historial de versiones de los artefactos. Contiene el artefacto, los cambios, los resultados de las evals, el registro de decisiones, la vía de rollback. "El repositorio se convierte en memoria de producto."
10. Primer loop recomendado — loop semanal de señal de producto. no empezar por la estrategia (demasiado amplia/subjetiva) sino por las product ops. Cada viernes: leer llamadas con clientes, tickets de soporte, notas de ventas, actualizaciones de experimentos, resúmenes de analítica, cambios publicados, escalamientos abiertos → producir un memo de señal de producto que separe la señal repetida del ruido aislado, cite al cliente textualmente, muestre qué cambió, señale la evidencia débil e indique qué supuestos del roadmap se reforzaron o debilitaron.
11. El criterio (taste) sigue siendo central pero necesita PRUEBA. cuando el juicio se traslada a artefactos reutilizables, hay que demostrar que un cambio realmente mejora las cosas (de lo contrario solo añade ruido o "ceremonia").
12. Límite humano. un loop puede resumir evidencia, revisar un PRD, señalar un lanzamiento arriesgado — no debe decidir la estrategia por sí solo, convertirse en el líder de producto, ni arbitrar sin contexto. "Construye el loop, pero sigue siendo el PM." Aumentar la autonomía lentamente, una vez ganada la confianza.
13. Citas y referencias. Boris (creador de Claude Code) "ya no escribe prompts, escribe loops que prompt-ean por él"; "La generación está resuelta… Solo quedan la verificación y el criterio"; Loop Library de Matthew Berman (loops reales de ingeniería/investigación/ops).
14. Vínculos fuertes. converge directamente con Compound Engineering ("cada unidad de trabajo facilita la siguiente," artefactos que se acumulan) y con la fase Compound del SDLC; resuena con Stack Overflow for Agents (capitalizar/verificar en lugar de regenerar) y con Monperrus / la doctrina verificación > generación. CLAUDE.md como artefacto vivo y versionado se conecta con la doctrina de Context Engineering.