Por qué el chat y los tickets tradicionales no bastan cuando trabajas con agentes de IA
Le pediste a tu agente «añade paginación al listado de usuarios». Volvió con la paginación hecha… y de paso te cambió el formato de dos endpoints que ya funcionaban, porque «así quedaba más consistente». Nadie se lo pidió. Nadie se lo prohibió tampoco.
Si trabajas con Cursor, Claude, Aider o Windsurf en un proyecto real, la escena te suena. Y la conclusión fácil —«el agente se equivocó»— es la equivocada. El agente hizo lo único que podía hacer con lo que tenía: rellenar los huecos. El problema no fue el agente. Fue que no había ninguna fuente de verdad que le dijera qué estaba dentro del alcance y qué no.
En el primer artículo hablamos de por qué los agentes fallan cuando las tareas no están claras. Aquí vamos un paso más allá: aunque tengas tareas, si viven en el sitio equivocado —un chat interminable o un ticket ambiguo—, el agente sigue trabajando a ciegas.
Cómo gestionamos los proyectos hoy, con agentes dentro
Antes de los agentes, el «sistema» de mucha gente era una mezcla razonable: algo de conversación (Slack, el chat del editor), algo de tickets (Linear, GitHub Issues, Plane, Height) y bastante memoria humana. Funcionaba porque el pegamento eras tú. Tú recordabas por qué se decidió aquello, tú sabías que ese ticket en realidad dependía de otro, tú traducías «arréglalo» en cinco pasos concretos.
Cuando metes un agente en la ecuación, ese pegamento desaparece. El agente no estaba en la llamada de ayer. No leyó el hilo donde decidisteis no tocar el módulo de pagos. No sabe que «el bug del login» ya se discutió tres veces. Tú le das una frase y un editor con acceso al código, y esperas que se comporte como un compañero con seis meses de contexto. No los tiene.
Y aquí está el punto incómodo: el agente trabaja mucho más rápido que tú revisando. Puede tocar quince archivos en el tiempo que tardas en leer un diff. Así que cualquier hueco de contexto no produce un error pequeño y contenido: produce trabajo amplio, rápido y desalineado que luego hay que deshacer.
Por qué el chat no es suficiente
El chat es genial para pensar en voz alta. Es pésimo para gobernar un proyecto. Con un agente delante, esa diferencia deja de ser un detalle y se convierte en el problema.
El contexto se diluye
Una conversación es lineal y efímera. Lo que dijiste hace veinte mensajes ya no está «activo»: está enterrado. Los agentes, en cambio, necesitan contexto estable, no conversaciones fluidas. Un hilo de chat es justo lo contrario de estable: cada mensaje nuevo empuja al anterior hacia el olvido, y la ventana de contexto del modelo tiene un límite. Le pegas medio hilo, el agente se queda con la mitad de la mitad, y rellena el resto por su cuenta.
Las decisiones importantes se entierran
Piensa en las decisiones reales de un proyecto: «usamos UUIDs, no autoincrementales», «los correos se envían fire-and-forget», «no tocamos la API pública sin versionar». Esas decisiones casi nunca viven en un sitio estable. Viven en un mensaje suelto, en un comentario de una PR, en la cabeza de quien lo decidió. En un chat, una decisión crítica y un «¿alguien ha comido?» tienen exactamente el mismo peso visual y la misma esperanza de vida.
Cuando el agente necesita esa decisión, no la encuentra —porque no está en ningún sitio consultable—. Así que decide por su cuenta. Y a veces decide distinto cada vez.
No hay estado, solo mensajes
Un chat no tiene estado. No puedes preguntarle «¿qué está en curso?», «¿qué quedó bloqueado?», «¿esto ya se hizo?». Solo puedes hacer scroll. Para una persona es incómodo; para un agente es inservible: no hay forma de que un modelo «recuerde» el estado del proyecto leyendo un río de mensajes. Los agentes no pueden recordar el estado del proyecto si no existe una fuente que lo represente.
Por qué los tickets tradicionales tampoco bastan
«Vale —dirás—, por eso existen los gestores de tareas.» Y sí: Linear, GitHub Issues, Plane o Height son un salto enorme frente al chat. Tienen estado, asignación, historial. Pero se diseñaron para un mundo donde quien lee el ticket es una persona. Y una persona rellena los huecos con criterio; un agente los rellena con estadística.
El ticket asume un lector humano
Un título como «Mejorar el rendimiento del dashboard» es perfectamente accionable… para alguien que lleva meses en el proyecto. Sabe qué dashboard, qué significa «lento», qué es aceptable y qué no hay que tocar. El agente no sabe nada de eso. Ve seis palabras y un cuadro de descripción medio vacío. La ambigüedad que un humano resuelve con contexto, el agente la resuelve inventando.
Falta estructura que un agente pueda seguir
Los tickets tradicionales guardan bien el «qué» y casi nada del resto: qué está hecho ya, qué depende de qué, qué queda fuera de alcance, cómo se valida el resultado, qué decisiones aplican. Esa información —cuando existe— está desperdigada entre la descripción, los comentarios, las etiquetas y tres PRs enlazadas. Es información dispersa, no una fuente de verdad. Para ti, reconstruirla cuesta un rato. Para un agente, que no puede «darse una vuelta por el proyecto» ni preguntar en el pasillo, es sencillamente inaccesible.
Siguen dependiendo de ti
El resultado práctico es que el gestor de tareas clásico no elimina tu trabajo de traducción: lo esconde. Sigues teniendo que estar tú en medio, explicando en el chat lo que el ticket no dice, recordando la decisión que no está escrita, avisando de la dependencia que nadie modeló. El agente no trabaja contra el proyecto: trabaja contra tu disponibilidad.
El coste real de esta brecha
Esta distancia entre «cómo guardamos la información» y «qué necesita un agente» no es teórica. Se paga, y se paga en sitios muy concretos:
- El tiempo no baja. Prometían acelerarte, y acabas invirtiendo el rato ganado en re-explicar el mismo contexto en cada sesión, desde cero.
- Agentes que improvisan. Sin límites claros, el agente «mejora» cosas que nadie quería tocar, duplica lógica que ya existía o resuelve el problema equivocado con mucha seguridad.
- Retrabajo silencioso. El cambio parece correcto, pasa la revisión rápida, y dos días después descubres que rompió una asunción que vivía en la cabeza de otra persona.
- Cero trazabilidad. Cuando algo sale mal, no hay forma de reconstruir por qué el agente hizo lo que hizo. La decisión no quedó registrada, el contexto no estaba enlazado, el estado no se reflejó. Solo queda el diff.
Ninguno de estos costes viene de que el modelo sea malo. Vienen de pedirle a un agente que opere sin una fuente de verdad y luego sorprendernos de que se invente una.
La idea clave: las tareas y épicas como única fuente de verdad
Aquí está el cambio de marco. Si quieres que un agente trabaje bien, el proyecto necesita un único lugar donde vive la verdad: qué hay que hacer, en qué estado está, qué depende de qué, qué se decidió y qué queda fuera. No repartido entre un chat, tres tickets y tu memoria. Uno.
La unidad natural de esa fuente de verdad no es el mensaje ni el documento suelto: es la tarea, agrupada en épicas, dentro de proyectos. Una tarea bien formada no es un título; es un contrato pequeño y estable: el objetivo, el alcance, lo que queda fuera, las dependencias y cómo se valida. Una épica da la foto grande: qué estáis construyendo y cómo encajan las piezas.
La diferencia entre información dispersa y fuente de verdad es precisamente esa. No es cuánta información tienes, es si existe un sitio consultable, estructurado y estable al que tanto tú como el agente podéis acudir y obtener la misma respuesta. Un chat tiene mucha información y ninguna verdad. Una fuente de verdad tiene menos ruido y una respuesta clara.
Qué cambia cuando el agente tiene una estructura real
Cuando el agente puede leer esa estructura en vez de adivinarla, el trabajo cambia de carácter:
- Deja de rellenar huecos. Trabaja sobre una unidad concreta con un alcance definido, así que no «mejora» lo que no debía tocar.
- Decide de forma consistente. Las decisiones del proyecto están escritas y son consultables, no reinventadas en cada sesión.
- El estado es real. «Hecho», «en curso» y «bloqueado» significan algo, y tanto tú como el agente podéis fiaros de ello sin hacer arqueología en un hilo.
- Hay rastro. Cada cosa tiene su sitio, así que cuando algo se tuerce puedes reconstruir el qué y el porqué.
- Dejas de ser el pegamento. El contexto no depende de que estés disponible para explicarlo: vive en el proyecto.
Fíjate en lo que no hemos dicho: nada de «el agente se vuelve autónomo y ya no revisas». Al contrario. Una fuente de verdad no elimina el control humano; lo hace barato. Revisar contra un alcance escrito es rápido. Revisar contra «lo que yo tenía en la cabeza» es agotador.
Dónde entra Hilbana
Hilbana nace justo de esta idea: que las tareas, épicas y proyectos sean la fuente de verdad que tus agentes pueden seguir sin perderse. No un chat que se diluye, no un ticket que da por hecho un lector humano con seis meses de contexto. Una estructura pensada desde el principio para que personas y agentes lean lo mismo, con las mismas reglas.
No vamos a entrar hoy en cómo lo hace pieza por pieza —eso es para los próximos artículos—. El posicionamiento de hoy es más simple y, creemos, más importante: el cuello de botella cuando trabajas con agentes no es el modelo, es el soporte sobre el que le pides que trabaje. Y ese soporte, hoy, sigue siendo un chat que olvida o un gestor de tareas que solo habla el idioma de los humanos.
Si tu proyecto tuviera una fuente de verdad de verdad —estable, estructurada y consultable por una persona y por un agente—, la mitad de los problemas de los que hemos hablado dejarían de ocurrir. Ese es el hueco que Hilbana quiere ocupar.
¿Quieres empezar a trabajar así con tus agentes?
Crea una cuenta gratis y prueba Hilbana con un proyecto agent-ready.
O, si prefieres entender primero cómo funciona: