Alfa-Bank convirtió la idea de un tester en un generador de stubs con AI para equipos de pruebas

Un evaluador del Alfa-Bank convirtió una idea en un generador de stubs impulsado por IA para equipos de prueba

Un evaluador del Alfa-Bank creó una herramienta interna de IA que convierte descripciones de texto en stubs de API listos para pruebas de servicios. El proyecto comenzó como un experimento nocturno dentro de la comunidad de IA y eventualmente evolucionó hacia un MVP, un dominio separado y pruebas dentro del banco.

Cómo surgió el proyecto

La historia comenzó en la primavera de 2025, cuando el ingeniero de pruebas Stas Zaitsev decidió profundizar en redes neuronales y explorar cómo podrían aplicarse al trabajo cotidiano de QA. Después de varios experimentos, incluido un bot de Telegram para evaluar inglés, se unió a la comunidad de IA interna alrededor de la plataforma AlfaGen. En una de las reuniones, se mostró a los participantes una lista de ideas útiles que los equipos aún no habían implementado.

Entre ellas estaba una tarea bien conocida por los evaluadores: crear automáticamente stubs de API. La idea era práctica y muy directa. Cuando el frontend ya está listo pero el servidor aún está en desarrollo, las pruebas frecuentemente se ven obstaculizadas por la falta de respuestas funcionales del servicio.

Los stubs resuelven este problema, pero su preparación requiere tiempo, configuración manual y comprensión de la infraestructura. En los requisitos comerciales para el nuevo agente, se describió un escenario simple: el usuario especifica las condiciones, el sistema aclara los detalles y proporciona el código del stub que se puede usar inmediatamente en las pruebas sin preparación prolongada.

Cómo funciona el generador

Zaitsev creó la primera versión muy rápidamente en el Taller de Prompts de AlfaGen: configuró un escenario que generaba código de stub basado en una descripción. Sin embargo, este formato resultó incómodo para el trabajo real y no escalaba bien para colegas sin experiencia técnica. El diálogo largo en el chat, la ejecución manual y la necesidad de entender detalles hicieron que la solución fuera más una demostración de idea que una herramienta para el trabajo cotidiano de los equipos de QA. Por eso fue necesaria una segunda versión con interfaz separada y ejecución automática.

"Se suponía que el proyecto tomaría 3 meses, pero no lo sabía y lo

hice todo en una noche."

En la segunda versión, el autor ensambló un agente completo en tres partes: WireMock para ejecutar los stubs, una capa de API en Kotlin y Spring AI para conectar con la interfaz web de AlfaGen, y una interfaz que se puede usar sin conocimientos profundos de programación. El usuario simplemente describe el escenario necesario en la ventana de chat — por ejemplo, qué respuestas devolver para diferentes userIds, si se necesita una demora y cuándo devolver un error 404. Después de eso, el sistema pasa por varios pasos:

• determina el tipo de stub — REST o SOAP
• selecciona el método HTTP requerido
• calcula cuántos stubs separados necesitan crearse para diferentes condiciones
• genera código y lo verifica en busca de errores
• inicia el resultado en WireMock

Según el autor, todo el ciclo toma 10–15 segundos, después de lo cual el stub ya puede conectarse en el entorno de trabajo. Para quienes necesitan control total, la interfaz también tiene un modo manual donde los parámetros se establecen por separado. Esto hace que la herramienta sea útil tanto para ingenieros experimentados como para evaluadores que no desean gastar tiempo en ensamblaje manual e implementación de mocks. Esencialmente, el agente elimina casi toda la mecánica rutinaria del usuario.

De MVP al lanzamiento

El prototipo nocturno evolucionó rápidamente en un MVP de dos semanas y luego en un producto interno completo. Después de una presentación en la demostración de la plataforma AlfaGen, otros equipos del banco se interesaron en la herramienta y el desarrollador se unió a un grupo ya trabajando en agentes de QA a tiempo completo. El proyecto luego comenzó el proceso de alcanzar calidad industrial: agregaron modo de chat, carpetas de proyecto, grupos de stubs con lógica, correcciones por retroalimentación de colegas y un escenario de usuario más conveniente.

A finales de noviembre, el equipo cerró problemas críticos y comenzó la preparación para un lanzamiento más amplio. Para la solución, asignaron un dominio separado, configuraron accesos, reescribieron la interfaz bajo las bibliotecas internas del banco y prepararon documentación. Actualmente, el generador está siendo probado por grupos de enfoque dentro del banco, y la versión local ya se está utilizando en tareas reales en productos para pequeñas empresas.

En esencia, este es un ejemplo de cómo una plataforma de IA interna convierte puntos de dolor de ingeniería individuales en un servicio aplicado para toda una organización.

Lo que esto significa

La historia del Alfa-Bank demuestra que las herramientas de IA útiles para el desarrollo pueden surgir no solo de equipos de I+D dedicados, sino desde abajo — desde puntos de dolor específicos de los evaluadores. Si tales proyectos se llevan rápidamente a interfaz, documentación, estándares internos y pilotos reales, dejan de ser demostraciones de capacidades de LLM y se convierten en herramientas de trabajo que ahorran horas a equipos completos y aceleran el despliegue de nuevos servicios para pruebas. Para IA corporativa, esto es más importante que cualquier escenario de demostración bonito.