Cada vez que un agente de programación termina una tarea, se abre la misma brecha. Recibes un diff y un alegre «listo», pero no qué cambió, qué se omitió, qué se probó ni sobre qué sigue teniendo dudas el agente. Así que vuelves a leer el diff, vuelves a ejecutar las pruebas por tu cuenta y vuelves a hacer preguntas que el agente podría haber respondido al entregar el trabajo. Si ejecutas dos agentes, ese coste se duplica. El problema no es el trabajo. Es el traspaso: qué se mueve entre quien pidió algo y el agente que lo hizo, y qué vuelve de vuelta.
Una plantilla de traspaso para agentes de programación es una estructura fija que define lo que lleva consigo una tarea cuando cambia de manos: de una persona a un agente en la asignación, y de un agente de vuelta a una persona en la revisión. En lugar de improvisar la forma de cada transferencia, rellenas los mismos campos cada vez. El agente sabe qué significa «hecho» antes de empezar, y tú recibes el mismo resumen, las mismas evidencias y las mismas preguntas abiertas cuando termina.
Este artículo repasa las dos plantillas que aguantan en la práctica, usando Sharkly como flujo de trabajo: la capa por encima de tus agentes de programación que mantiene visibles el contexto, el progreso, los bloqueos, los resultados y la revisión humana desde la solicitud hasta el despliegue. Ya tienes agentes de programación. Sharkly los convierte en un equipo, y la plantilla de traspaso es lo que hace que cada transferencia sea un registro en lugar de una suposición.
Qué es una plantilla de traspaso para agentes de programación
Una plantilla de traspaso es una checklist convertida en estructura. Responde a tres preguntas que un diff desnudo nunca responde: qué se pidió, qué ocurrió y a quién le toca ahora. Cuando esas tres cosas viajan juntas, el siguiente trabajador lee un solo registro en lugar de reconstruir tres.
Hay dos traspasos que merece la pena plantillar, porque van en direcciones opuestas y llevan cosas opuestas:
- Traspaso de asignación (de una persona o de un Agente líder a un Agente): el objetivo, los límites y la definición de hecho, entregados antes de que empiece el trabajo.
- Traspaso de revisión (de un Agente de vuelta a una persona): el cambio, la evidencia de que funciona y las partes que aún debe juzgar un humano, entregados cuando el trabajo se detiene.
Plantillar ambos es la clave. La mayoría de los equipos escribe un ticket aproximado y no plantilla nada a la vuelta, así que cada revisión empieza como un interrogatorio. Arreglar el viaje de vuelta es donde está el tiempo.
El modelo operativo que codifica la plantilla
Una plantilla vale tanto como el modelo operativo que tiene debajo. Cuatro verbos deciden quién es dueño de cada costura: quién asigna, quién ejecuta, quién revisa, quién acepta. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo.
Ese contrato es la razón por la que las dos plantillas llevan campos distintos. Un Agente nunca debería adivinar cómo es la aceptación, así que la plantilla de asignación obliga a quien pide a que lo escriba. Una persona nunca debería adivinar si el verde significa que es seguro, así que la plantilla de revisión obliga al Agente a mostrar su trabajo. Aquí está el traspaso de asignación como bloque para copiar y pegar:
## Assignment handoff
Task ID: SH-###
Goal: one sentence, in plain language
In scope: the specific files, endpoints, or behaviors to touch
Out of scope: what to leave alone (auth, billing, public contracts)
Definition of done:
- [ ] observable acceptance criterion 1
- [ ] observable acceptance criterion 2
Constraints: frameworks, patterns, or limits to respect
Assignee: the exact Agent that owns this
Las líneas de «out of scope» y «definition of done» son las que hacen el trabajo pesado. Sin ellas, un agente optimiza para un diff que pasa, no para el resultado que tenías en mente. Con ellas, la comprobación de aceptación está escrita antes de que exista una sola línea de código.
El traspaso de revisión: qué vuelve
La plantilla de vuelta es la que más flujos de trabajo se saltan, y la que te salva la tarde. Cuando un Agente termina, no debería avisarte con un «listo» y un enlace. Debería devolver una estructura rellena:
## Review handoff
Task ID: SH-###
Summary: what changed, in 2-3 sentences
Acceptance: each definition-of-done item, checked with how it was verified
Tests: typecheck / unit / build results, pasted or linked
Diff: the PR or worktree branch
Known limits: what this does NOT cover, and any risky assumption
Open questions: decisions left for a human
Los campos de «known limits» y «open questions» son lo que separa un traspaso real de un muro de marcas verdes. Un límite honesto («el contador de Redis asume una sola región») convierte un merge a ciegas en un merge informado. Es el mismo principio que hay detrás de revisar código generado por IA con evidencia a nivel de tarea: quien revisa lee una afirmación más su prueba, no un diff más una esperanza.
Un límite que conviene dejar claro: el traspaso de revisión no es una petición de merge. Es una petición de revisión. El Agente presenta; la persona decide. Mantener esos dos actos separados es lo que impide que se despliegue trabajo sin revisar.
Estados y puertas de revisión: dónde vive la plantilla
Una plantilla que vive en el búfer de desplazamiento de la terminal es una plantilla que nadie lee. El traspaso tiene que estar adjunto a algo compartido, y los estados son su hogar natural. Cada Tarea pasa por un único carril, y cada cambio de estado es un traspaso con su plantilla adjunta:
| Estado | Responsable | Plantilla adjunta |
|---|---|---|
| Todo | Persona o Agente líder | Traspaso de asignación |
| En progreso | Agente | (trabajando en un worktree aislado) |
| Listo para revisión | Agente | Traspaso de revisión |
| Hecho | Persona | nota de aceptación + decisión de merge |
La regla que hace esto legible: los Agentes mueven una Tarea a «Listo para revisión»; las Personas la mueven a «Hecho». Un Agente nunca marca su propio trabajo como Hecho, y una persona nunca tiene que reconstruir lo que pasó, porque el traspaso de revisión ya está en la Tarea. En Sharkly, la ejecución, los bloqueos, los resultados y la discusión de seguimiento vuelven a la línea temporal de la Tarea, así que cuando hay diez agentes en marcha lees el tablero, no diez terminales. Esa es la diferencia entre rastrear lo que completaron los agentes y esperar que un registro de commits lo explique después. Dónde debe detenerse el trabajo autónomo es en sí mismo una decisión de diseño, que se trata en dónde colocar las puertas de aprobación.
Un ejemplo práctico: de ticket a PR fusionado
Tomemos una Tarea con forma real, SH-441: «Añadir exportación a CSV a la página de informes». Fíjate en cómo se rellenan las plantillas, no en el código.
Una persona abre SH-441 y un Agente líder completa el traspaso de asignación: objetivo («permitir a los usuarios descargar el informe actual como CSV»), dentro del alcance (el controlador de informes y un módulo de exportación nuevo), fuera del alcance (auth, las consultas de informes existentes) y una definición de hecho con tres elementos comprobables (un botón de descarga, el escape correcto de comas y comillas, una prueba con un fixture de 10 000 filas). El Assignee es un Agente de backend. Nada es ambiguo, porque la plantilla no permitió que lo fuera.
El Agente de backend reclama la Tarea, trabaja en un worktree aislado para no chocar nunca con otro trabajo, y ejecuta los elementos de la definición de hecho como su propia checklist. Cuando el typecheck, las pruebas unitarias y la build están en verde, mueve SH-441 a «Listo para revisión» con la plantilla de vuelta rellena: un resumen breve, cada elemento de aceptación marcado con cómo se verificó, el diff y un límite conocido («las exportaciones de más de 100 000 filas se almacenan en memoria; el streaming no está implementado»).
Ahora el traspaso cambia de dirección. Una persona lee un solo registro, no un búfer de terminal. Confirma la prueba de escape, sopesa el límite de memoria frente a los tamaños reales de los informes, lo acepta por ahora y mueve SH-441 a «Hecho», lo que dispara el merge. De ticket a PR fusionado, con una plantilla rellena en ambas costuras y un registro de quién era responsable de cada una. Este es el camino de requisitos a código hecho trazable de principio a fin.
Cuándo una plantilla es excesiva
Las plantillas tienen un coste, así que aquí está el par de decisiones honestas. Sáltate la plantilla completa para trabajo pequeño y bien definido que un Agente termina en una sola pasada, donde el objetivo y la aceptación son obvios por el título de la Tarea. Recurre a ella en el momento en que el trabajo cruza una costura que importa: varios agentes sobre un mismo objetivo, un cambio en un contrato público o cualquier cosa que toque auth, facturación o datos que no puedas retirar fácilmente. Una plantilla es un seguro contra el contexto perdido, y contratas el seguro donde una pérdida dolería.
Puedes llevar todo esto a mano con un tablero compartido y disciplina. Funciona hasta que el número de agentes, tareas y repositorios sube y la disciplina es lo primero que se pierde. Si ya ejecutas varios agentes, Sharkly te da un único lugar para gestionar sus tareas y resultados: Tareas compartidas que llevan los traspasos de asignación y revisión, Assignees por Tarea, worktrees aislados y un carril de estados donde los Agentes llegan a «Listo para revisión» y las Personas deciden «Hecho». Conserva los agentes de programación que ya usas. Descarga Sharkly cuando las costuras entre ellos empiecen a costar más que el trabajo.
Preguntas frecuentes
¿Qué es una plantilla de traspaso para agentes de programación? Es una estructura fija que define lo que lleva consigo una tarea cuando cambia de manos. Hay dos: un traspaso de asignación (objetivo, alcance y definición de hecho, de una persona a un Agente) y un traspaso de revisión (resumen, evidencia y límites conocidos, de un Agente de vuelta a una persona). Rellenar los mismos campos cada vez es lo que evita que el contexto se evapore entre trabajadores.
¿Por qué plantillar el viaje de vuelta y no solo el ticket? La mayoría de los equipos escribe un ticket y no plantilla nada a la vuelta, así que cada revisión empieza como un interrogatorio. El traspaso de revisión, con su resumen, sus elementos de aceptación marcados y sus límites conocidos, es donde una plantilla ahorra más tiempo. Consulta agentes de programación con humano en el bucle.
¿Debería un agente marcar su propio trabajo como hecho? No. Deja que un Agente mueva una Tarea a «Listo para revisión» con la plantilla de vuelta rellena; deja el paso a «Hecho», y la decisión de merge, a una persona. Separar «presentado» de «aceptado» es lo que impide que se despliegue código sin revisar.
¿Dónde debería vivir la plantilla? En una Tarea compartida, adjunta a un cambio de estado, no en una terminal que solo vio un agente. Cuando el traspaso es un estado con su plantilla adjunta, el siguiente trabajador ve exactamente qué le está esperando. Esto también evita que la revisión se convierta en el cuello de botella cuando muchos agentes terminan a la vez.
¿Necesito una herramienta para esto o puedo hacerlo manualmente? Puedes llevarlo con un tablero compartido y disciplina. Una capa dedicada compensa una vez que coordinas varios agentes en varios repositorios y el seguimiento manual se convierte en el trabajo. Compárala con un gestor de tareas de IA para trabajo de agentes de propósito general.
