La promesa es tentadora: asistentes de Inteligencia Artificial capaces de acelerar la entrega de software, sugerir soluciones al vuelo y “desbloquear” tareas complejas en minutos. Pero un nuevo estudio de Anthropic —la empresa detrás de Claude— pone sobre la mesa una pregunta incómoda para equipos de ingeniería, managers y escuelas de programación: ¿qué pasa con las habilidades cuando se aprende con el copiloto encendido?
La respuesta, al menos en el contexto del aprendizaje, no es amable. En un ensayo controlado aleatorizado con 52 ingenieros de software (en su mayoría perfiles junior) que debían aprender una librería nueva de Python llamada Trio, el grupo que trabajó con asistencia de IA obtuvo peores resultados de comprensión que el grupo que programó sin ella. La diferencia fue de un 17% en la evaluación, “casi dos letras” en términos académicos, según describe la propia investigación.
El dato que rompe el relato: casi no hay ganancia de tiempo
El estudio no discute que la IA pueda ser útil. Lo que discute es el peaje cuando se usa como muleta durante la adquisición de una habilidad nueva.
En la parte de rendimiento, el resultado es casi anticlimático: quienes usaron IA terminaron, de media, unos dos minutos antes. Ese ahorro, además, no alcanzó significación estadística. En cambio, la caída en “maestría” sí fue significativa: el grupo con IA promedió un 50% en el test, frente al 67% del grupo sin IA.
Para entender por qué importa, hay que mirar dónde se abrió la mayor brecha: depuración (debugging). No se trata de una habilidad secundaria. Es exactamente la competencia que permite supervisar código ajeno, detectar errores sutiles y explicar por qué algo funciona… o por qué va a fallar en producción.
Tabla rápida: resultados del experimento
| Métrica | Con asistencia de IA | Sin asistencia de IA |
|---|---|---|
| Tiempo medio de finalización | ~2 minutos más rápido (no significativo) | — |
| Nota media del test | 50% | 67% |
| Mayor diferencia de desempeño | Depuración (debugging) | Mejor rendimiento en debugging |
No es “la IA”: es cómo se usa
Un matiz clave del trabajo es que la degradación no fue inevitable. La investigación identificó seis patrones de interacción: tres asociados a bajo rendimiento y tres a mejores resultados. El divisor no fue la herramienta, sino el nivel de “delegación mental”.
Patrones de peor aprendizaje (alto “cognitive offloading”):
- Delegación total: pedir a la IA que escriba y cierre la tarea. Rápido, pero con comprensión muy baja.
- Dependencia progresiva: empezar consultando y acabar entregando todo a la IA.
- Depuración delegada: usar a la IA como “mecánico” constante del código, en lugar de como apoyo para entender.
Patrones con mejor aprendizaje (IA como tutor, no como sustituto):
- Generar y luego comprender: pedir código, pero después forzar explicación, revisión y razonamiento propio.
- Generación con explicación obligatoria: solicitar siempre el “por qué” junto al “cómo”.
- Consulta conceptual: preguntar por conceptos, límites y modelos mentales, y escribir el código con ese entendimiento.
La investigación incluso describe algo que muchos equipos ya han observado en la práctica: algunos participantes invirtieron hasta 11 minutos —un 30% del tiempo disponible— redactando consultas a la IA. Es decir, la supuesta “velocidad gratis” se puede convertir en tiempo de interacción que no siempre produce aprendizaje.
El problema empresarial: productividad hoy, cantera mañana
La discusión no se queda en pedagogía. Se conecta con un dilema de empresa: si la IA reduce la necesidad de tareas repetitivas, la tentación natural es contratar menos juniors. El riesgo llega después: sin una base de perfiles en formación, ¿de dónde saldrán los seniors dentro de cinco o diez años?
Aquí conviene separar correlación de causalidad, pero el contexto es revelador. Un informe del Stanford Digital Economy Lab muestra que el empleo de desarrolladores en el tramo inicial (22–25 años) cae con fuerza desde el punto de referencia de octubre de 2022, mientras otros grupos de edad se mantienen más estables o crecen en el periodo analizado. La fotografía no demuestra que la IA sea la única causa, pero sí refuerza la idea de que el “pipeline” junior se está tensando en un momento en el que, paradójicamente, la supervisión humana se vuelve más crítica.
Qué pueden hacer equipos y responsables técnicos (sin prohibir la IA)
La conclusión práctica no es “apagar la IA”, sino diseñar su uso para que no destruya aprendizaje.
1) Definir modos de uso según el tipo de tarea
- Aprendizaje y librerías nuevas: IA como tutor. Preguntas conceptuales, ejemplos mínimos, explicación de errores.
- Trabajo rutinario y conocido: IA como acelerador. Generación de boilerplate, refactors repetitivos, documentación.
2) Obligar a “explicar antes de pegar”
Un cambio cultural simple: si alguien pega un bloque generado, debe poder explicar qué hace, qué asume y cómo fallaría. Es una regla barata y tremendamente efectiva.
3) Depuración manual como requisito
Si el estudio señala que el debugging es la grieta principal, el antídoto es evidente: prácticas deliberadas de depuración sin asistencia, al menos en etapas formativas.
4) Revisiones de código orientadas a comprensión
No basta con “pasa los tests”. En reviews de juniors, pedir que describan el flujo, puntos de fallo y alternativas. La IA puede ayudar, pero la responsabilidad debe quedarse en la persona.
5) Métricas que no solo midan velocidad
Si solo se premia “cerrar tickets”, el incentivo empuja a delegar. Si se mide también calidad, resiliencia y comprensión (por ejemplo, incidencias evitadas o postmortems), el equilibrio cambia.
Una advertencia que llega desde dentro
Que una empresa de IA publique un resultado así es, por sí mismo, un mensaje: la industria empieza a reconocer que hay trade-offs reales. La productividad no siempre es una autopista hacia la competencia. Y en software —donde los fallos se pagan en incidentes, seguridad y reputación— perder habilidades básicas de comprensión y depuración no es un detalle: es un riesgo operativo.
La pregunta, por tanto, no es si los equipos usarán IA. Esa parte ya está decidida. La pregunta es si sabrán usarla sin hipotecar la capacidad de formar ingenieros que, cuando toque, puedan supervisar sistemas críticos sin depender de una respuesta generada.
Preguntas frecuentes
¿Usar asistentes de IA para programar empeora siempre la comprensión del código?
No necesariamente. La evidencia sugiere que depende del patrón de uso: si se delega la solución completa, baja la comprensión; si se usa para preguntas conceptuales y explicaciones, el impacto puede mitigarse.
¿Por qué el debugging es la habilidad más afectada por los copilotos de IA?
Porque depurar exige construir un modelo mental del sistema, formular hipótesis y validar causas. Si la IA “resuelve” ese proceso, se reduce el entrenamiento real de esa capacidad.
¿Cómo debería usar un junior herramientas tipo Claude o Copilot sin “atrofiarse”?
Como tutor: pedir explicaciones, alternativas, límites del enfoque y análisis de errores; y reservar la generación automática para partes mecánicas, no para la lógica central.
¿Qué políticas de empresa ayudan a evitar la pérdida de habilidades en equipos de desarrollo?
Separar “modo aprendizaje” de “modo producción”, reforzar revisiones orientadas a comprensión, exigir explicación de cambios generados y practicar depuración manual de forma periódica.
vía: anthropic
