Llevo más de cuarenta años escribiendo código. No digo esto para impresionar a nadie, sino para situar lo que voy a contarte: cuando digo que he visto cambiar la programación desde dentro, lo digo literalmente. He programado en ensamblador, en Basic, en COBOL, en FORTRAN, en Pascal, en C, en Lisp, en Prolog, en Python. He visto aparecer los lenguajes de cuarta generación, la programación orientada a objetos, los frameworks, los repositorios abiertos, los entornos de desarrollo que te corregían mientras escribías. He vivido cada una de esas revoluciones con la emoción del que sabe reconocerlas cuando llegan.

Y sin embargo, cuando empecé a usar los grandes modelos de lenguaje para programar, tardé tiempo en entender lo que estaba pasando de verdad. No lo que hacía la herramienta. Eso era visible desde el primer día. Lo que tardé en entender fue de dónde venía esa capacidad. Quién le había enseñado. Y sobre todo, qué significa que lo que me enseñó a mí, durante décadas, es exactamente lo que le enseñó a ella.

El maestro y el alumno compartiendo aula

Cuando aprendes a programar, aprendes dos cosas distintas que con el tiempo se vuelven inseparables. Aprendes la sintaxis, que es la parte que cualquiera puede memorizar. Y aprendes a resolver problemas, que es la parte que nadie puede simplemente memorizar porque tiene que construirse encima de miles de intentos, de errores, de caminos que no llevan a ningún sitio y que sin embargo te enseñan algo.

Esa segunda parte, la de resolver problemas, es la que más tiempo lleva. La que más frustra. La que hace que muchos abandonen. Y es también, precisamente, la que más diferencia a un programador competente de uno extraordinario.

Durante décadas, los programadores aprendíamos esas habilidades de varias fuentes: los libros, los mentores, la documentación técnica, los foros, los proyectos de código abierto donde podías leer cómo otros habían resuelto problemas parecidos a los tuyos. Y más tarde, a partir de los años noventa, algo que cambió el juego por completo: las comunidades online. Primero los grupos de noticias, luego los foros especializados, y finalmente Stack Overflow, que se convirtió en algo así como la memoria colectiva de la programación mundial. Lleva funcionando desde 2008, acumula millones de preguntas y respuestas reales, y su modelo de moderación por reputación ha garantizado durante años que lo que sube a la superficie sea, en su mayoría, conocimiento útil y contrastado.

Ese corpus, junto con GitHub y sus cientos de millones de repositorios públicos, con la documentación técnica, con los libros, con los artículos, con el código abierto que millones de personas han publicado a lo largo de décadas, es lo que han leído los modelos de lenguaje. Es su formación. Su escuela. El material sobre el que construyeron su capacidad para entender un problema, sugerir un enfoque, escribir código funcional, detectar un error. Modelos como StarCoder, uno de los más documentados en cuanto a su proceso de entrenamiento, se construyeron sobre más de 600 lenguajes de programación y una masa ingente de issues, pull requests, notebooks y documentación técnica acumulada durante décadas por la comunidad global de desarrolladores.

Dicho de otra manera: la IA aprendió a programar leyendo lo que nosotros escribimos cuando aprendíamos a programar.

Lo que eso cambia, y lo que no

Hay algo que me resulta profundamente curioso en esto, y que creo que vale la pena detenerse a considerar. La IA no inventó nuevas formas de resolver problemas de programación. Destilú las que ya existían. Aprendió los patrones, las heurísticas, los atajos, los errores más comunes y cómo evitarlos. Aprendió a reconocer cuándo un problema se parece a otro que ya tiene solución conocida. Y aprendió el lenguaje con el que los programadores piensan cuando programan, que no es solo el lenguaje formal del código, sino también el lenguaje informal de quien está atascado a las once de la noche y escribe en un foro «no entiendo por qué esto no funciona».

Eso explica muchas cosas. Explica por qué la IA es tan buena con los lenguajes y frameworks más populares, los que tienen más representación en ese corpus de aprendizaje, y menos fiable con los más oscuros o recientes. Explica por qué se maneja mejor con problemas que siguen patrones conocidos que con problemas genuinamente novedosos. Y explica también por qué, cuando le pides que resuelva algo, a veces lo hace de una manera que reconoces inmediatamente como la que habrías encontrado tú en Stack Overflow hace diez años, con sus virtudes y sus limitaciones.

