Tenés que escribir el código. Cómo aprender a programar en tiempos de IA

Hace unos días di una charla a estudiantes universitarios, me pidieron que hable sobre mi trayectoria en tecnología y open source y también sobre el futuro. Una parte generó bastante conversación después: cómo veo la programación en la era de la inteligencia artificial, y sobre todo, cómo aprender en estos tiempos. Este post es esa parte de la charla, por escrito y con un poco más de detalle.

Una aclaración honesta antes de arrancar: los proyectos open source de los que hablé en la charla (dolarPy, ListaHu, AyudaPy, AireLib.re) no salieron de un prompt, pero no por disciplina mía, sino porque las herramientas de IA no existían cuando los hice. (Por suerte) me tocó aprender de la única forma que había: escribiendo, frustrándome y preguntando en la comunidad. Hoy creo que esa forma sigue siendo la que mejor funciona, y de eso va este post.

Sí, y...

Esta parte está inspirada en un ensayo de Carson Gross, el creador de htmx y profesor de Computer Science en la Universidad de Montana. El ensayo responde una pregunta que mucha gente se hace hoy: si la IA genera código, ¿vale la pena aprender a programar?

Su respuesta es "sí, y". Sí, porque programar es resolver problemas con computadoras y controlar la complejidad de esas soluciones, y eso no pierde valor con la IA, lo gana. Y porque además hay que aprender a usar la IA bien. La pregunta no es "¿programo o no?", sino cómo programás en este nuevo contexto.

Tenés que escribir el código

Esto es especialmente para los que están arrancando, aunque aplica para todos: la única forma de aprender es escribiendo el código. Si tenés una herramienta que te genera la solución y la usás para todo, no vas a aprender y esto no es una cuestión de tecnología, es una cuestión cognitiva y de didáctica. Si no hacés, no aprendés. Así funcionamos los humanos.

Como dice Gross, si generás el código en vez de escribirlo, te robás a vos mismo el entendimiento visceral que solo se desarrolla en la frustración. Y sí, esta carrera tiene un lado de frustración. Es normal, y es importante: esa frustración de pelear con un problema es lo que hace que los conceptos queden.

Hay una consecuencia directa que me parece la más importante de todas: si no escribís código, no vas a poder leerlo. Y si no podés leer código, no podés revisar lo que la IA te genera, no podés corregirlo, y terminás creando sistemas que no entendés y no controlás.

Un consejo concreto que doy dese siempre, inclusive antes de los LLMs: si van a copiar código de algún lado, no hagan Ctrl+C, Ctrl+V. Miren y escriban. Aunque parezca lo mismo, no lo es. Tipear el código es parte de cómo se aprende.

Yo mismo estoy aplicando esto ahora: estoy aprendiendo Rust, que tiene paradigmas distintos a los que estoy acostumbrado y no le pido a la IA que me genere el código. Porque si lo hago, no aprendo. Con veinte años programando esto sigue siendo verdad.

El mito del compilador

Hay un argumento que se escucha seguido: "esto es como cuando se pasó de assembly a los lenguajes de alto nivel; promptear es el nuevo nivel de abstracción". Hasta cierto punto es viable la comparación, pero tiene un problema.

Los compiladores son deterministas: mismo input, mismo output, siempre. Los LLMs no. Ya lo habrán experimentado: le hacés la misma pregunta dos veces y te da respuestas distintas. Para preguntar por el clima quizas no importa mucho, pero para construir sistemas, importa muchísimo.

Los compiladores eliminan complejidad accidental (la complicación que no viene del problema sino de cómo lo resolviste). Los LLMs muchas veces no la eliminan, e incluso la agregan, con atajos y enfoques inapropiados. Y acá vuelve el punto anterior: ¿cómo te das cuenta de que el enfoque es malo si no aprendiste a leer código?

Un ejemplo real: reportes de seguridad con IA

En authentik, donde trabajo, recibimos reportes de seguridad de gente que encuentra problemas. Cuando explotó el tema de los LLMs, empezamos a recibir reportes de bajísima calidad: señalaban problemas en partes del código que ni siquiera existían.

Las herramientas mejoraron, hoy a veces encuentran cosas válidas y suelen incluir un fix propuesto. Pero acá viene lo interesante: en la gran mayoría de los casos, ese fix "funciona" pero no resuelve el problema de fondo. Si aplicáramos lo que dice la IA, estaríamos metiendo parche sobre parche, y el día que alguien cambie una variable, el mismo problema vuelve a aparecer.

La única forma de identificar eso es conocer el código y tener los fundamentos para entender por qué pasó y qué hay que hacer de verdad. El código que en teoría es correcto puede ser una mala decisión igual y eso no te lo dice el modelo: lo tenés que saber vos.

El lado positivo: la IA como asistente de cátedra

No todo es negativo. Hay una forma de usar la IA que me parece genuinamente buena para aprender: como un TA, tutor o ayudante/asistente de cátedra.

Usala para que te explique conceptos. Para destrabarte de la complejidad accidental que no es programación en sí: instalar Python, configurar un entorno, esas cosas que antes te frenaban días hasta encontrar a alguien que te explique (particularmente creo que hay valor en aprender a hacer eso manualmente pero puede frenar el momentum a mucha gente). Para hacerle preguntas sobre un codebase enorme y abrumador. Usada así, la IA puede incluso acelerarte en tu camino de aprendizaje.

Yo uso estas herramientas, pero trato de hacerlo de la forma más acotada posible. No le pido soluciones enteras; le pido cosas puntuales, sobre todo en tareas donde ya sé cómo tiene que verse el resultado final. Eso acelera mi trabajo sin entregarle el criterio de decisión, porque al final yo soy el responsable del código y de lo que hace.

