¿Sigue importando el lenguaje que conoces?

Pasaste años haciéndote bueno en un lenguaje. Aprendiste sus reglas, luego sus mañas, luego esas pequeñas verdades feas que solo se aprenden publicando cosas hechas con él y viéndolas romperse. Y ahora un modelo escribe ese lenguaje con fluidez, y todos los demás también, en cuanto se lo pides. Así que llega la pregunta, en alguna de sus versiones: ¿sigo con lo que sé o me paso a eso a lo que todo el mundo se está pasando? El miedo que hay debajo es más simple que la pregunta. ¿Dejaron de contar los años, sin más?

El lenguaje son dos cosas

Está el lenguaje como tecleo: su sintaxis, la forma de un bucle, dónde van los puntos y comas. Y está todo lo que hay debajo: cómo gestiona la memoria, cómo maneja dos cosas que ocurren a la vez, los modos de fallo que son suyos y de ningún otro, los idioms que son correctos y los que solo parecen correctos, el ecosistema y las herramientas que crecieron a su alrededor. La IA abarató el tecleo. El resto apenas lo ha tocado, y hay una razón. El resto no está realmente en el texto. Vive en sistemas en marcha y en la memoria de lo que se rompió, y un modelo aprende de texto. Por eso la mitad profunda no se limitó a sobrevivir al cambio. Es la mitad que el cambio volvió escasa.

Fíjate en qué bugs se volvieron fáciles

Los errores contra los que protegía la fluidez superficial son exactamente los que el modelo ahora evita y el compilador siempre cazó: una palabra clave equivocada, un trozo de sintaxis mal usado, una llamada a algo que no existe. Lo que queda son los errores que solo la profundidad detecta: el agujero de seguridad que se lee como código normal, la decisión de diseño que está mal aunque cada línea esté bien, el bug de concurrencia que no puedes ver en ninguna línea concreta. La IA limpió los errores baratos y dejó los caros, y los baratos eran los únicos que el conocimiento superficial llegaba a cazar.

La profundidad es una alarma que salta sola

Hay una sensación que todo desarrollador con experiencia conoce. En el lenguaje que conoces a fondo, el código equivocado hace saltar una alarma antes de que puedas decir por qué. Algo en su forma no cuadra, así que te paras y miras. En un lenguaje que solo conoces a medias, esa alarma nunca salta. El código parece plausible, así que lo aceptas. Un modelo produce código plausible por construcción, página tras página. Los tests cazan parte de lo que tiene mal, y puedes apuntar un segundo modelo contra el primero, pero una suite solo comprueba los fallos que a alguien se le ocurrió anotar, y los modelos entrenados con el mismo código comparten los mismos puntos ciegos. Al final, lo que se interpone entre lo plausible y lo correcto es un lector cuya alarma todavía funciona. Ese lector es alguien que conoce el lenguaje a fondo. No hay atajo hacia la alarma.

Cambia por una razón, no por un estado de ánimo

Los costes de cambiar se dividen igual que el lenguaje. Puedes estar escribiendo código de aspecto plausible en un lenguaje nuevo esa misma tarde, y esa parte antes llevaba meses. Los idioms, el runtime, la manera concreta en que falla ese lenguaje en particular, poco de eso se transfiere entre lenguajes que son extraños entre sí. Entre parientes cercanos, lenguajes que comparten modelo de ejecución, pasa más, y ese es el único atajo real que existe. El resto todavía hay que ganárselo. Lo que se transfiere del todo es la parte que nunca fue del lenguaje: cómo descompones un problema y cómo razonas sobre un sistema.

Así que cambia cuando haya una razón real, un dominio que lo exige, un trabajo que quieres, un problema para el que ese lenguaje fue construido, y no porque el ruido subió de volumen. Algunos dominios deciden el lenguaje por ti. El trabajo en tiempo real y en sistemas embebidos no puede permitirse un garbage collector que pausa en el momento equivocado, así que los lenguajes de sistemas son dueños de ese terreno, y el navegador es el navegador; en ambos casos, el lenguaje representa un modelo de ejecución que tienes que sostener en la cabeza, y ninguna fluidez de un modelo cambia lo que va a hacer el hardware. El machine learning pertenece a Python por otra razón, el ecosistema, y el efecto es el mismo.

