Hay una idea que cada vez deja de sonar futurista para quienes trabajan con Jira y empieza a ser simplemente práctica: que una inteligencia artificial no solo escriba código, sino que haga el ciclo completo de trabajo de un desarrollador.

No hablo de pedirle una función suelta, copiarla y pegarla en tu proyecto. Hablo de algo bastante más serio. Alguien abre una incidencia en Jira, se describe una necesidad de negocio, la IA entiende el requisito, pregunta lo que falta, construye la funcionalidad, la organiza en una rama separada, abre una Pull Request en GitHub, ejecuta comprobaciones y deja una aplicación real lista para revisar.

Y sí, eso fue exactamente lo que pasó con un pequeño experimento muy concreto: crear una web que generase un NDA mutuo a partir de un formulario.

El reto: pasar de una issue a una aplicación real

La tarea era sencilla de explicar pero lo bastante realista como para parecer un encargo de empresa. Como ocurre habitualmente en Jira, todo comenzaba con una incidencia que describía una necesidad de negocio. El requisito consistía en construir una aplicación web donde una persona introdujera ciertos datos clave y, con ellos, se rellenara automáticamente un acuerdo de confidencialidad mutuo. Después, ese documento debía poder descargarse localmente.

Lo interesante no era solo la app. Lo interesante era el proceso completo.

La incidencia en Jira se redactó de forma deliberadamente poco detallada. Nada de sobredefinir la solución desde el principio. No se especificó de entrada el formato exacto de descarga ni todos los matices de la interfaz. Esa ambigüedad era intencional, porque en muchos entornos reales los requisitos llegan así. No siempre vienen escritos por un perfil técnico. A veces vienen de legal, de producto o de negocio.

La pregunta de fondo era esta: ¿puede una IA encargarse del flujo de desarrollo casi de punta a punta cuando el encargo parte de una descripción imperfecta?

La configuración: Jira, GitHub, Claude y feature-dev

Para poner esto en marcha se combinó un stack de orquestación bastante potente:

• Jira como origen de la necesidad.
• GitHub como destino del código y de la Pull Request.
• Claude como agente principal de desarrollo.
• feature-dev como plugin que guía el proceso estructurado de implementación.

La orden fue casi insultantemente simple: implementar la incidencia correspondiente usando una aplicación Next.jsdentro de un directorio llamado frontend y crear una PR al finalizar.

Eso es lo que hace que todo esto impresione. Porque el humano apenas tiene que orquestar. En lugar de sentarse a picar código desde cero, define el trabajo y supervisa el resultado.

Bueno, supervisa el resultado y procura no equivocarse con el identificador del ticket, que también puede pasar. De hecho, hubo un pequeño tropiezo inicial al indicar la incidencia incorrecta. La propia IA detectó que esa tarea ya estaba cerrada y pidió corregirlo. Primer detalle interesante: no obedeció ciegamente, sino que validó el contexto.

La IA no adivina, pregunta

Una de las partes más valiosas del flujo fue ver cómo la IA no se lanzó a construir sin más, sino que abrió una ronda de aclaraciones.

Como la descripción era vaga, aparecieron preguntas razonables:

• ¿Qué campos debe tener el formulario?
• ¿Debe ser un formulario mínimo o una versión completa con direcciones, firmas y cargos?
• ¿En qué formato debe descargarse el documento?
• ¿Todo debe resolverse en cliente o conviene una API interna?
• ¿Qué stack visual debe utilizarse?

Las respuestas fueron claras:

• Formulario completo.
• Descarga en PDF.
• Implementación totalmente en cliente por ahora.
• Next.js con App Router, TypeScript y Tailwind.

Y con eso, a trabajar. A partir de ese momento, Jira dejaba de ser solo un gestor de tareas para convertirse en el punto de partida de todo el flujo automatizado.

Este punto es clave para cualquiera que quiera usar IA en desarrollo de software sin hacerse trampas a sí mismo. La IA acelera muchísimo, pero la calidad del resultado depende también de la calidad de las restricciones y decisiones que le marques. Cuando falta información, lo correcto no es inventar, sino preguntar. Y aquí lo hizo bien.

De la idea al código sin tocar una línea

Una vez resueltas las dudas, el agente empezó a montar el proyecto. Estructura de frontend, componentes, lógica de formulario, generación del documento, renderizado, flujo de descarga y organización del repositorio. Todo ello dentro de una rama separada para no ensuciar la principal. Además, el trabajo seguía manteniendo la trazabilidad entre Jira y el desarrollo realizado.

Ese detalle también importa. No se trata solo de que “funcione”, sino de que trabaje con una disciplina parecida a la de un equipo serio. Rama aislada, cambios encapsulados y PR preparada para revisión.

Durante el proceso, la sensación fue muy parecida a la de delegar trabajo a un desarrollador real. Tú defines el qué. El agente empieza a resolver el cómo. Si faltan piezas, pregunta. Si no, sigue avanzando.

Y aquí aparece una de las grandes promesas del vibe coding bien entendido: no usar IA para hacer chapuzas rápidas, sino para orquestar software real, con flujo de trabajo, herramientas y entregables profesionales.

Si te interesa aprender este sistema completo, desde la conexión entre herramientas hasta la automatización del ciclo, merece la pena echar un vistazo al curso de Vibe Coding, donde se monta este flujo paso a paso.

La Pull Request apareció sola

Tras terminar la implementación, la IA dejó preparado un resumen del trabajo realizado y abrió la PR en GitHub. No en la rama principal, sino en una rama específica para el prototipo del generador de NDA mutuo.

