Alfa-Bank convierte la idea de un tester en un generador de stubs con IA para equipos de pruebas

Un tester de Alfa-Bank ha creado una herramienta interna de IA que convierte una descripción en texto en stubs de API listos para probar servicios. El proyecto nació como un experimento nocturno dentro de la comunidad de IA y acabó convertido en un MVP, con dominio propio 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 las redes neuronales y ver cómo aplicarlas al trabajo diario de QA. Tras varios experimentos, entre ellos un bot de Telegram para evaluar inglés, se unió a la comunidad interna de IA en torno a la plataforma AlfaGen.

En una de las reuniones se mostró a los participantes una lista de ideas útiles a las que los equipos aún no habían llegado. Una de ellas era una tarea muy familiar para cualquier tester: crear stubs de API de forma automática.

La idea era práctica y muy terrenal. Cuando el frontend ya está listo pero el backend sigue en desarrollo, las pruebas suelen frenarse porque el servicio no devuelve respuestas funcionales. Los stubs resuelven el problema, pero prepararlos exige tiempo, configuración manual y conocer la infraestructura.

Los requisitos de negocio del nuevo agente describían un escenario sencillo: el usuario fija las condiciones, el sistema aclara los detalles y entrega el código de un stub que se puede usar de inmediato en las pruebas, sin una larga preparación.

Cómo funciona el generador

Zaitsev hizo la primera versión muy rápido en el «Taller de prompts» de AlfaGen: configuró un escenario que generaba el código del stub a partir de una descripción. Pero ese formato resultó incómodo para el trabajo real y escalaba mal hacia compañeros sin formación técnica. Un diálogo largo en el chat, un lanzamiento manual y la necesidad de entender los detalles lo dejaban más como una demostración de la idea que como una herramienta para el día a día de los equipos de QA. Por eso hizo falta una segunda versión, con interfaz propia y lanzamiento automático.

«Se suponía que el proyecto llevaría 3 meses, pero yo no lo sabía y lo

hice todo en una tarde».

En la segunda versión, el autor montó un agente completo con tres piezas: 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 en una ventana de chat, por ejemplo qué respuestas devolver para distintos userId, si hace falta un retraso y cuándo hay que devolver un error 404. Después, el sistema recorre varios pasos:

• determina el tipo de stub: REST o SOAP
• elige el método HTTP adecuado
• calcula cuántos stubs independientes hacen falta para las distintas condiciones
• genera el código y comprueba si tiene errores
• despliega el resultado en WireMock

Según el autor, todo el ciclo dura entre 10 y 15 segundos, y después el stub ya se puede conectar al entorno de trabajo. Para quienes necesitan control total, la interfaz mantiene además un modo manual en el que los parámetros se fijan por separado.

Eso hace que la herramienta sea útil tanto para ingenieros con experiencia como para testers que no quieren perder tiempo montando y lanzando mocks a mano. En la práctica, el agente libera al usuario de casi toda la mecánica rutinaria.

Del MVP al lanzamiento

El prototipo nocturno pasó pronto a ser un MVP de dos semanas y después un producto interno completo. Tras una presentación en una demo de la plataforma AlfaGen, otros equipos del banco se interesaron por la herramienta y el desarrollador se unió a un grupo que trabaja en agentes de QA a tiempo completo.

A continuación se llevó el proyecto a nivel de producción: se añadieron un modo de chat, carpetas por proyecto, grupos de stubs con lógica, correcciones a partir de los comentarios de los compañeros y un flujo de uso más cómodo. A finales de noviembre, el equipo cerró los problemas críticos y empezó a preparar un lanzamiento más amplio.

La solución recibió un dominio propio, se configuraron los accesos, se reescribió el frontend con las bibliotecas internas del banco y se preparó la documentación. Ahora el generador lo prueban grupos focales dentro del banco, mientras que una versión local ya se usa en tareas reales en productos para pequeñas empresas.

En esencia, es un ejemplo de cómo una plataforma interna de IA convierte un problema concreto de un ingeniero en un servicio aplicado para toda una organización.

Qué significa

La historia de Alfa-Bank muestra que las herramientas de IA útiles para el desarrollo no nacen solo en equipos de I+D dedicados, sino también desde abajo, a partir de un problema concreto de los testers. Si estos proyectos se llevan con rapidez hasta tener interfaz, documentación, estándares internos y un piloto real, dejan de ser una demostración de lo que pueden hacer los LLM y pasan a ser una herramienta de trabajo que ahorra horas a todo el equipo y acelera la llegada de nuevos servicios a la fase de pruebas.

Para la IA corporativa, eso importa más que cualquier escenario de demo vistoso.