Parte II. El equipo: personas y agentes
Aprender cuando la IA escribe el primer borrador
Juniors, confianza y verificación
Tres semanas sin escribir una línea
En la Sprint Review, Celia, la diseñadora, preguntó por qué el filtro de clases tardaba tanto en cargar. Aitana había hecho ese cambio. Abrió el código para explicarlo y se quedó callada. Lo había generado con la IA, lo había probado, funcionaba, y no sabía por qué estaba escrito así.
Después, a solas, le contó a Olga que llevaba tres semanas sin escribir una línea de código desde cero. Pedía, revisaba por encima, probaba y entregaba. Iba rapidísimo. Y tenía la sensación de estar aprendiendo menos que en las prácticas.
Quien no escribe no aprende a revisar
Revisar bien exige saber escribir. Un error se detecta porque uno sabe cómo se haría bien. Quien nunca ha escrito una consulta lenta no sabe ver una consulta lenta.
Por eso la IA plantea un problema de aprendizaje, y le afecta sobre todo a quien empieza. Un desarrollador con diez años de oficio usa la IA para ir más rápido en lo que ya sabe hacer. Una persona junior la usa para hacer lo que todavía no sabe, y se salta justo la parte en la que se aprende.
No es solo cosa de juniors. Jeff Gothelf, en Product Management and AI (Sense & Respond Press, 2026, capítulo 5), cita un estudio de Sarah Baldeo, investigadora de la Universidad de Middlesex, publicado en abril de 2026 en la revista Technology, Mind, and Behavior, en el que casi dos mil adultos hicieron tareas de trabajo con IA.
Quienes aceptaban lo que proponía la IA sin discutirlo terminaban con menos confianza en su propio criterio. Quienes la corregían, la discutían o la rechazaban terminaban con más confianza que quienes no la usaban. La variable no era la herramienta: era la actitud con la que se usaba.
Primero tu borrador
La regla más útil que conozco es sencilla:
Primero tu borrador, después la IA. Tres líneas propias antes de pedir nada. Luego compara.
No hace falta que el borrador sea bueno. Hace falta que exista. Cuando la IA responde, la comparación es lo que enseña: dónde coincidís, dónde no y si estuviste a punto de aceptar algo que estaba mal.
En un equipo, la regla se aplica en el refinamiento y en el código. En el refinamiento, cada persona escribe su idea de los criterios de aceptación antes de pedírselos a la IA. En el código, quien empieza escribe la primera versión de una función pequeña antes de generar el resto.
La revisión, el sitio donde se aprende
La revisión de código entre personas vuelve a ser lo que fue en los mejores equipos: el sitio donde se aprende, no un trámite para pasar a producción. Aitana y Germán empezaron a revisar juntos una vez por semana, con el código de ella delante, y Germán preguntaba "¿por qué así?" antes de decir nada más.
Dos cosas que no conviene exigir:
- Velocidad sin verificación. Si lo que se premia es entregar mucho, se entrega mucho sin comprobar.
- "Usar la IA" como objetivo de rendimiento. Se usará para todo, incluso para lo que se haría mejor sin ella.
Y una que conviene recordar: revisar cansa más que escribir. Un equipo que pasa el día revisando código generado necesita repartir esa carga y ponerle límite, como vimos en el capítulo 4.
En resumen
Quien no escribe no aprende a revisar. Aceptar sin discutir erosiona el criterio; discutir con la IA lo refuerza. Primero tu borrador, después la IA, y la revisión entre personas como el sitio donde se aprende.
Pruébalo esta semana
Durante una semana, en el refinamiento, cada persona escribe sus criterios de aceptación antes de pedírselos a la IA. Al final de la semana, comparad: ¿qué habríais dejado pasar si hubierais aceptado lo primero que salió?
Hay más ideas para repartir la carga en Cómo trabajar con agentes sin quemar al equipo.