Programar no es escribir: es construir sobre un precipicio

Pero hay algo que esa explicación no captura del todo, y que quiero poner sobre la mesa porque me parece fundamental para entender lo que está ocurriendo ahora.

Programar con una sintaxis formal no es como escribir en lenguaje natural. En lenguaje natural, un error tipográfico no impide que te entiendan. Una frase mal construida comunica igual. Hay margen. Hay contexto. El receptor interpreta y suple. En programación, no. Una coma en el lugar incorrecto, un paréntesis que no cierra, una variable mal nombrada en un sistema que la espera de otra manera: cualquiera de esas cosas hace que el programa no funcione. No que funcione peor. Que no funcione. El intérprete no perdona, no interpreta intenciones, no da el beneficio de la duda. O es exactamente así, o es un error.

Eso significa que programar requiere un tipo de atención sostenida y de precisión que no tiene equivalente fácil en otras disciplinas. Y significa también que el espacio de los errores posibles es enorme: puedes tener la lógica perfectamente clara en tu cabeza y que el programa falle por un detalle de sintaxis que tu ojo cansado pasó por alto. O tener la sintaxis impecable y que la lógica tenga un agujero que solo aparece con ciertos datos, en cierta secuencia, bajo ciertas condiciones que nadie probó durante el desarrollo.

Yo aprendí eso a base de horas. Y de noches. Y de depuraciones que empezaban con la certeza de que el error estaba en un sitio y terminaban, horas después, descubriendo que estaba en otro completamente distinto. Eso es lo que construye el criterio. La capacidad de leer un bloque de código y sentir que algo no encaja antes de saber exactamente qué. El olfato que no se adquiere leyendo manuales.

Entonces llega la IA, y hace algo que no esperaba

Lo que me sorprendió cuando empecé a usar modelos de lenguaje para programar no fue que supieran escribir código. Era previsible que lo hicieran, dado el corpus del que habían aprendido. Lo que me sorprendió fue otra cosa: la forma en que se enfrentaban a un problema.

Porque la IA no solo escribe código. Cuando le planteas un problema de programación real, hace algo que, si lo describes con honestidad, se parece mucho a pensar. Analiza el código existente antes de proponer nada. Identifica las dependencias, los puntos de fricción, los lugares donde una intervención podría generar efectos no deseados más adelante. Y entonces no da una respuesta: da varias. Propone soluciones distintas, explica el razonamiento detrás de cada una, señala las ventajas e inconvenientes de cada enfoque según el contexto. Y después, si se lo permites, ejecuta.

Eso no es buscar en una base de datos. Eso no es autocompletar. Eso es razonar sobre un problema con información incompleta, sopesar alternativas y tomar una decisión fundamentada. Que es, exactamente, lo que hacemos los programadores cuando trabajamos bien.

Entender esto cambió mi manera de relacionarme con estas herramientas. Dejé de verlas como generadores de código y empecé a verlas como lo que en realidad son: interlocutores técnicos con los que puedes razonar. Que se equivocan, sí. Que tienen puntos ciegos, también. Pero que, usados con criterio, amplían de manera genuina lo que un programador puede hacer. No lo sustituyen: lo multiplican. Como conté en «Cuando la inteligencia cueste menos que un café», el verdadero peligro no es que la IA desplace a los desarrolladores que la usan. Es que desplace a los que no.

La herramienta que aprende de tus decisiones

Hay algo más que me parece importante señalar, y es que la relación entre el programador y la IA no es pasiva en una sola dirección. Cuando usas un modelo de lenguaje para programar, no solo recibes sugerencias: estás generando datos. Estás mostrando cómo piensas, qué rechazas, qué aceptas, qué corriges. Y esos datos, en alguna medida, forman parte de lo que informa el aprendizaje futuro de estos sistemas.

