Cómo introducir IA en un equipo de ingeniería que ya funciona
Introducir IA en ingeniería no consiste en repartir licencias y esperar productividad. Hay que rediseñar el flujo, acordar dónde puede ayudar, mantener visible la calidad y convertir los hallazgos individuales en capacidad del equipo.
Cuando un equipo de software ya funciona, cambiarlo requiere más cuidado que empezar desde cero. Hay hábitos que protegen la calidad, acuerdos implícitos que sostienen la colaboración y una identidad profesional construida durante años. La IA puede ampliar todo eso o erosionarlo.
He acompañado la evolución de un equipo de ingeniería de más de quince personas hacia una forma de trabajo cada vez más agéntica. La primera lección fue sencilla: la unidad de adopción no es la herramienta. Es el sistema de trabajo.
Empezar observando, no imponiendo
Antes de elegir usos conviene mirar dónde se acumula la fricción: comprender código ajeno, preparar pruebas, reproducir incidencias, actualizar documentación, revisar cambios, explorar una tecnología o convertir una decisión en una primera implementación.
Después hay que distinguir tres cosas:
- Trabajo lento porque exige criterio.
- Trabajo lento porque falta contexto.
- Trabajo lento porque repetimos mecánicamente pasos conocidos.
La IA no resuelve igual cada caso. Puede ampliar el criterio ofreciendo alternativas, organizar el contexto o ejecutar trabajo repetible. Mezclar las tres categorías produce pilotos vistosos y poca mejora real.
Un primer ciclo seguro
El mejor piloto no es necesariamente el que promete más ahorro. Es el que permite aprender sin poner en riesgo el producto. Elegiría una tarea frecuente, reversible y observable; acordaría qué significa un buen resultado; mantendría revisión humana; y compararía el flujo completo antes y después.
No mediría solo líneas de código o tiempo de generación. Miraría tiempo hasta producción, defectos, retrabajo, facilidad de revisión y comprensión posterior. Producir más deprisa puede simplemente mover el cuello de botella hacia la revisión o la operación.
Convertir trucos personales en infraestructura del equipo
Si cada persona mantiene su colección privada de prompts, la organización no está aprendiendo. Los patrones útiles deben convertirse en instrucciones compartidas, ejemplos, herramientas, evaluaciones y criterios de revisión versionados.
También cambia la revisión. Ya no basta con preguntar si el código funciona. Hay que comprobar si el problema estaba bien formulado, qué contexto recibió el agente, qué decisiones tomó, qué pruebas ejecutó y qué parte sigue sin estar verificada.
La calidad no desaparece porque la ejecución sea más barata. Se vuelve más importante porque el volumen de cambios que podemos producir aumenta.
Dar espacio a la resistencia útil
No toda objeción es miedo al cambio. A veces una persona está señalando un problema real de privacidad, mantenibilidad, carga cognitiva o pérdida de aprendizaje. La adopción mejora cuando el equipo puede convertir esas objeciones en guardrails y experimentos, no cuando se le pide entusiasmo obligatorio.
La dirección debe dejar claras tres cosas: qué problemas buscamos resolver, qué límites no se pueden cruzar y cómo se reconocerá una mejora. El equipo puede entonces explorar dentro de un terreno seguro.
La señal de que está funcionando
La adopción madura cuando una persona nueva puede beneficiarse del sistema sin copiar los hábitos de quien hizo el primer experimento; cuando los resultados pueden revisarse; y cuando el equipo sabe en qué situaciones no debe delegar.
No se trata de que todas las personas usen IA todo el tiempo. Se trata de que el equipo disponga de una nueva capacidad compartida y pueda evolucionarla con criterio.
Fuentes y referencias
- Informe DORA 2025 sobre desarrollo de software asistido por IA.
- Marco seguro de desarrollo de software de NIST.
- Fuente primaria: experiencia de Victor evolucionando un equipo internacional de ingeniería.