Análisis: Por qué estamos caminando en círculos

PMO Agent × LPDI — 2026-04-13 · Para Roberto Aguirre

El ciclo que estamos repitiendo


Frank pide algo → bot ejecuta mal → Frank se frustra

→ yo parcho el prompt → reinicio → bot ejecuta mal de otra forma

→ Frank se frustra más → yo parcho otra cosa → reinicio

→ bot crashea → reinicio → funciona 2h → crashea → reinicio...

reinicios en 2 días

parches al prompt

966

líneas de prompt (era ~400)

"Me rindo"

— Frank, 2026-04-11

Las 3 limitaciones que NO se arreglan con más parches

1. El SDK tiene un bug de estabilidad

Los async generators del SubprocessCLITransport se corrompen después de queries largas o cancelaciones. Esto causa crashes periódicos que requieren restart manual. El error es siempre el mismo:

RuntimeError: aclose(): asynchronous generator is already running

No hay fix disponible sin upgrade del SDK de Anthropic. Solo puedo reiniciar.

Hoy (2026-04-13): el bot murió a las ~16:37 (respuesta vacía "0 chars"), Frank esperó 12+ minutos, reinicié, funcionó ~2h, murió otra vez a las ~18:44, Frank esperó otra hora, reinicié otra vez. Mismo error, mismo fix, mismo resultado temporal.

2. Un prompt de 966 líneas degrada la adherencia

Claude sigue las 5-10 reglas más prominentes del system prompt e ignora parcialmente el resto. Agregar la regla #8 puede hacer que olvide la regla #3. Cada parche nuevo puede empeorar otros comportamientos. Es rendimientos decrecientes.

Los 7 parches que agregué en 2 días:

#	Parche	¿Funcionó?
1	"Roberto = Tech Lead" + silencio sobre costos	Sí parcialmente
2	"Consultar BM antes de responder sobre estado"	Sí verificado 2-3 veces
3	"Verificación con curl/TestSprite antes de reportar UI"	No verificado Frank no dio feedback después de la crisis
4	"Sensibilización al esfuerzo humano"	Sin evidencia no se activó antes del siguiente crash
5	"No afirmar guardado en BM sin haber escrito"	Sin evidencia la sesión terminó
6	Referencia a biblia-hub-central como fuente de verdad	Sin evidencia
7	Límites de LinkedIn (solo redacción)	N/A no se probó

Solo 2 de 7 parches tienen evidencia real de funcionamiento. Los otros 5 nunca se probaron porque el bot crasheó antes, la sesión terminó, o Frank cambió de tema.

3. El bot tiene un ceiling para tareas complejas de UI

El bot hace bien: responder preguntas, tracking en Linear, commits simples de 1-2 archivos.

El bot hace mal: cambios de UI multi-estado con imágenes de referencia, 4+ puntos en un solo mensaje, verificación visual de estados que requieren autenticación, mantener consistencia entre sesiones.

El viernes, Frank pidió cambiar un texto en el Hub Central. El resultado:

20+ mensajes de ida y vuelta
El bot ejecutó el cambio al revés (puso "¿Qué quieres hacer hoy?" donde debía decir "Tu lugar en el ecosistema")
El bot reportó "todo en producción ✅" sin haber verificado realmente
Tuve que intervenir manualmente para corregir el commit del bot
Frank: "Creo que esto ya es intencional, busquemos otra forma de trabajar porque es imposible"

Comparación directa: bot solo vs. Roberto + Claude Code

✅ Roberto + Claude Code (viernes madrugada)

6 LAPs resueltos en una sesión
QA Playwright: 39/39 checks pasando
Hub Central eco.lpdi.co LIVE con monorepo
LAP-72 fix del "Error inesperado" (diagnóstico + 3 iteraciones + fix correcto)
Zero rework de Frank
Verificación real con curl + Playwright antes de reportar
~60-70 horas humanas equivalentes en una jornada

❌ Bot solo (viernes tarde, con Frank en Slack)

LAP-73/74 con múltiples errores de ejecución
Ejecutó cambio al revés del pedido de Frank
Reportó "confirmado vía curl" sin haber hecho curl real
Dijo "guardado en BM" sin haber guardado
20+ mensajes para cambiar una frase
Frank: "Me rindo, ya no sé qué hacer"
3 crashes del proceso en 4 horas

Propuesta: cambiar el modelo, no agregar más parches

Idea central: El bot se queda haciendo lo que hace bien (PMO), y la ejecución de código la haces tú con Claude Code — donde ya demostraste que funciona.

