Qué cambia realmente en un equipo de ingeniería AI-native

Casi todo lo que se publica sobre ingeniería con IA habla de velocidad: cuánto más rápido se escribe código. Nos parece la parte menos interesante. Lo que cambia de verdad en un equipo AI-native es dónde se concentra el trabajo humano: generar código dejó de ser el cuello de botella, y el esfuerzo se mueve hacia decidir qué construir, preparar el contexto, poner límites y verificar. Esta guía describe esos cambios en el trabajo diario —y lo que no cambia.

Lo que no cambia

Empecemos por aquí, porque es lo que más se pierde en la conversación:

• La responsabilidad sigue siendo humana. Un agente puede proponer, escribir y probar código. Quien lo integra responde por él.
• Entender el problema sigue siendo el primer trabajo. La IA acelera la ejecución de una tarea; no decide si la tarea era la correcta.
• La arquitectura se sigue decidiendo. Generar rápido sobre una arquitectura que nadie pensó solo produce deuda más rápido.

En Cian-OS lo resumimos en un principio: la IA ejecuta; las personas siguen siendo responsables.

Lo que cambia, en nueve prácticas

1. Descomposición de tareas

Las tareas se vuelven más pequeñas y más precisas. No porque la IA no pueda producir mucho código, sino porque una persona tiene que poder revisar el resultado completo. «Construye el módulo de facturación» produce algo imposible de revisar; «agrega la validación del número de identificación tributaria al formulario de clientes, con sus pruebas» produce algo que se puede verificar en minutos.

2. Preparación del contexto

Un agente solo sabe lo que se le da. Las reglas del proyecto, las convenciones, las decisiones de arquitectura y los comandos para probar y desplegar pasan de vivir en la cabeza de alguien a vivir escritos en el repositorio. En Cian-OS lo tratamos como infraestructura: el contexto se escribe, se versiona y se revisa, igual que el código. Un efecto lateral valioso: ese contexto también sirve a cualquier persona nueva en el equipo.

3. Límites de agentes y herramientas

Hay que decidir —por escrito— qué puede hacer un agente sin pedir permiso y qué no. Leer código, proponer cambios y correr pruebas suelen estar dentro; desplegar, tocar producción o borrar datos, fuera. Los agentes trabajan sin secretos ni datos reales de clientes en su contexto.

4. Revisión

La revisión de código deja de ser un trámite y se vuelve el punto de control principal. Nada se integra sin que una persona que entiende el cambio lo revise, sin importar quién —o qué— lo escribió. El volumen de cambios aumenta; el estándar de revisión no puede bajar.

5. Verificación

Cada mejora en la velocidad de generación amplía la distancia entre lo que se produce y lo que se ha comprobado. Si la verificación no escala al mismo ritmo, esa distancia se llena de errores que nadie vio. Por eso, en nuestra forma de trabajar, la verificación no es una fase al final: pruebas automatizadas, análisis estático, revisión de dependencias, controles de seguridad, revisión humana y validación de aceptación corren de forma continua.

6. Pruebas

La IA escribe pruebas con facilidad, y eso tiene una trampa: una prueba que nunca falla no prueba nada. Alguien tiene que comprobar que las pruebas generadas fallan cuando deben fallar, y revisarlas con el mismo cuidado que el código que protegen.

7. Seguridad

Aparecen riesgos nuevos y se agravan algunos viejos. Un agente puede proponer una dependencia que nadie evaluó o copiar un patrón inseguro con total confianza. Y si el producto usa modelos de lenguaje, sus entradas deben tratarse como no confiables: la inyección de instrucciones (prompt injection) encabeza la lista de riesgos de OWASP para aplicaciones con modelos de lenguaje. Los cambios en autenticación, permisos y datos sensibles llevan revisión reforzada.

8. Criterio humano

Cuando ejecutar es barato, el valor se concentra en decidir: qué problema vale la pena resolver, qué se construye y qué no, qué compromiso de arquitectura envejece bien, cuándo algo está listo para producción. Esas decisiones no se delegan a un modelo, porque nadie puede pedirle cuentas a un modelo.

9. Gobierno de la entrega

Medir cuánto código produce la IA es medir lo equivocado. Lo útil es medir cuánto software verificado llega a producción y cuánto se sostiene: indicadores como la frecuencia de despliegue, el tiempo que tarda un cambio en llegar a producción, la tasa de cambios que fallan y el tiempo de recuperación —los que propone DORA— dicen más que cualquier conteo de líneas o de tareas.

Por qué este Playbook no promete productividad

No incluimos multiplicadores de productividad. Las cifras que circulan miden cosas distintas —líneas, tareas, tiempo hasta una primera versión— en contextos distintos, y casi nunca miden lo que importa: software verificado, en producción, que el equipo puede seguir manteniendo. Si la adopción de IA funciona, se nota en esos indicadores de entrega. Si solo se nota en el volumen de código, todavía no funciona.

Un ejemplo ilustrativo: una tarea, de principio a fin

Un equipo de cuatro personas (ejemplo ilustrativo) necesita que el sistema de pedidos rechace descuentos por encima del límite autorizado para cada cliente:

1. Tarea: una persona la acota: la regla, dónde se aplica, qué mensaje ve el usuario y qué pruebas deben pasar.
2. Contexto: el agente trabaja con las convenciones del repositorio y la decisión, ya documentada, de que las reglas de precios viven en el servidor.
3. Límites: el agente puede modificar código y correr pruebas en su entorno; no puede desplegar ni ver datos de clientes.
4. Generación: el agente propone el cambio y sus pruebas.
5. Verificación: las pruebas corren en cada cambio; un ingeniero confirma que fallan si se quita la validación.
6. Revisión: un ingeniero que conoce el módulo de precios revisa el cambio completo; por tocar reglas de dinero, lleva revisión reforzada.
7. Entrega: el cambio llega a producción por el despliegue de siempre, con posibilidad de revertir. Un responsable con nombre responde por él.

Nada de este flujo depende de una herramienta en particular. Todo depende de que alguien lo haya diseñado.

Errores comunes

• Medir código generado en lugar de software verificado en producción.
• Pedirle a un agente tareas enormes que nadie puede revisar completas.
• Dejar el contexto en la cabeza de las personas y esperar que los agentes lo adivinen.
• Dar a los agentes acceso a secretos o a producción «para que sean más útiles».
• Bajar el estándar de revisión porque el volumen de cambios subió.
• Confiar en pruebas generadas sin comprobar que fallan cuando deben.
• Elegir herramientas antes de diseñar el flujo de trabajo.