Es una relación más parecida a la que tenías con un mentor de verdad que a la que tienes con un libro de texto. Un buen mentor no solo te transmite conocimiento: aprende de cómo tú lo absorbes, de qué preguntas haces, de dónde te atascas. La diferencia es que un mentor humano aprende de ti durante el tiempo que duró vuestra relación. Un sistema de IA aprende, en potencia, de millones de interacciones simultáneas.

Eso hace que la calidad de lo que introduces en el sistema importe más de lo que parece. No solo para ti, en términos de lo que obtienes a cambio, sino en un sentido más amplio. Si los programadores que usan IA delegan sistemáticamente las decisiones más difíciles, el corpus de aprendizaje futuro reflejará esa tendencia. Si en cambio la usan para ampliar su capacidad de pensar, como planteé en «¿Te está haciendo la IA más capaz o más dependiente?», el resultado es completamente otro.

Lo que cuarenta años me han enseñado sobre aprender

He aprendido lenguajes de programación suficientes como para saber que el lenguaje no es lo más difícil. Lo más difícil es aprender a pensar en términos de problemas descomponibles. A ver un sistema complejo y saber por dónde empezar. A reconocer cuándo una solución elegante existe y cuándo hay que conformarse con una solución funcional. A entender qué hace un código aunque no lo hayas escrito tú. A depurar, que es básicamente el arte de razonar en sentido inverso desde un resultado que no tiene sentido.

Esas habilidades no se aprenden leyendo documentación. Se aprenden resolviendo problemas, equivocándose, volviendo a intentarlo. Y lo que me pregunto, y creo que deberíamos preguntarnos todos los que trabajamos con IA y formamos a quienes la usarán mañana, es si los entornos de aprendizaje actuales siguen generando ese tipo de habilidades. No digo que sea inevitable que no lo hagan. Digo que no es automático. Como señalé en «Del Álgebra al Vibe: Por qué el Vibe Coding es el nuevo Fortran», cada revolución en programación ha liberado a los programadores de una capa de complejidad para que pudieran operar en un nivel más alto. El vibe coding —el término que Andrej Karpathy acuñó en febrero de 2025 para describir la programación por intención en lenguaje natural— es la versión más radical de ese movimiento hasta la fecha. El peligro no es que la capa desaparezca. Es que quien opera en el nivel más alto no entienda lo que hay debajo, que fue exactamente lo que exploré en «El mapa acaba donde empieza la brújula».

Hay un paralelismo que me gusta mucho con la historia del ajedrez. Cuando Deep Blue venció a Kaspárov el 11 de mayo de 1997, parecía que la máquina había matado al ajedrez humano. Lo que ocurrió fue lo contrario: la IA se convirtió en el mejor entrenador que han tenido los jugadores de ajedrez en toda la historia, como conté en «La Paradoja del Tablero». La clave fue que los jugadores usaron la IA para entender mejor el juego, no para sustituir su capacidad de jugarlo. Los que mejor la aprovecharon fueron los que ya sabían jugar bien.

Quién enseñó a la IA a resolver problemas

Volviendo a donde empecé: la IA aprendió a programar leyéndonos. Leyendo nuestras preguntas, nuestras respuestas, nuestro código, nuestros comentarios, nuestras discusiones. Aprendió de lo mejor y de lo peor que hemos producido. Aprendió los atajos brillantes y los antipatrones que llevan a sistemas imposibles de mantener. Es, en ese sentido, un espejo de nosotros mismos como comunidad técnica.

Lo que hagamos con ese espejo importa. Podemos usarlo para ver más claro, para identificar qué sabemos y qué nos falta, para aprender más rápido y con más contexto. O podemos usarlo como sustituto de mirarnos a nosotros mismos, delegando en él las decisiones que son precisamente las que más nos hacen crecer.

Y aquí hay algo que no es poco: la IA aprendió a resolver problemas de programación. Pero no aprendió a tener el criterio para saber qué problema merece ser resuelto, ni por qué, ni de qué manera encaja con el mundo que existe más allá del código. Eso sigue siendo nuestro. Y si lo ejercitamos, también lo seguirá siendo mañana.

La inteligencia que le enseñamos a la máquina es exactamente tan buena como la que nosotros ejercitamos al enseñarla.