Un año con asistentes de AI en producción: la experiencia de VTB, T-Bank y Dodo Engineering

Desarrolladores de VTB, T-Banco, Dodo Engineering y S7 TechLab compartieron su experiencia implementando asistentes de codificación con IA en la discusión técnica Conversations, organizada por Just AI, y llegaron a conclusiones inesperadas sobre cómo han cambiado los roles en los equipos durante el último año.

¿Qué Cambió en un Año de IA en Código?

Grandes equipos de TI rusos comenzaron a implementar masivamente asistentes de IA para escribir código hace aproximadamente un año. Las actitudes de los desarrolladores pasaron por etapas reconocibles: entusiasmo al inicio, decepción al enfrentarse a alucinaciones y código de baja calidad — y finalmente, adopción tranquila de la herramienta en la rutina diaria.

La pregunta principal hoy no es "¿funciona la IA?" sino "¿ha cambiado algo medible en las métricas del equipo?" Según la experiencia de los participantes de la discusión, hay mejora real de productividad, pero concentrada no donde esperaban: no en la velocidad de escribir nuevas características, sino en la reducción de esfuerzo en tareas rutinarias — pruebas, documentación, refactorización de código plantilla.

• Empresas participantes: VTB, T-Banco, Dodo Engineering, S7 TechLab
• Organizador de la discusión Conversations: Just AI
• Efecto principal de IA: ahorro en tareas rutinarias, no aceleración del desarrollo de nuevas características
• Las herramientas se han consolidado en el flujo de trabajo diario de la mayoría de equipos

¿Deben Obligar a los Desarrolladores a Usar IA?

Una de las preguntas más agudas de la discusión: ¿deberían obligarse a los desarrolladores a usar asistentes de IA? La experiencia de los participantes mostró que el enfoque directivo funciona peor que el orgánico. VTB y T-Banco apostaron por defensores internos: desarrolladores que demostraban personalmente a sus colegas casos de ahorro real de tiempo. Cuando la IA se "prescribe" a través del ejemplo personal, la resistencia disminuye notablemente.

S7 TechLab y Dodo Engineering señalaron que la negatividad surge más a menudo donde el asistente genera código que requiere revisión prolongada. Si la proporción "escrito por IA / aceptado sin cambios significativos" es demasiado baja, la confianza en la herramienta cae — y los desarrolladores vuelven a los métodos antiguos.

"La IA no acelera el desarrollo automáticamente — redistribuye hacia

dónde va el tiempo."

¿Quién Ahora Escribe Código y Quién Solo lo Revisa?

Aquí emergió un cambio inesperado de roles. En equipos donde los asistentes de IA se usan activamente, la tarea del desarrollador se desplaza de escribir código a revisarlo y validarlo. Esto cambia los requisitos para juniors y mid-levels: la capacidad de leer rápidamente, entender y evaluar código ajeno — incluyendo código generado por IA — se vuelve más importante que la capacidad de escribirlo rápidamente desde cero.

Los participantes identificaron dos riesgos reales. Primero: un desarrollador acepta código "a ciegas" y acumula deuda técnica. Segundo: gasta tanto tiempo entendiendo el código generado que todas las ganancias de IA desaparecen. Ambos escenarios ya han ocurrido en equipos de producción.

Qué Significa Esto

Los asistentes de codificación con IA se han consolidado en el ciclo de producción de grandes equipos de TI rusos — pero junto con la eficiencia, han traído nuevas preguntas sobre estructura de roles, calidad de revisión de código y gestión de deuda técnica. La conclusión principal de la discusión: la IA cambia los procesos en lugar de simplemente acelerarlos.

Preguntas Frecuentes

¿Qué empresas participaron en la discusión?

En la discusión técnica Conversations organizada por Just AI, participaron representantes de VTB, T-Banco, Dodo Engineering y S7 TechLab — las cuatro empresas compartieron su experiencia implementando asistentes de IA en desarrollo de producción.

¿Dónde

Realmente Crece la Productividad de los Asistentes de IA?

Según la experiencia de los participantes, las ganancias de productividad son más visibles en tareas rutinarias: escribir pruebas, documentación y refactorizar código plantilla — no en la velocidad de desarrollo de nuevas características.