¿Copilot te está volviendo peor programador?

"¿Copilot me está volviendo peor programador?" es una de esas búsquedas que la gente escribe a las 11 de la noche después de un mal día, medio esperando que la respuesta sea que no. La respuesta honesta es más útil que un simple sí o no: Copilot no te está volviendo más torpe, pero sí está cambiando en silencio cuál de tus habilidades se ejercita todos los días, y cuál no.

Esa distinción importa, porque las dos cosas que la gente suele preocuparse por perder, entender el software y poder construirlo, en realidad no son lo que se erosiona. Lo que se erosiona es algo más acotado y específico, y una vez que sabes exactamente qué es, es mucho más fácil de proteger.

Lo que Copilot realmente reemplaza

Copilot no escribe tu arquitectura. No decide qué construir, no depura un problema complicado de producción ni lee por ti el código desconocido de un compañero. Lo que reemplaza, muy efectivamente, es el acto pequeño y mecánico de recordar: el nombre exacto del método, la sintaxis del bucle, el orden de los argumentos, eso que tus dedos solían saber sin que tu cerebro tuviera que intervenir. Esa es una habilidad real, y es la que está en juego acá — no tu criterio, no tu capacidad de resolver problemas, solo tu recuerdo de mano a teclado de la sintaxis.

Las habilidades que no se erosionan

El diseño de sistemas, depurar, revisar código, saber qué construir en primer lugar, leer código que no escribiste: nada de eso depende de escribir un bucle de memoria. Si estás haciendo trabajo de ingeniería real día a día, ese lado de tu habilidad, si acaso, se sigue ejercitando constantemente. Vale la pena decirlo con claridad, porque el miedo debajo de "¿Copilot me está volviendo peor?" suele ser en realidad un miedo sobre la competencia en general, y ese miedo es en su mayoría infundado.

La habilidad que sí se erosiona en silencio

Lo que realmente se atrofia es la automaticidad: la parte de programar que solía pasar sin pensamiento consciente. Ya sea .length o len() para el lenguaje en el que estás ahora. Si un chequeo in de Python se traduce al .includes() de JavaScript. El músculo que te permite escribir un bucle for sin una pausa de medio segundo para recordar su forma. Nada de eso aparece en tu trabajo diario hasta el momento exacto en que sí aparece: una entrevista, una laptop rota, una sesión de pair programming donde compartir tu pantalla significa compartir también el vacío del autocompletado.

Cómo saber si te está pasando

• Recurres al autocompletado para cosas que antes simplemente escribías. Métodos básicos de arreglos, operaciones comunes de cadenas, lo que debería ser reflejo.
• Dudas al escribir un bucle desde un archivo en blanco. No porque no entiendas los bucles, sino porque la sintaxis exacta no te sale de inmediato.
• Te has descubierto escribiendo sintaxis del lenguaje equivocado. Con confianza, no como un error de tipeo — la señal específica de que un hábito se cruzó, no de que falte un concepto.
• Un pizarrón o un IDE roto se sienten desproporcionadamente más difíciles de lo que deberían. Si la brecha entre "puedo construir esto" y "puedo escribirlo sin ayuda" se siente grande, esa es la brecha de automaticidad, no una brecha de competencia.

No tienes que elegir entre la IA y la habilidad

La solución no es renunciar a Copilot — eso sería como evitar una calculadora para seguir siendo bueno dividiendo a mano por principio, no porque importe. La solución es asegurarte de que no sea la única forma en que escribes código. Unos minutos al día de práctica genuinamente sin asistencia, sin autocompletado, sin sugerencias, alcanzan para mantener vivo ese reflejo específico sin renunciar a nada de la productividad real que te da la asistencia de IA el resto del tiempo.

Esa es exactamente la brecha que SoloScript está construido para cerrar: ejercicios cortos y sin asistencia en el lenguaje que realmente usas, para que el músculo de recordar siga ejercitado incluso mientras el asistente se encarga del resto de tu día.