Hay una escena en Edge of Tomorrow donde Rita muere, vuelve, corrige un paso, muere otra vez, y así hasta que el pasillo entero sale bien. El patrón Rita Vrataski Loop toma ese bucle como metáfora operativa: un humano y un agente de IA iteran sobre el mismo backlog, cada uno corrigiendo lo que el otro dejó a medias, hasta que el ticket cierra.
La diferencia con otras ideas parecidas es dónde vive la autoridad. Aquí no manda el repo, ni el agente, ni un prompt maestro: manda el PM tool. En la implementación de referencia, joa23/linear-cli, ese árbitro es Linear.
No es un framework base. Es una capa de gobierno. Este post es para colegas que están evaluando sin ganas de instalar nada todavía.
Qué hace realmente
El patrón define tres cosas:
- Una fuente de verdad compartida: el board de Linear. Ni el agente ni el humano tocan tickets que no existan ahí.
- Un loop de trabajo explícito: el agente toma el ticket de mayor prioridad en “To Do”, lo mueve a “In Progress”, implementa, abre PR, y lo pasa a “Done” cuando merge.
- Puntos de control humanos: priorización, etiquetas, bloqueos, review de PR. El humano no escribe código — o escribe poco — pero sí decide qué se hace y qué no.
Conviene distinguirlo de dos vecinos cercanos:
- Ralph Loop es 100% autónomo. Arranca con contexto fresco cada iteración, usa el filesystem como memoria, y nadie lo mira hasta que el commit aparece. Es para cuando quieres que la máquina se las arregle sola.
- Superpowers (y similares) son herramientas personales. Mejoran tu sesión, no el flujo del equipo.
Rita Vrataski se sitúa en medio: agente activo, pero humano en el asiento de gobierno. La sesión de Claude se mantiene viva entre iteraciones, así que el contexto no se evapora entre un ticket y el siguiente.
Cómo funciona por dentro
El flujo real, cuando lo llevas a práctica, se parece a esto:
linear-cli issues --status="To Do" --assignee=@me
→ el agente elige el de mayor prioridad
linear-cli move <id> "In Progress"
→ trabajo (código, tests, lo que sea)
→ PR con el ID del issue en el título
linear-cli move <id> "In Review"
→ humano revisa, comenta, aprueba
linear-cli move <id> "Done"
El binario linear-cli no hace nada mágico: es un wrapper sobre la API de Linear pensado para que un agente lo llame sin friccion (subcomandos estables, output parseable, auth por env). Lo que aporta es que el agente pueda operar el board como lo haría un humano, sin que tengas que montar una integración MCP o escribirte un adapter cada vez.
El humano, en paralelo, trabaja sobre el mismo board: crea tickets, los re-prioriza, bloquea los que requieren decisión, comenta PRs. No hay dos colas. No hay un “backlog del agente” separado. Si está en Linear, es del equipo.
Esa simetría es lo que convierte el patrón en algo útil en lugar de en otra demo. El día que el humano bloquea un ticket porque quiere discutirlo en el standup, el agente ya no lo toca — y nadie tuvo que escribir una regla nueva para eso.
Pros
- Governance real, no cosmética. Linear no es un dashboard de observación: es el mecanismo que decide qué se hace. Si no está en el board, no existe.
- Trazabilidad barata. Cada cambio queda amarrado a un issue, y cada issue tiene autor, fecha, discusión, labels. Auditar el trabajo del agente es auditar tu backlog.
- No requiere rip-and-replace. Si tu equipo ya usa Linear, la curva es de una tarde. No hay que adoptar un framework, reescribir el repo, ni inventar una taxonomía de carpetas.
- Equipos híbridos de verdad. El humano y el agente trabajan del mismo tablero con las mismas reglas. Eso baja mucho la fricción política de “¿y esto quién lo hizo?”.
- Contexto persistente. Al mantener la sesión viva entre iteraciones, el agente no reaprende el repo cada vez. En proyectos grandes, eso ahorra tokens y evita que se repita a sí mismo.
Contras
- Acoplamiento duro a Linear. Si usas Jira, Notion, GitHub Issues o Gitea, esto no es para ti tal cual. Habría que reescribir la capa CLI contra otro backend, y en ese momento ya no estás adoptando un patrón, estás construyendo uno.
- Overhead si no vives en Linear. Adoptar un PM tool solo para habilitar el loop es poner el carro delante del caballo. El patrón brilla cuando Linear ya era parte del flujo.
- Madurez limitada. 117 estrellas, 15 forks. Es nicho. La comunidad es pequeña y los issues que encuentres los vas a resolver tú.
- Sin TDD ni guardrails integrados. El loop confía en que el humano revise el PR. Si tu equipo no tiene esa disciplina, el patrón no te la va a imponer.
- Dependencia de que Linear siga con API abierta y pricing razonable. Riesgo de plataforma estándar — el mismo que tienes ya si montaste el equipo encima.
Cuándo sí, cuándo no
Sí si tu equipo ya usa Linear como PM tool y quieres experimentar con agentes que operen dentro de tu flujo existente en lugar de en un carril paralelo. También si te importa la trazabilidad — auditoría, compliance, postmortems — y no quieres inventarte un registro alternativo para lo que hace el agente.
No si usas Jira, Notion, Asana, GitHub Issues, Gitea o cualquier otra cosa que no sea Linear: la implementación de referencia no te sirve y reescribirla es un proyecto en sí. Tampoco si tu caso de uso es un agente autónomo sin humano en el loop — ahí Ralph u otros son mejor fit. Y no si estás empezando: este patrón asume que el equipo ya opera con tickets, prioridades y revisión de PRs. Si eso no existe, el agente solo va a amplificar el caos.
Veredicto
Opcional. No es stack base, es una capa de governance sobre un stack que ya tengas. Si Linear ya es tu PM tool y quieres empezar a meter agentes sin convertir el backlog en dos colas separadas, vale una tarde de experimento — probablemente con un proyecto pequeño, un par de tickets bien definidos, y mucho ojo en el primer PR.
Si no usas Linear, la lección que te llevas no es el repo: es la idea de que el PM tool sea el árbitro. Eso lo puedes replicar con cualquier backend que tenga una API decente y un CLI estable. El patrón importa; la herramienta es un detalle de implementación.
TL;DR — humano y agente al mismo board, Linear decide el orden, el PR cierra el issue. Útil si ya vives en Linear, ruido si no.