Lo noté unos seis meses después de usar Copilot de forma habitual. Estaba depurando un script de Python y recurrí al asistente de IA antes de haber leído siquiera el mensaje de error. El traceback estaba ahí mismo — KeyError: 'user_id' — pero mi primer instinto se había convertido en 'pegarlo en el chat' en lugar de 'leerlo y pensar'. Ese momento me inquietó más que cualquier debate sobre si la IA reemplazará a los desarrolladores.
Las herramientas de código con IA están cambiando algo más que nuestra productividad. Están modificando nuestros hábitos cognitivos: cómo abordamos los problemas, cuán profundamente entendemos nuestro código y cómo aprendemos. Algunos de estos cambios son genuinamente positivos. Otros son preocupantes de maneras que no aparecerán en las métricas de productividad.
El marco de Kahneman aplicado al código
La distinción de Daniel Kahneman entre el Sistema 1 (rápido, automático, intuitivo) y el Sistema 2 (lento, deliberado, analítico) se aplica sorprendentemente bien a cómo trabajan los desarrolladores. Leer patrones de código familiares, escribir boilerplate, navegar APIs conocidas — eso es Sistema 1. Depurar condiciones de carrera, diseñar sistemas distribuidos, razonar sobre implicaciones de seguridad — eso es Sistema 2.
Las herramientas de IA para código destacan en las tareas del Sistema 1. Generan boilerplate al instante, completan patrones familiares y manejan las partes mecánicas de la programación que los desarrolladores experimentados hacen en piloto automático. Esto es genuinamente valioso — liberar recursos cognitivos para los problemas difíciles es un beneficio neto.
El riesgo está en que las herramientas de IA también facilitan evitar el pensamiento del Sistema 2 por completo. Cuando la IA sugiere una función completa, aceptarla requiere menos esfuerzo cognitivo que entenderla. Cuando propone una corrección para un bug, la tentación es aplicarla y seguir adelante en lugar de comprender por qué funciona. Con el tiempo, esto puede atrofiar las habilidades analíticas que distinguen a un ingeniero senior de alguien que simplemente sabe teclear.
Lo que realmente está mejorando
Sería deshonesto plantear esto como algo puramente negativo. Las herramientas de IA han mejorado genuinamente algunos aspectos del desarrollo.
Explorar territorio desconocido
Cuando necesito trabajar en un lenguaje o framework que no uso a diario, los asistentes de IA son transformadores. No porque escriban código perfecto — no lo hacen — sino porque me dan un punto de partida que suele ir en la dirección correcta. En vez de pasar una hora leyendo documentación para entender el patrón básico de un pool de conexiones PostgreSQL en Go, obtengo un andamiaje razonable en 30 segundos y dedico esa hora a las partes que realmente requieren criterio.
Esto reduce la barrera para experimentar con nuevas herramientas. He explorado tecnologías que antes habría descartado simplemente porque el coste de entrada parecía demasiado alto. Es un beneficio real — los desarrolladores que pueden trabajar cómodamente en más partes del stack son más efectivos.
Reducir la fricción del cambio de contexto
El desarrollo moderno implica cambiar constantemente de contexto entre lenguajes, frameworks y paradigmas. ¿El test runner de este proyecto es Jest o Vitest? ¿Esta API devuelve promesas o usa callbacks? ¿Este código usa snake_case o camelCase? Las herramientas de IA absorben estos detalles y generan código que se adapta al contexto, reduciendo la fricción al alternar entre proyectos.
Hacer más rápida la revisión de código
Que una IA resuma un diff grande, señale posibles problemas o explique patrones de código desconocidos ha hecho que la revisión de código sea menos tediosa para mí. Sigo leyendo el código yo misma — el resumen de la IA es un punto de partida, no un sustituto — pero me ayuda a enfocar mi atención en las partes importantes en lugar de dedicar el mismo tiempo a cambios de boilerplate y a cambios de lógica compleja.
Lo que está empeorando
La brecha de comprensión
He empezado a notar un patrón en las revisiones de código: los desarrolladores que usan intensivamente herramientas de IA producen código que funciona pero que no pueden explicar del todo. Pregunta '¿por qué usaste un WeakMap aquí en vez de un Map normal?' y obtienes 'la IA lo sugirió' en lugar de una explicación sobre las implicaciones del recolector de basura. El código está bien. La comprensión no.
Esto importa porque la comprensión es lo que te permite depurar bajo presión, extender el código en direcciones inesperadas y tomar decisiones arquitectónicas. Puedes entregar código que no entiendes — la gente lo hace constantemente — pero no puedes mantenerlo, y no puedes enseñar a otros lo que no sabes tú mismo.
El músculo de la depuración
La depuración es una de las habilidades más importantes que puede tener un desarrollador, y es una habilidad que requiere práctica. Leer mensajes de error con atención, formular hipótesis, acotar el espacio del problema, usar un depurador para verificar suposiciones — son comportamientos aprendidos que se fortalecen con el uso y se debilitan con el abandono.
Cuando tu primer instinto es pegar un error en un chat de IA y aplicar cualquier corrección que sugiera, no estás practicando depuración. Estás practicando una habilidad diferente: evaluar si la sugerencia de una IA parece plausible. Eso es útil, pero no es lo mismo. El desarrollador que puede depurar sistemáticamente superará al desarrollador dependiente de la IA cada vez que se enfrente a un problema que la IA no puede resolver — que, en incidentes de producción, es la mayoría de las veces.
El atractor de la mediocridad
Las herramientas de código con IA generan código promedio. Por definición — están entrenadas con la distribución del código existente, así que producen el centro estadístico de esa distribución. Para tareas sencillas, lo promedio está bien. Para tareas donde necesitas una solución elegante, un enfoque creativo o una comprensión profunda del dominio del problema, lo promedio no es suficiente.
He visto a desarrolladores aceptar soluciones generadas por IA que técnicamente funcionan pero que pasan por alto la idea subyacente que haría el código más simple, rápido o mantenible. La IA no sugiere la observación ingeniosa de que 'esto en realidad es un problema de ordenamiento topológico'. Genera una solución de fuerza bruta funcional que nadie cuestiona porque pasa los tests.
El problema del aprendizaje
Para los desarrolladores junior, el impacto es más agudo. Aprender a programar consiste fundamentalmente en construir modelos mentales — entender cómo funcionan las variables, qué sucede cuando llamas a una función, por qué ciertas estructuras de datos son más rápidas que otras. Este aprendizaje ocurre a través de la lucha: escribir código malo, obtener errores, descubrir por qué y desarrollar intuición.
Las herramientas de IA cortocircuitan esa lucha. Un desarrollador junior que obtiene respuestas instantáneas para cada error no desarrolla la misma intuición que uno que pasó 30 minutos leyendo el stack trace y recorriendo el código paso a paso con el depurador. La analogía a la que siempre vuelvo es la navegación GPS: las personas que siempre usan GPS desarrollan un razonamiento espacial más débil que quienes a veces navegan con mapas. El destino es el mismo, pero el modelo mental es diferente.
No estoy diciendo que los desarrolladores junior no deban usar herramientas de IA. Ese barco ya zarpó, y las herramientas genuinamente ayudan con la productividad. Pero hay un argumento a favor de la práctica deliberada sin asistencia de IA — dedicar tiempo a los mensajes de error en crudo, la documentación, el depurador — específicamente para construir la comprensión fundamental que las herramientas de IA tienden a esquivar.
Encontrar el equilibrio
Después de reflexionar sobre cómo han cambiado mis propios hábitos, he establecido algunas pautas que me funcionan. No son reglas universales — cada desarrollador encontrará un equilibrio diferente.
- Lee el error antes de recurrir a la IA. Date 60 segundos con el mensaje de error o el comportamiento inesperado. A menudo, detectarás el problema de inmediato. Si no, entonces pregunta a la IA — pero pídele que explique el error, no solo que lo corrija.
- Entiende antes de aceptar. Cuando la IA sugiere código, léelo como leerías el PR de un colega. ¿Puedes explicar qué hace cada línea? Si no, aprende qué hace o no lo integres. 'Funciona' no es suficiente para código del que eres responsable.
- Usa la IA para las partes aburridas, no para las difíciles. Deja que genere andamiaje de tests, boilerplate de APIs, archivos de configuración y formato de documentación. Haz tú la arquitectura, la selección de algoritmos y la depuración. Las partes difíciles son donde aprendes y donde tu criterio aporta más valor.
- Trabaja sin ella periódicamente. Como con cualquier dependencia de herramientas, es saludable trabajar ocasionalmente sin asistencia de IA. No porque la herramienta sea mala, sino porque necesitas mantener las habilidades que reemplaza. Intento hacer al menos una sesión significativa de depuración por semana sin ayuda de IA.
- Enseña y explica. La mejor prueba de comprensión es poder explicar algo a otra persona. Si no puedes explicar por qué funciona el código generado por IA, no lo entiendes lo suficiente.
El panorama general
Estamos en la fase inicial de un cambio fundamental en cómo se escribe el software. Las herramientas de IA seguirán mejorando — más precisas, más conscientes del contexto, capaces de manejar tareas más grandes y complejas. Los desarrolladores que prosperen no serán los que resistan las herramientas ni los que les deleguen todo. Serán los que usen la IA como palanca mientras mantienen la comprensión profunda que los hace efectivos cuando la IA se queda corta.
La analogía que me resulta más útil no es la de la automatización reemplazando trabajadores — es la de las herramientas eléctricas complementando a los artesanos. Una sierra de mesa no hace obsoleto a un carpintero. Hace más rápida la parte mecánica del corte para que el carpintero pueda dedicar más tiempo al diseño, las uniones y el acabado. Pero un carpintero que nunca aprendió a cortar recto sin la sierra de mesa tiene limitaciones que importan cuando el trabajo requiere herramientas manuales.
La pregunta no es si usar herramientas de código con IA. Es si las estás usando como herramientas eléctricas que amplifican tus habilidades, o como muletas que impiden que esas habilidades se desarrollen. La respuesta cambia según la tarea, el contexto y en qué punto de tu carrera te encuentras. Pero es una pregunta que vale la pena hacerse regularmente — porque la inercia tiende hacia la dependencia, y la intencionalidad es el único contrapeso.