Mira el movimiento concreto que tanto angustia a la gente: seguir con C++ o ponerse con Rust. Planteado como qué lenguaje gana, no tiene respuesta limpia y la discusión nunca termina. Visto desde la profundidad, hay menos que discutir. Si conoces bien C++, la mayor parte de lo que Rust te pide, pensar en serio en ownership y lifetimes, es peso que ya venías cargando, solo que ahora el compilador lo carga contigo. Eso se parece más a subir de nivel que a empezar de cero. Y la versión adulta del movimiento no suele ser un cambio limpio, sino saber lo suficiente de cada uno para trabajar donde cada uno encaja. El error era tratarlo como una disyuntiva.

El mercado también opina

Hay una razón más para cambiar, y es la menos romántica: la puerta. Cuánto importa la etiqueta de tu experiencia depende de cómo te ganas la vida. Construye tu propio producto y nadie que lo compre pregunta en qué está escrito. Ayuda a otros a construir el suyo, consultoría, freelance, trabajo de agencia, y trabajas dentro de su stack, así que el tuyo tiene que quedar lo bastante cerca como para que te contraten. Y en la contratación a secas, la etiqueta puede decidirlo todo antes de que un humano lea tu nombre. El filtro quiere años de un framework concreto, y la profundidad en un lenguaje vecino no te consigue la entrevista.

El mercado también tiene temporadas. La demanda de los lenguajes crece y se encoge en ciclos que tienen poco que ver con el mérito, y un stack que llenó una década de ofertas de empleo puede quedarse en silencio mientras uno que nunca tocaste aparece en cada anuncio. Eso no es una razón para perseguir cada temporada. Es una razón para saber a qué juego estás jugando. Si tus ingresos pasan por los stacks de otros, mantén al menos un lenguaje que el mercado quiera esta temporada, y usa la máquina para lo que ahora hace bien, llevarte rápido a lo plausible en un stack nuevo, mientras tú haces la parte que ella no puede: construir la profundidad suficiente para defender el código en la entrevista y después de que te contraten. La casilla abre la puerta, y la profundidad es lo que te mantiene dentro.

Dónde paga la profundidad y dónde no

Nada de esto deja sin valor la amplitud. Un segundo lenguaje, sobre todo uno que piensa distinto del primero, afina cómo ves el primero, y la IA hace que trastear salga barato, así que dar una vuelta por ahí ya casi no cuesta nada. Lo que perdió valor es la amplitud como pila de sintaxis, cinco lenguajes que sabes teclear y ninguno que sepas defender.

La profundidad tampoco paga en todas partes. Para un script desechable, un poco de pegamento, un prototipo que vas a borrar el viernes, el modelo iguala el terreno y el lenguaje apenas importa. La profundidad se gana el sueldo en el código que vive: el sistema maduro donde el rendimiento o la seguridad importan de verdad, el código que seguirás manteniendo dentro de tres años.

La parte incómoda es que las repeticiones que antes construían profundidad venían gratis con el trabajo, y ya no vienen. Escribías los bucles tú mismo, te dabas contra los bugs baratos, los arreglabas, y la profundidad se acumulaba como efecto secundario. Esa parte ahora la hace la máquina, así que las repeticiones hay que elegirlas a propósito. Depura el código generado en vez de regenerarlo. Lee el diff como lo leería un revisor. Rompe algo adrede para ver cómo falla. Antes la profundidad te pasaba; ahora tiene que ser una decisión.

Esto es una idea antigua que vuelve a la superficie: la producción mecánica de código nunca fue aquello por lo que te pagaban, y ahora es la parte que hace una máquina. Lo que queda es el criterio, y el criterio en programación no es independiente del lenguaje como nos gusta fingir. Buena parte de él vive dentro de un runtime, aprendido por la vía lenta, construyendo cosas en él y estando ahí cuando fallaron.

Así que los años sí contaron. La parte que perdió valor nunca fue la que llevaba la cuenta. La sintaxis que memorizaste vale menos ahora, y nunca valió mucho. El modelo del lenguaje que construiste por debajo, lo bastante profundo para saber cuándo el código generado te está mintiendo, vale más que nunca. Aprende un lenguaje lo bastante bien como para revisarlo.