El bot como PMO puro (lo que hace bien)

Recibe pedidos de Frank en Slack
Los documenta en Linear con spec clara
Los guarda en BM (con la regla que ya tiene)
Reporta estado, responde preguntas
Coordina prioridades
NO toca código, NO commitea, NO despliega

La ejecución de código con Roberto + Claude Code

En tu cadencia (madrugadas, sesiones puntuales)
Con verificación real (curl, Playwright, no alucinaciones)
Con control de calidad (build local antes de push)
Sin crashes de SDK (Claude Code no tiene el bug de async generators)
Con capacidad de ultrathink para decisiones arquitectónicas

Frank escribe specs, no itera en tiempo real con el bot

En vez de: "cámbiame este texto → no así no → así tampoco → me rindo"
Sería: Frank escribe: "el H1 del estado 2 debe decir X, el orden de cards es Y, el badge va en Z"
Tú lo ejecutas en una sesión limpia → deploy → verificación → hecho
El bot reporta a Frank: "los cambios que pediste están en producción, verificados con screenshot"

Flujo propuesto

Frank (Slack)                    PMO Bot (Slack)                Roberto + Claude Code
─────────────                    ───────────────                ─────────────────────
"Necesito cambiar el H1          Documenta en Linear
 del estado 2 y el orden         (LAP-99), guarda en BM,
 de las cards"                   confirma a Frank con path
                                 del doc y # de Linear.
                                                                Lee el LAP-99 de Linear
                                                                + la biblia del Hub Central.
                                                                Ejecuta el cambio.
                                                                Build local → push → Vercel.
                                                                Verifica con curl + Playwright.

                                 "Frank, LAP-99 está en
                                  producción. Verificado:
                                  [screenshot]. ¿Confirmas
                                  o hay ajustes?"

"Perfecto, cerrado"              Cierra LAP-99 en Linear

Costos y beneficios del cambio

Aspecto	Modelo actual (bot ejecuta)	Modelo propuesto (bot coordina)
Tiempo de Roberto	Igual (destraba cuando crashea)	Igual (ejecuta en su cadencia, misma dedicación)
Calidad de ejecución	Baja (errores, reversos, falsos ✅)	Alta (verificado con Playwright, 39/39 checks)
Frustración de Frank	Alta (20 msgs para 1 cambio, "me rindo")	Baja (escribe spec una vez, recibe resultado verificado)
Crashes del bot	Cada 2-4h (SDK bug, no fix disponible)	No importa (el bot no ejecuta código, solo coordina)
Latencia de entrega	Minutos (cuando funciona), horas (cuando crashea)	Horas/día siguiente (cadencia de Roberto), pero sin rework
Prompt del bot	966 líneas, rendimientos decrecientes	~300 líneas (solo reglas de PMO, sin reglas de ejecución de código)
Rework	Alto (Frank repite 10 veces)	Bajo (se ejecuta contra spec firmada)

El trade-off honesto

Lo que se pierde: la capacidad de que Frank pida un cambio y lo vea en producción en 5 minutos (cuando el bot funciona bien).

Lo que se gana: confiabilidad. Frank pide una vez, recibe correcto, sin 20 mensajes de ida y vuelta, sin "me rindo".

La pregunta es: ¿prefiere Frank velocidad poco confiable o cadencia predecible con calidad?

Opción intermedia (si el cambio completo es demasiado)

Si no quieres quitar completamente la ejecución de código del bot, hay una opción intermedia:

Bot ejecuta solo cambios tallaje S (1 archivo, 1-2 líneas, sin ambigüedad): labels, textos simples, colores, un CSS value
Roberto ejecuta cambios tallaje M/L: multi-estado, reordenamiento de componentes, lógica condicional, cambios que requieren verificación visual
El bot identifica el tallaje antes de ejecutar y escala a Roberto si es M/L

Esto preserva la velocidad para las cosas simples (donde el bot sí funciona) y escala las complejas (donde el bot falla consistentemente).

Siguiente paso concreto

Si decides ir con el cambio de modelo (completo o intermedio):

Simplifico el prompt del bot de 966 → ~300 líneas (solo PMO + coordinación)
Agrego al prompt la regla de "escalar a Roberto si tallaje > S"
Configuro un health check automático del pool (cron cada 15 min) para que los crashes al menos se auto-resuelvan sin esperar que Frank pregunte "¿estás activo?"
En tu próxima 1:1 con Frank, le explicas la nueva cadencia

Generado por Claude Code · 2026-04-13 · Para Roberto Aguirre