Agentes de IA para desarrollo: delegar cambios con tickets

Te dejo el vídeo arriba, pero aquí lo tienes escrito y con los enlaces para que lo puedas seguir con calma.

Voy a enseñarte un caso de uso que monté por pura necesidad y que, cuanto más lo uso, más claro veo que se parece a cómo van a trabajar muchas empresas dentro de poco. Un tablero de tickets conectado a una IA que recibe peticiones de cambio, las desarrolla en la aplicación y contesta sola. Sin que la persona que pide el cambio toque el código, el repositorio ni nada de lo que hay detrás.

Te aviso ya: esto no es apto para todo el mundo. Requiere un poco de conocimiento técnico. Pero la lógica es sencilla y la idea de fondo es lo que de verdad importa.

¿Qué problema resolvía yo exactamente?

Tengo un negocio con mi compañero Fer y desarrollamos una plataforma juntos. El tema es que Fer necesitaba hacer ciertos cambios en esa plataforma de forma recurrente, sin tener que pasar por mí cada vez.

El problema: toda la documentación de cómo funciona el sistema, las instrucciones, todo, lo tengo yo en mi repo. Y para hacer cambios bien, viene de lujo tirar de esa documentación. Se puede hacer sin ella, porque al final tienes la del propio código, pero con la mía todo sale mejor.

Así que la pregunta era: ¿cómo hago para que Fer pueda pedir cambios tirando de mis skills y mi documentación, sin darle acceso a todo lo que tengo montado?

Y ahí es donde encajó lo que ya tenía funcionando.

¿Cómo funciona un tablero de tickets conectado a Claude Code?

Yo ya tenía un Claude Code montado en un servidor. Lo uso a diario desde Telegram, con mis skills, con los repos actualizándose solos, igual que trabajo en local. Si quieres ver esa parte, la conté aquí: metí Claude Code dentro de Telegram.

La lógica del tablero es la misma. Lo único que cambia es de dónde le llegan las instrucciones. En vez de escribirle por Telegram, Fer las manda desde otro sitio: un tablero kanban de peticiones de cambio.

Funciona así:

• Fer crea una petición nueva. Le pone un título de lo que quiere cambiar y, en formato Markdown, explica el cambio como se lo explicarías a cualquier IA: "me gustaría que este botón, al pulsarlo, hiciera esto".
• Si hace falta, adjunta imágenes, PDFs o lo que sea.
• Esa petición llega a mi servidor de una forma muy específica para que pueda procesar el ticket.
• La IA lo coge, hace el cambio, hace el commit y contesta.

Hay un sistema de colas montado. No intenta procesar todo a la vez: va ticket a ticket para no saturar el servidor.

¿Y qué pasa cuando el cambio no está bien?

Te pongo el ejemplo real. Fer pidió añadir un botón para descargar un menú en PDF. Adjuntó una captura de pantalla. Claude lo procesó en el servidor, hizo el commit, añadió lo que le pedía y le contestó: "hemos hecho este commit, se ha añadido esto". La IA le manda un correo cuando termina y el ticket pasa solo a completado.

Pero si Fer revisa y ve que algo está mal, le puede contestar en el mismo ticket: "oye, esto no funciona por esto, te mando esta imagen". En ese momento Claude vuelve a pasar el ticket a "en progreso", lo recoge cuando le toca en la cola y, cuando termina, le vuelve a contestar.

El resultado: tengo a Fer haciendo cambios en un servidor entrenado con mis skills, mi conocimiento y mi documentación, sin necesidad de que acceda a absolutamente nada de lo que tengo montado. Y funciona increíblemente bien, porque son cambios que de la otra forma tendría que estar haciendo yo.

Por qué creo que esto es el futuro del desarrollo

Aquí viene la parte que a mí me parece más interesante.

Lo que veo es que muchas empresas de desarrollo van a acabar funcionando así. Los equipos de desarrolladores se van a centrar en decidir qué es importante desarrollar y qué no. Igual que antes tenías al Scrum Master decidiendo qué entraba en el backlog y en los sprints, ahora vas a tener a una persona decidiendo qué desarrolla la IA y qué no.