¿Y cómo se configura esto en la práctica? La mayoría de las herramientas (Claude, ChatGPT, Gemini) aceptan un archivo de configuración que define cómo se comportan. Generalmente se llama AGENTS.md (en Claude es CLAUDE.md, pero funciona igual). La idea es decirle: no me des la respuesta directa, dame pistas, preguntame qué probé, explicame los conceptos. Que te haga pensar en vez de escupir código.

Preparé una versión en español, basada en la que usa Carson Gross con sus alumnos, que pueden descargar y usar: gist.github.com/melizeche. Si están aprendiendo, esto hace que la IA no les quite justamente la parte de aprender.

Los fundamentos no caducan

Hay algo que mucha gente no termina de entender: el trabajo de un desarrollador o ingeniero no es escribir código. Es resolver problemas y el código es simplementa la herramienta para lograrlo, no el objetivo. Y programar nunca fue teclear: comunicación, entender el problema y diseñar sistemas siempre fueron parte del oficio. La IA no inventa nada de eso, solo lo hace más visible.

Si lo que importa es resolver el problema, entenderlo de punta a punta es innegociable. No podés delegar a ciegas lo que no entendés. Y ojo que esto no va por el lado moral de "es de perezoso pedirle a la IA". El problema es práctico: el código que no entendés genera complejidad innecesaria, y va a llegar el punto en que quieras cambiar algo y se te rompa en mil partes sin que sepas por qué. Eso ya le pasó a mucha gente con proyectos vibe-codeados que después tuvieron que reescribir, o pagar a alguien que entienda para que los arregle.

Seguí el incentivo

Cada tanto aparece alguien diciendo que en seis meses los programadores ya no van a ser necesarios. Mi recomendación: antes de asustarte, preguntate qué incentivo tiene quien lo dice.

Quien dice que la IA reemplaza a los programadores casi siempre te vende algo. Puede ser la herramienta, el curso para "no quedar obsoleto", o humo a los inversores. Cuando el CEO de una empresa de IA anuncia que en equis tiempo los programadores van a sobrar, o que su nuevo modelo es tan peligroso que solo ellos pueden contenerlo, eso mueve el precio de sus acciones. Es un juego de inversiones, no es un pronóstico desinteresado.

Del otro lado, la gente que conozco que trabaja en esto todos los días, sin nada que venderte, suele tener un mensaje mucho más aburrido: usá la IA, pero escribí el código. Nadie se hizo rico diciendo eso, y por ahí justamente va el punto.

Hoy la IA es barata. ¿Y mañana?

Otra cosa a tener en cuenta: hoy podés usar estas herramientas gratis o por una suscripción de 20 dólares. Ese no es el precio real de operarlas. Está fuertemente subsidiado con capital de riesgo, operando a pérdida, con la jugada de siempre: que sea barato hasta que estés acostumbrado, y ahí subir el precio, cuando ya dependés.

Ya vimos esto con Uber. Cuando llegó era baratísimo, mucho más que el taxi. Se llevó todo el mercado operando a pérdida, y después subió los precios. Hoy en la mayoría de ciudades casi no quedan taxis, y dependemos de estas plataformas.

Con la IA puede pasar lo mismo, y el costo de mañana no lo conoce nadie. De hecho ya hay empresas grandes reconociendo que se consumieron el presupuesto anual de IA en tres meses sin ver la productividad prometida. Si solo sabés programar con la herramienta, el día que suban el precio quedás a merced de un costo que no controlás y hasta podés quedar afuera de tu propia profesión.

Saber programar sin la herramienta es tu seguro. No apuestes tu carrera a que la canilla libre dure para siempre.

Ya vimos esta película

Cada tantos años aparece la tecnología que "lo cambia todo" y si no te metés "te quedás sin trabajo".

A comienzos de los 2000 eran las herramientas no-code y low-code: diseñabas unos diagramas UML, conectabas cajitas y ya no ibas a programar nunca más! Funcionaban fantástico para los demos; cuando tenías que trabajar en serio o proyectos más complejos, dejaban de ser suficientes y volvías a tocar código.

Después fue Big Data: hace 10 o 15 años todo era Big Data y si no lo entendías te quedabas afuera y sin trabajo. ¿Qué pasó? El hype pasó, y quedó una herramienta útil y hasta una profesión nueva (data science).

Más cerca en el tiempo: blockchain hasta en la sopa, NFTs, el metaverso. Hasta Facebook se cambió el nombre a Meta apostando a eso. Hoy, ¿qué quedó?

El patrón se repite: lo que era humo se evapora, lo que tenía sustancia queda y se vuelve una herramienta más, normal e invisible. Yo creo que a la IA le va a pasar eso. Ni apocalipsis ni magia.

No te paralices con el ruido ni te dejes arrastrar por él y seguí construyendo sobre fundamentos.

En resumen

Si estás aprendiendo a programar hoy:

Escribí el código. La frustración es parte del aprendizaje, no un bug. Usá la IA como tutor, no como generadora de soluciones (el AGENTS.md ayuda con eso). Desconfiá de quien te vende miedo o magia, y preguntate siempre qué incentivo tiene. No dependas de una herramienta cuyo precio no controlás. Y recordá que el trabajo nunca fue teclear: es resolver problemas, y eso se aprende resolviéndolos.

Esto es lo que a mí me funcionó; tu camino puede ser otro y estar perfecto. Pero de algo estoy bastante seguro: el hype va a pasar, las herramientas van a cambiar de precio y de nombre, y la gente que entiende lo que construye va a seguir teniendo trabajo.

Mientras tanto, empezá por lo más simple: escribí el código.