SaaS · Ingeniería · En evolución · CTO + Arquitectura · 23 julio 2026
Un asistente que lleva la petición de Slack a producción
De una idea escrita en Slack a la funcionalidad desplegada: el asistente crea el ticket en Jira, la documentación en Confluence, desarrolla y despliega.
Arquitectura
El problema: las peticiones de desarrollo se pierden entre Slack y la memoria de alguien
En una empresa de software real, las peticiones no llegan como tickets limpios: llegan como mensajes en Slack. "¿Podemos hacer que…?", un audio, una captura. Y ahí empieza el desorden: alguien lo tiene que convertir en ticket, alguien lo tiene que documentar, alguien lo tiene que desarrollar y alguien lo tiene que desplegar — y cada salto pierde contexto.
El resultado típico: features que viven solo en la cabeza de quien las pidió, tickets sin documentación, y desarrollos que nadie sabe muy bien por qué se hicieron.
La decisión: un asistente que sea dueño del hilo, de la idea al deploy
En vez de sumar pasos manuales, montar un asistente que acompañe la petición de punta a punta: que la recoja en Slack, la formalice en Jira, la documente en Confluence como documentación de producto, ayude a desarrollarla y la lleve hasta el despliegue — dejando rastro en cada paso. La persona decide y revisa; el asistente hace el trabajo de coser el flujo.
Qué construí: el ciclo completo, cosido
- Entrada por Slack: la petición se recoge en el canal donde de verdad ocurre, con su contexto (texto, audios transcritos, capturas leídas).
- Ticket en Jira creado con el método y las convenciones de la empresa, no un ticket genérico.
- Documentación de producto en Confluence, para que la funcionalidad quede explicada, no solo hecha.
- Desarrollo asistido por agentes: parte del código lo escriben, corrigen y prueban agentes, con la persona validando.
- Despliegue a producción vía CI/CD, con verificación — cerrando el círculo desde "lo pidió alguien en un canal" hasta "está desplegado y documentado".
Resultado: de una frase en un canal a una funcionalidad viva y explicada
- El ciclo petición → Jira + Confluence → desarrollo → deploy deja de depender de que cada persona recuerde su parte.
- Cada desarrollo nace documentado: ticket + doc de producto, sin un paso manual extra de "acuérdate de escribirlo".
- El conocimiento deja de vivir en la cabeza de quien pidió la feature y pasa a estar donde cualquiera puede consultarlo.
Lección: el valor no está en el código, está en coser el flujo
Automatizar "escribir código" es la parte fácil y la menos importante. Lo que de verdad cambia el ritmo de una empresa es coser el flujo completo — recogida, formalización, documentación, desarrollo, despliegue — para que ninguna petición se pierda entre dos personas. El asistente no sustituye a nadie: elimina las costuras.
Casos relacionados
Automatización interna · Agentes de IA
Un asistente de Slack personal para cada empleado, en su propio equipo
Config central, ejecución local
panel web para gobernar cada bot; cada uno corre en el Mac de su dueño con su propia suscripción de Claude Code — nada de facturación por tokens ni servidores de bots
Producto B2B · Equipo de desarrollo interno
Linty, un agente autónomo que atiende Jira 24/7: 81 tickets en 5 días sin intervención humana
81
tickets atendidos por Linty en los primeros 5 días operativos