Eso ya de por sí era una buena señal. Pero lo más interesante vino al revisar qué afirmaba haber hecho además de programar:

• Compilación del proyecto.
• Limpieza y revisión con lint.
• Comprobaciones funcionales.
• Ejecución de verificaciones relacionadas con Playwright.

Y aquí pasó algo curioso. Inicialmente parecía que no iba a ocuparse demasiado del testing porque no se le había pedido con precisión. Pero al final sí había hecho trabajo de validación. No perfecto, no completo, pero bastante más de lo esperado.

Probando la aplicación: formulario a la izquierda, NDA a la derecha

El momento de la verdad llegó al arrancar la app en local. Dentro del directorio frontend, bastó ejecutar el servidor de desarrollo de Next.js para abrir la aplicación en localhost.

El resultado era una interfaz bastante limpia y profesional.

A un lado, un formulario amplio con todos los datos necesarios para ambas partes del contrato: nombre de empresa, dirección, firmante, propósito del acuerdo, fecha efectiva, duración, periodo de confidencialidad y jurisdicción. Al otro lado, una vista previa del NDA actualizándose en tiempo real.

Ese detalle da mucha calidad al producto final. No había que pulsar un botón de “generar” para ver cambios. Conforme se iban rellenando los campos, el documento se refrescaba dinámicamente. Eso es justo el tipo de experiencia que uno espera en una herramienta moderna.

Se probaron datos de ejemplo con dos partes ficticias y el texto legal se fue completando correctamente. La jurisdicción se actualizaba al instante, las partes aparecían bien identificadas y la estructura del acuerdo mantenía una apariencia seria y consistente.

La descarga en PDF funcionó de verdad

Luego tocaba la parte delicada: exportar el documento.

Al pulsar el botón de descarga, el PDF se generó y quedó guardado localmente. Al abrirlo, el contrato estaba correctamente rellenado con la información introducida en el formulario, con una estructura legal coherente y sin errores evidentes en el contenido.

Y aquí está una de las conclusiones más potentes de todo esto: un único ticket en Jira acabó convertido en una aplicación funcional que genera documentos legales reales.

No una demo vacía. No una pantalla bonita sin utilidad. Una herramienta usable.

¿Y qué pasa con la calidad y las pruebas?

La parte más honesta de todo este experimento vino después, cuando tocó preguntar directamente qué controles de calidad había realizado.

La respuesta fue bastante madura. El agente indicó que había hecho:

• Pruebas automáticas y de build.
• Verificación funcional de extremo a extremo.
• Revisión de calidad del código.

Pero también reconoció lo que faltaba:

• Una revisión manual real del PDF en un visor visual.
• Una suite permanente de tests unitarios integrada en el repositorio.

Eso es importante porque pone los pies en el suelo. La IA puede hacer muchísimo, pero todavía conviene supervisar, afinar y pedir explícitamente ciertas garantías cuando son relevantes.

La lección no es “la IA ya no falla nunca”. La lección es otra: si sabes dirigirla bien, te puede ahorrar una barbaridad de trabajo y dejarte a ti la parte de criterio, revisión y decisión.

De hecho, al detectar ese hueco, se pudo volver a pedir más automatización, más pruebas y revisión adicional. Es decir, el flujo no termina en el primer resultado. Se puede iterar igual que con cualquier miembro del equipo.

Lo realmente interesante no es el NDA

Seamos sinceros. El generador de NDA está bien, pero no es lo más importante de toda la historia.

Lo realmente potente es el patrón:

1. Recibes una necesidad de negocio.
2. La conviertes en una issue.
3. La IA la interpreta y pide aclaraciones.
4. Construye la solución con un stack real.
5. La sube a GitHub con su Pull Request.
6. Ejecuta validaciones.
7. Deja un entregable listo para revisar y desplegar.

Eso cambia bastante el papel del desarrollador. Ya no se trata solo de escribir cada línea, sino de diseñar bien el sistema, dar buenas instrucciones, revisar con criterio y multiplicar la productividad.

Y si este flujo te llama la atención, también te pueden interesar recursos relacionados como el blog de Frogames, el artículo sobre agentes de IA en 60 minutos y la colección de cursos de Inteligencia Artificial, donde todo esto encaja dentro de una visión más amplia de automatización y construcción de productos reales.

Conclusión: la IA ya puede trabajar como parte del equipo

Después de ver todo el proceso, cuesta seguir pensando en estas herramientas como simples asistentes de autocompletado.

Aquí la IA actuó como un desarrollador que recibe un encargo, resuelve dudas, implementa, organiza el repositorio, abre la PR y entrega una solución funcional. Con límites, sí. Con margen de mejora, también. Pero con un nivel de autonomía que hace muy poco parecía ciencia ficción.

La conclusión es bastante clara: ya no estamos hablando de usar IA para programar a trozos, sino de usarla para construir software completo.

Y eso abre una puerta enorme para equipos pequeños, perfiles híbridos, fundadores técnicos y cualquiera que quiera convertir ideas en producto más deprisa y con menos fricción.

Hoy fue un generador de NDA. Y todo empezó, simplemente, con un ticket creado en Jira. Mañana puede ser el panel interno de una empresa, una herramienta de automatización, una app de negocio o el MVP de un servicio entero. El ticket sigue siendo el mismo. Lo que cambia radicalmente es quién hace el trabajo y cómo de lejos puede llegar.