Alfa-Bank Mostró Cómo Escépticos Implementaron un Servicio Interno de RRHH en Producción con GLM-5

Alfa Bank compartió un caso en el que un equipo de escépticos del vibe-coding llevó un nuevo servicio de RR.HH. a producción en varias semanas usando GLM-5. El experimento mostró que la IA acelera significativamente la creación de prototipos y el desarrollo rutinario, pero no exime al equipo de la responsabilidad de la arquitectura, Git y el lanzamiento.

Cómo se seleccionó el proyecto

Un piloto dentro de HR Tech fue reunido con tres personas que inicialmente no creían en los beneficios prácticos del vibe-coding: un líder de equipo, un analista de sistemas y un product manager. Se les dio libertad para elegir una tarea, y el equipo decidió no hacer un proyecto demo abstracto, sino tomar una característica real de la hoja de ruta de desarrollo de Alfa People. Así surgió el servicio "Mis Objetivos", donde los empleados del banco pueden establecer objetivos y vincular tareas dentro de la plataforma corporativa de RR.

HH. La apuesta no era solo en velocidad, sino también en riesgo razonable. Si el proyecto no hubiera despegado, no habría roto procesos de negocio críticos, pero si tenía éxito, cerraría una necesidad real.

Mientras tanto, los plazos se apretaron rápidamente: la fecha límite se movió varias veces y el tiempo de desarrollo se redujo a solo unos pocos días. El equipo utilizó el descubrimiento ya realizado, los puntos de dolor de usuario recopilados y las soluciones mínimas descritas, luego pasó al modelo la tarea de preparar un borrador de requisitos comerciales.

Cómo fue el desarrollo

En la práctica, lo más desafiante no fue el GLM-5 en sí, sino el trabajo colaborativo de personas que nunca antes habían escrito aplicaciones de producción y tenían casi ninguna experiencia con IDE y Git. El líder de equipo tuvo que hacer primero una incorporación rápida, configurar el entorno y explicar acciones básicas con ramas, solicitudes de extracción y envíos. Sin esto, la IA aceleró fragmentos individuales de trabajo, pero todo el flujo se ralentizó por cada conflicto, malentendido y divergencia en los cambios. A continuación, el proceso se veía así:

• el líder de equipo, analista de sistemas y product manager trabajaron en el servicio
• la interfaz se montó mediante descripciones de texto e iteraciones rápidas
• el equipo hizo 19 versiones de prototipo antes de elegir la base para el producto
• debido a la alta carga en GLM-5 durante el día, el desarrollo a menudo se trasladaba a horas nocturnas
• entre 15 equipos piloto, solo esta composición logró llevar el servicio a producción

La IA ayudó principalmente con maquetación, formularios, validadores y versiones iniciales de pantallas. El product manager describía cómo debería ser la interfaz, el modelo generaba HTML y lógica de UI, y el líder de equipo lo conectaba con el backend y lo llevaba a estado de funcionamiento. Después del lanzamiento, el servicio ganó rápidamente uso real: en la primera semana, se registraron 10,000 usuarios únicos, 9,240 objetivos creados y 981 tareas vinculadas, lo que para un producto interno parecía un inicio muy fuerte.

Donde surgieron limitaciones

El caso demuestra bien que el principal cuello de botella en el desarrollo empresarial con IA no está en la generación de código, sino en la disciplina de ingeniería. Cuando varios participantes cambian simultáneamente el proyecto, la falta de conocimiento de Git se convierte en trabajo manual constante resolviendo conflictos. El segundo problema es infraestructural: 15 equipos participaron en el piloto al mismo tiempo, y durante el día GLM-5 podía tardar varios minutos en responder, lo que hacía la herramienta casi inútil e interrumpía el ritmo de trabajo.

Otro momento revelador sucedió justo antes de la demostración: el modelo y los complementos dejaron de estar disponibles, y los bugs finales tuvieron que ser corregidos manualmente. Esto rápidamente te sobria y disipa la ilusión de que la IA puede reemplazar completamente a un ingeniero en un momento crítico. La arquitectura, integraciones, seguridad, verificación de logs y resolución de casos extremos siguieron siendo responsabilidad del desarrollador experimentado.

De hecho, fueron precisamente los ajustes manuales en el último momento los que permitieron que la presentación y el lanzamiento transcurrieran sin problemas.

"En las grandes empresas, el vibe-coding no es un reemplazo para un

desarrollador, sino una herramienta en manos de un especialista experimentado."

Como resultado, el equipo llegó a un modelo de uso más sobrio: la IA es adecuada para trabajo paralelo en tareas rutinarias, interfaces e hipótesis preliminares, pero no elimina el liderazgo técnico. Si los límites del lanzamiento no se fijan, hay tentación de expandir infinitamente el alcance de tareas, porque parece que el modelo hará "un poco más". En la práctica, fue precisamente un marco de tareas rígido, control manual y la capacidad de detener mejoras en el momento adecuado lo que permitió completar el servicio.

Lo que esto significa

La historia de Alfa Bank es importante porque muestra el vibe-coding sin filtro publicitario. Dentro de una gran empresa, ya puede acelerar el lanzamiento de productos internos, especialmente en la fase de prototipado y tareas típicas de UI, pero funciona solo donde hay un ingeniero experimentado, alcance de trabajo claro y disposición para manejar manualmente todo lo crítico. En este escenario, la IA no es piloto automático, sino un acelerador de equipo que entrega resultados solo con un proceso maduro y responsabilidad rigurosa por el resultado.