En un post en el blog de Anthropic comparten los resultados de un estudio que intentaba entender el impacto del uso de IA en la adquisición de habilidades técnicas:
En un ensayo controlado aleatorio, examinamos 1) qué tan rápido los desarrolladores de software adquirían una nueva habilidad (en este caso, una biblioteca de Python) con y sin asistencia de IA; y 2) si el uso de IA los hacía menos propensos a entender el código que acababan de escribir.
Los resultados:
Encontramos que el uso de asistencia de IA condujo a una disminución estadísticamente significativa en el dominio de la habilidad. En un cuestionario que cubría conceptos que habían utilizado apenas unos minutos antes, los participantes del grupo de IA obtuvieron una puntuación 17% más baja que aquellos que programaron a mano, o el equivalente a casi dos grados escolares. El uso de IA aceleró la tarea ligeramente, pero esto no alcanzó el umbral de significancia estadística.
Si bien el contexto es el uso de IA, estos resultados no me sorprenden. No por la IA como tal, sino porque esto es exactamente lo que pasa cada vez que una tecnología elimina un problema que antes tenías que resolver manualmente.
Not our first rodeo
Cuando aprendí a programar en Objective-C por ahí de 2008, antes de ARC, cada vez que creabas un objeto en memoria con [[Object alloc] init], tenías que asegurarte de liberar esa memoria con [object release] al terminar de usarlo. Si no lo hacías, tenías un memory leak. En el mejor de los casos tu app se sentía lenta. En el peor, encontrabas un SEGFAULT y tu app se cerraba inesperadamente.
Pero llegó ARC y de repente los que programábamos en iOS ya no teníamos que preocuparnos por cerrar ese ciclo manualmente, porque el sistema lo haría por nosotros. No solamente había que escribir menos código, sino que teníamos una garantía a nivel sistema de que ya no teníamos por qué llevar la cuenta de referencias manualmente.
De un día para otro, ya no teníamos que pensar en eso.
Claro, aparecieron otros problemas, y no fue el final de los bugs en aplicaciones de iOS, pero ese problema ya no existía.
Alguien que decide aprender Swift como su primer lenguaje de programación en 2026 no va a tener que aprender los mismos conceptos de manejo de memoria que yo tuve que aprender hace 20 años; así como yo no tuve que aprender los fundamentales de los registros de procesador que eran vitales cuando ASM era la capa de abstracción más alta que teníamos.
Y mira que yo he podido hacer una carrera en software incluso sin saber cómo mover bits de memoria entre registros manualmente.
La capa de abstracción
Lo que la IA está haciendo para el desarrollo de software es el mismo efecto práctico que los avances en compiladores, tipos de datos y análisis estático de código: al crear una capa de abstracción sobre problemas fundamentales, los programadores pueden dejar de preocuparse de una categoría de problemas por completo.
Este proceso no es una anomalía de la IA, sino la continuación de una inercia histórica.
Cada gran avance en la computación ha consistido en darnos la oportunidad de “ignorar” una dificultad técnica para permitirnos pensar en problemas más complejos. Pasamos de gestionar manualmente bits en registros a delegar la organización de datos al encapsulamiento de C++. De sufrir por el manejo de memoria a confiar en el Garbage Collector de Java. Y de escribir código de infraestructura a definir solo intenciones en Ruby o JS.
Lo que hoy experimentamos con la IA es simplemente el desplazamiento de esa frontera: si antes abstrajimos el hardware y la memoria, hoy estamos abstrayendo la sintaxis misma. El código se está convirtiendo en un detalle de implementación para que el programador pueda enfocarse puramente en la arquitectura y el propósito.
Peor programador, mejor ingeniero
Aquí está el punto que la mayoría de la gente se pierde cuando ve estos estudios. Ser “peor programador” en el sentido de que ya no puedes escribir un algoritmo de ordenamiento de memoria o que necesitas consultar la sintaxis exacta de un decorador en Python no es un bug, sino un feature.
La pregunta nunca ha sido “¿qué tan bien escribes código?”. La pregunta siempre ha sido “¿qué tan bien resuelves problemas?”. Y resolver problemas requiere un conjunto de habilidades completamente distinto: saber qué problema estás resolviendo realmente. No el problema que el usuario te pidió explícitamente, sino el problema subyacente que está causando fricción.
Saber cuándo no escribir código. Cuándo la solución es cambiar un proceso, reorganizar un equipo, o simplemente decir que no. Saber verificar si tu solución funciona. No si compila. No si pasa las pruebas. Si resuelve el problema real para las personas reales que lo tienen.
La IA puede escribir el código. No puede hacer ninguna de estas otras cosas.
De sintaxis a sistemas
Así como alguien aprendiendo Swift hoy no se va a tener que preocupar por el ciclo de retain/release de memoria, y yo no me tuve que preocupar por aprender cómo mover bits entre registros de procesador, la IA lo que está haciendo es elevar la capa de abstracción para que el código, como tal, ya no sea lo importante.
Solo que esta vez, la capa de abstracción está más alta que nunca. Completamente fuera del dominio técnico. Ya no se trata de escribir código sintácticamente correcto. Se trata de saber qué problema resolver y cómo verificar que la solución —la que tú diseñaste y la IA implementó— realmente lo resuelve.
Esa es una habilidad completamente distinta. Y esa es la habilidad que define a un ingeniero.
Si estás navegando esta transición —de escribir código a diseñar sistemas, de ejecutar a decidir qué vale la pena ejecutar— trabajo con personas en tecnología que quieren desarrollar exactamente estas habilidades que la IA no puede abstraer: pensamiento estratégico, arquitectura de soluciones y la capacidad de distinguir entre el problema real y el problema aparente.
Agenda una sesión de descubrimiento y platicamos sobre dónde estás y hacia dónde quieres ir.
Deja un comentario