Arrancas tres agentes de programación con tres tareas y luego pasas los siguientes veinte minutos saltando entre pestañas de la terminal intentando responder a una sola pregunta: ¿cuál me necesita ahora mismo? Uno sigue en ejecución. Otro está esperando un y/n que nunca viste. Un tercero terminó en verde hace una hora y, sin hacer ruido, construyó lo que no era. Nada te avisó de nada de eso. Tuviste que ir a buscarlo.
Esa brecha es la que se supone que cierra la observabilidad de los agentes de programación. La observabilidad, tomada de la ingeniería de sistemas, es la capacidad de entender qué está haciendo un proceso en ejecución a partir de las señales que emite, sin conectarse a él directamente (OpenTelemetry tiene una buena introducción). Para los agentes de programación el listón es este: deberías poder responder «qué está haciendo cada agente, qué ha fallado y qué necesita a una persona» desde una vista compartida, y no haciendo tail de una sesión. La mayoría de las configuraciones no lo consiguen. Tienen un estado por ahí y un log por otro lado, y a eso lo llaman observabilidad. No lo es.
Este artículo repasa las tres señales que un agente de programación emite de verdad, qué señales de fallo merecen que les conectes una alerta y dónde una capa de tareas compartida como Sharkly convierte la salida en bruto en algo sobre lo que puedes actuar. Sharkly se sitúa por encima de los agentes que ya ejecutas; ya tienes agentes de programación, y de lo que se trata aquí es de hacer legible su trabajo cuando hay más de uno.
Estado, logs y señales de fallo son tres cosas distintas
Estas tres palabras se usan como sinónimos, y esa confusión está en la raíz de la mayoría de las malas configuraciones de monitorización. Responden a preguntas distintas.
El estado es la situación resumida de una ejecución. En ejecución, esperando entrada, terminada o fallida. Es un solo campo, barato de leer, y te dice dónde está una ejecución, no qué hizo. Un estado no es observabilidad; es el dato más pequeño sobre una ejecución.
Los logs son el rastro de ejecución en bruto. Cada llamada a una herramienta, cada edición de archivo y cada respuesta del modelo, en orden. Los logs te cuentan qué pasó después de que ya sabes que algo fue mal. Son indispensables para un análisis post-mortem e inútiles como señal en vivo, porque nadie vigila cinco logs desplazándose a la vez. Un log no es una señal hasta que algo extrae significado de él.
Las señales de fallo son alertas derivadas. Son las condiciones concretas que merecen interrumpirte: un agente atascado, una ejecución que terminó en verde yendo en la dirección equivocada, un presupuesto que se agotó a mitad de tarea. Una señal de fallo es lo que realmente quieres, y es la capa que casi todas las configuraciones hechas a mano se saltan, porque derivarla significa procesar los logs para convertirlos en eventos en lugar de solo almacenarlos.
La trampa está en quedarse con las dos primeras. Estado más logs parece observabilidad porque tienes un estado y un registro. Pero la única pregunta que escala, «¿cuál de mis agentes me necesita?», vive por completo en la tercera capa.
Las señales de fallo que realmente importan
La observabilidad de servicios web vigila caídas y latencia. Los agentes de programación fallan de otra manera, y los fallos que te cuestan una tarde rara vez son los que aparecen como un estado en rojo. Estas son las señales que merece la pena derivar.
| Señal | Qué significa | Por qué el estado y los logs no lo detectan |
|---|---|---|
| Bloqueo silencioso | El agente está esperando un prompt o un secreto ausente, sin producir salida | El estado sigue marcando «en ejecución»; nada levanta la mano |
| Verde pero equivocado | La ejecución terminó con éxito e hizo lo que no era | El estado es «terminada»; solo leyendo el diff se descubre |
| Verificación omitida | Se reportó como terminado sin ejecutar typecheck, tests o el build | Los logs contienen la omisión, pero nadie lee un log que pasó |
| Agotamiento del presupuesto | Se alcanzó la cuota del modelo o el límite de gasto a mitad de una tarea | El fallo aparece como una respuesta truncada, no como una alerta |
| Conflicto latente | Dos agentes editaron los mismos archivos en worktrees separados | Ambas ejecuciones están «terminadas»; la colisión espera en el merge |
| Thrash | El agente edita, revierte y vuelve a editar el mismo archivo en bucle | Cada paso individual parece correcto en el log |
El patrón en las seis: el fallo es invisible en la capa de estado y queda enterrado en la capa de logs. «Verde pero equivocado» es la que más se subestima. Un agente de programación que termina con toda seguridad la tarea equivocada se ve idéntico a uno que la clavó, hasta que la revisión con evidencia a nivel de tarea lo detecta. Una observabilidad que solo informa de códigos de salida reportará ese fallo como un éxito.
Dos de estas son estructurales y no de comportamiento. Los conflictos latentes son el motivo por el que el trabajo en paralelo sobre el mismo repositorio necesita worktrees aislados por tarea, para que los solapamientos de archivos salgan a la luz antes del merge y no durante él. El agotamiento del presupuesto es el motivo por el que hacer seguimiento del gasto entre agentes pertenece a la misma vista que el estado; una ejecución que se detuvo sin hacer ruido porque se quedó sin cuota es una señal de fallo, no una tarea completada.
Cuánta observabilidad necesitas, según el tamaño del equipo
No necesitas las seis señales desde el primer día. La cantidad adecuada de instrumentación escala con cuántos agentes se ejecutan y cuántas personas necesitan verlos.
| Configuración | Qué instrumentar | Dónde se rompe |
|---|---|---|
| Un agente, una tarea | Solo el estado; lee el log si falla | Nada, hasta que arrancas un segundo agente |
| Varios agentes en solitario | Estado por ejecución más señales de bloqueo y de verde pero equivocado | Infieres el estado a partir del silencio y te pierdes los bloqueos |
| Equipo pequeño, repositorios compartidos | Las seis señales, más el estado de revisión, en una vista compartida | Tu monitorización vive en un portátil que nadie más puede ver |
| Equipo más grande, muchos repositorios | Lo anterior más la propiedad por ejecución, el presupuesto y la pista de auditoría | Nadie puede responder «quién ejecutó qué» una semana después |
La lectura honesta: un desarrollador en solitario que ejecuta un agente en trabajo no relacionado tiene toda la observabilidad que necesita en una sola terminal. La ecuación cambia en el momento en que los agentes superan en número a tus pantallas, el trabajo se ejecuta en máquinas en las que no estás sentado o otra persona necesita ver el mismo tablero. Pasada esa línea, un campo de estado y un directorio de logs dejan de ser suficientes.
Cuándo bastan los logs sin procesar y un único runtime
Dale a las herramientas integradas su mejor versión, porque para mucho trabajo ganan. Claude Code y Codex mantienen un rastro de sesión legible, y para un solo agente en una sola tarea ese rastro es tu observabilidad. Tú lo arrancaste, lo estás vigilando y leerás el log si se detiene. Añadir ahí una capa de gestión es pura sobrecarga.
Usa la salida del propio runtime cuando ejecutas uno o dos agentes, en trabajo no relacionado, que nunca pasan la tarea a nadie más. Echa mano de una capa de observabilidad compartida cuando las ejecuciones superan tu capacidad de atención, cuando se ejecutan en algún sitio donde no puedes hacer tail o cuando la revisión tiene que convertirse en una actividad de equipo y no en algo privado. Ese último caso es el asesino silencioso: que cinco agentes terminen en paralelo no es una victoria si revisar sus diffs vuelve a serializarse en una cola de una sola persona. Los agentes fueron más rápidos; tú fuiste más lento. Eso también es un problema de observabilidad, y ningún runtime individual lo resuelve, porque la señal que importa, «esta ejecución ha terminado y espera tu revisión», vive entre agentes, no dentro de uno.
Observabilidad cuando los resultados vuelven a la Task
Una capa de tareas cambia la unidad de observabilidad: pasa de «un proceso en un panel» a «una Task con un estado». Este es el cambio en torno al cual está construido Sharkly, y encaja con las tres señales a la vez.
Cada ejecución de agente se asocia a una Task. El estado, el progreso, los bloqueos y los resultados vuelven a la línea de tiempo de esa Task en lugar de vivir en un log que solo tú puedes ver. Las señales de fallo afloran en un solo sitio: las ejecuciones que necesitan a una persona llegan al Inbox, así que la pregunta deja de ser «¿terminó algo?» y pasa a ser «esto es lo que necesita mi decisión». 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.
El límite importa, porque es fácil asumir mal. Sharkly no ejecuta el agente ni escribe el código. Claude Code, Codex y los demás runtimes que ya usas siguen haciendo la ejecución. Sharkly añade la capa compartida de tareas, Computer, contexto y revisión a su alrededor, de modo que el contexto, el progreso, los bloqueos, los resultados y la revisión humana se mantienen visibles desde la petición hasta la entrega. Para ver el cuadro completo de lo que debería mostrar ese tablero compartido, consulta qué necesita de verdad un panel de agentes de programación con IA, y para el ángulo de la monitorización en vivo, cómo monitorizar agentes de programación que se ejecutan en paralelo.
Si quieres seguir usando varios agentes de programación en lugar de comprometerte con un solo ecosistema, esa vista compartida y centrada en las señales es el problema en torno al cual está diseñado Sharkly. Puedes ejecutar tus agentes de programación actuales a través de Sharkly y conservar todos los runtimes que ya usas.
Preguntas frecuentes
¿La observabilidad de los agentes de programación es lo mismo que el logging? No. El logging almacena lo que pasó. La observabilidad es ser capaz de responder qué está haciendo cada agente, qué falló y qué te necesita, sin leer esos logs uno a uno. Los logs son una entrada de la observabilidad, no su totalidad.
¿Cuál es la señal de fallo más importante que instrumentar primero? El bloqueo silencioso. Un agente que marca «en ejecución» mientras espera para siempre un prompt que nunca viste es la forma más común de que el trabajo en paralelo muera sin hacer ruido. Haz que las ejecuciones bloqueadas levanten la mano antes de ir a por algo más sofisticado.
¿Puedo obtener esto a partir de la salida integrada de mi agente de programación? Para un agente, sí. El propio rastro de sesión del runtime es suficiente. La salida integrada no tiene una vista entre agentes, así que no puede decirte cuál de cinco ejecuciones te necesita, que es exactamente la pregunta que aparece en cuanto pasas de una.
