El motor funcionaba. El producto todavía no existía.
Los agentes de IA de Purgo podían escribir pipelines de datos de nivel producción. Lo que no tenían era forma de llegar a un usuario. Construimos la plataforma alrededor de ellos.
15 minutos para construir un pipeline de datos, contra más de 10 días
El problema
Purgo empezó como una adquisición: una solución con las bases para analizar código con IA, y un CEO, Sang Kim, que veía un producto más grande ahí. La ambición era IA multiagente haciendo el trabajo que los ingenieros de datos hacen a mano, y el objetivo era uno de los espacios menos indulgentes del campo, donde una salida que apenas es plausible es peor que ninguna salida.
La experiencia buscada era específica. Un usuario escribe un requisito en Jira. Lo que vuelve es código listo para producción que respeta la lógica de negocio, las reglas de la empresa y los estándares de QA.
La brecha no era la inteligencia. Era todo lo que la rodea. La infraestructura original se había construido para comprobar un concepto, no para cargar un producto SaaS, y un motor sin consola, sin integraciones, sin pipeline de QA y sin interfaz no es algo que un cliente pueda comprar.
Qué construimos
La experiencia de producto, y la plomería de abajo. Una aplicación web, una consola y un tablero para que la funcionalidad de la IA saliera a la superficie. Una integración con Jira para poder enviar una tarea de desarrollo y recibir su código generado contra ese caso. Una integración con GitHub para que las salidas queden documentadas y almacenadas automáticamente en vez de a mano.
Y después la parte que decide si a un producto de IA se le confía una segunda vez: un pipeline de QA y de pruebas que valida no solo la interfaz sino el comportamiento de los flujos inteligentes en sí. Una funcionalidad de IA sin forma de verificar su salida es una esperanza, no una funcionalidad.
También cargamos la documentación, el trabajo de UI y UX, y los materiales del sitio de mercadeo, así que el lanzamiento fue un lanzamiento de producto y no un demo con una landing page.
- Aplicación web, consola y tablero
- Integración con Jira para enviar tareas y recuperar código
- Integración con GitHub para documentación y almacenamiento automáticos
- Pipelines de QA y de pruebas que cubren los flujos inteligentes, no solo la interfaz
- Documentación, UI y UX, y materiales de lanzamiento
Cómo funciona
Paso 01
El requisito entra a Jira
Un usuario escribe un ticket en la herramienta en la que su equipo ya trabaja. Ningún flujo nuevo que adoptar.
Paso 02
La plataforma lo recoge
La consola y el tablero le entregan la solicitud a los agentes de IA de Purgo con el contexto del proyecto adjunto.
Paso 03
Los agentes generan el código
Código de pipeline listo para producción, escrito contra la lógica de negocio, las reglas de la empresa y los estándares de QA.
Paso 04
QA valida, GitHub registra
La salida pasa por el pipeline de pruebas, y después aterriza documentada y almacenada en el repositorio.
Paso 05
Revisado y desplegado
Una persona revisa código que llega estandarizado, mantenible, y suficientemente legible para depurarlo.
Del diseño a la consola y a probar el sistema completo, Koombea ha ayudado con casi todos los aspectos de poner la plataforma en pie.
Qué pasó
El caso de estudio original no publica cifras de ingresos ni de tamaño de equipo. El único número que Purgo sí publica es el que le importa a su comprador.
- La creación de un pipeline bajó de más de 10 días a menos de 15 minutos, cifra publicada por Purgo
- Los requisitos que entran por Jira devuelven código listo para producción
- La validación, la documentación y el despliegue corren sin cuellos de botella manuales
- Salidas estandarizadas y mantenibles, y por eso más fáciles de depurar que sus equivalentes hechos a mano
Notas de entrega
Stack: Python, aplicación web y consola, API de Jira, API de GitHub, pipelines de QA y de pruebas.
El proyecto corrió entre zonas horarias contra una arquitectura distribuida, con los sistemas de backend y los flujos de datos alineados entre equipos. Sang destacó el arranque de nuevas personas: mientras el equipo crecía y cambiaba, la gente nueva llegaba productiva, que es un resultado de documentación y de proceso y no de contratación.
Capacidades aplicadas: Ingeniería de Producto, Integraciones y Datos. Entregado como un alcance comprometido, estimado en story points y cotizado antes de empezar.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.