Cuando ese ticket pasa por el programador, este puede tirar de todos esos tickets a través de skills montadas en su entorno, descargándose los datos del desarrollo por una API, con todo sincronizado con los repos, haciendo las PRs, todo el proceso.

Y aquí está el cambio de fondo: creo que el trabajo del programador va a ser cada vez menos picar código y más pensar desde qué ángulo afrontar cada problema, y supervisar que se resuelva bien.

Los programadores no vamos a desaparecer. Lo que cambia es el rol. Antes pensabas "cómo optimizo este algoritmo, cómo monto esta estructura, qué patrón uso" y luego lo picabas tú. Ahora piensas lo mismo, pero en vez de picarlo se lo mandas a la IA con la explicación suficiente para que lo haga bien. Hay mucha gente todavía muy negacionista con esto, y creo que interiorizarlo cuanto antes es clave.

Esto no solo vale para desarrollo. Sirve igual para atención al cliente. Imagina que tienes una plataforma y la gente te pide cambios, ese feedback típico que te llega. Vas a tener a una persona filtrando: "esto lo hacemos, y lo hacemos de esta manera". Lo acepta, la IA lo desarrolla, tú revisas que está bien y se le contesta al cliente que ya está hecho. La cantidad de fricción que te quitas es enorme.

¿Por qué es una ventaja competitiva sobre todo para startups?

Hay que cogerlo con pinzas. Si hablamos de grandes plataformas o grandes corporaciones, todavía no, o no de esta forma tan automatizada.

Pero para startups, empresas en crecimiento y desarrollos ágiles, esto puede ser una ventaja competitiva fuerte. Por la velocidad de desarrollo que te da y por la rapidez a la hora de implementar cambios, que muchas veces son un dolor de cabeza tremendo.

Y hay una capa más que me parece importante señalar. Ahora mismo la persona que desarrolla es la que tiene sus skills, su documentación, todo montado en local o en su servidor. Pero yo creo que eso va a empezar a cambiar: se van a crear capas donde el usuario no accede directamente a las skills, sino a un intermediario conectado a un servidor con toda la documentación detrás. Sobre todo por el tema de filtraciones de datos, para que quien desarrolla no tenga tanto poder sobre cómo funcionan ciertos procesos por dentro.

Herramientas que salen en el vídeo

• Claude Code: es la IA que corre en el servidor y procesa cada ticket. La misma que uso desde Telegram, con mis skills y mi documentación cargadas.
• Telegram: el canal desde el que ya controlaba ese Claude Code antes de montar el tablero. La lógica del tablero es la misma, solo cambia por dónde entran las instrucciones.

Un apunte sobre coste, porque lo comento en el vídeo: ha habido cambios en Anthropic y van a empezar a cobrar por cómo se usa esto. Te dan un crédito mensual de la misma cantidad que pagas en tu plan. Yo pago unos 180 o 200 euros al mes, y para el uso que le doy no lo llego a gastar. Pero si vas con un plan de 20 euros, para este tipo de funcionalidades se te puede quedar corto. Tenlo en cuenta según tu caso.

Si quieres entender bien esta base, te dejo dos lecturas: la guía de automatización y agentes con IA y, si quieres exprimir la herramienta, qué son y cómo se usan los subagentes de Claude Code.

Lo que se viene

Es un caso de uso muy simple, pero abre un debate enorme. La IA deja de ser un chatbot que suelta respuestas y pasa a ser algo que trabaja de verdad con tus herramientas, tu documentación y tus skills, para hacer cosas. Y lo hace sin que quien pide el trabajo tenga que tocar nada de lo que hay detrás.

No es ciencia ficción. Lo tengo funcionando hoy, con Fer pidiendo cambios y la IA resolviéndolos sola. Y cuanto más lo uso, más convencido estoy de que así es como vamos a trabajar dentro de poco.

Si lo que te interesa no es tanto el "cómo hago una web" sino todo lo que hay detrás (cómo creo las skills, cómo monto la documentación, cómo levanto sistemas como este), es justo lo que enseño en la formación YO S.A.. Ahí está el motor de todo lo que ves en el canal.