¿Se aprende algo si la IA hace el trabajo por ti? Mi respuesta
Me lo preguntan en cada vídeo. Después de un año largo trabajando así, mi respuesta cambió: se aprende, pero no lo que crees.
Sí se aprende. Pero no se aprende lo mismo, y hay una manera de trabajar con la que no aprendes nada.
Esa es mi respuesta a la pregunta que más me repiten. Hace un tiempo habría contestado otra cosa, así que empiezo contando cómo cambié de opinión.
¿Se aprende de verdad delegando en la IA?
Al principio yo decía que no. Que si le pides el código a una máquina, te quedas igual de ignorante que estabas.
Lo que me hizo cambiar de idea fue darme cuenta de que ya no era verdad en mi caso. Después de un año largo trabajando así, entiendo bastante mejor cómo se estructura un proyecto, por qué unas decisiones envejecen bien y otras te explotan, y cómo se depura algo que falla. Y eso lo he aprendido sin escribir la mayor parte de las líneas.
Entonces la pregunta buena no es si se aprende, sino qué se aprende y qué se pierde.
Lo que se pierde es la memoria de sintaxis. Ya no me acuerdo del orden exacto de los parámetros de una función ni de cómo se escribe cierta estructura en cierto lenguaje. Antes eso lo tenía y ahora no.
Lo que se gana es criterio de arquitectura. Ver un plan y saber que va a dar problemas. Detectar que una solución está resolviendo el síntoma. Entender por qué algo que funciona hoy va a ser un infierno de mantener.
Y si me das a elegir entre las dos, me quedo con la segunda sin pensarlo. La sintaxis siempre estuvo en la documentación. El criterio no está en ninguna parte.
La diferencia entre delegar y desentenderse
Aquí está la línea, y es bastante nítida.
Desentenderse es pedir algo, copiarlo, ver que funciona y pasar a lo siguiente. Si funciona no miras nada. Si no funciona, vuelves a pedir con otras palabras hasta que funcione. En ese modo no aprendes nada, y no es una opinión moral: es que literalmente no ha pasado ninguna información por tu cabeza.
Delegar es pedir algo, leerlo, entender a grandes rasgos qué hace, preguntar por lo que no entiendes y decidir si te vale. Sigue siendo mucho más rápido que escribirlo tú. Y ahí sí aprendes, porque estás leyendo soluciones buenas a problemas reales todo el rato.
La diferencia práctica entre los dos modos son unos segundos por cada cosa. Segundos.
Lo que me funcionó a mí fue tomármelo como leer código de alguien mejor que yo. Es lo que hacen los que aprenden en equipo: no escriben todo desde cero, leen lo que han hecho otros y así absorben patrones. Solo que aquí el otro está disponible a las dos de la mañana y le puedes preguntar por qué ha hecho algo sin quedar como un pesado.
Las tres preguntas que convierten trabajo hecho en aprendizaje
Tengo tres preguntas que hago casi en automático y que son la diferencia entre acumular archivos y acumular criterio.
"¿Por qué así y no de la otra forma?" La respuesta a esto es donde está el aprendizaje real. No qué hace el código, sino qué alternativas había y por qué se ha descartado el resto.
"¿Qué se rompe si cambio esto?" Te obliga a entender las dependencias, que es lo que de verdad distingue a quien sabe de quien copia.
"Explícamelo como si no supiera nada de esto." Sin vergüenza. Es la que más he usado y la que más me ha enseñado. Si la explicación no te cabe en la cabeza, no lo has entendido, y da igual que funcione.
Hay una cuarta que uso menos pero que es demoledora cuando algo no me cuadra: "dame la versión más simple que resuelva esto". Casi siempre aparece una solución con la mitad de piezas, y comparar las dos te enseña más que cualquiera de ellas por separado. Además te quita de encima complejidad que ibas a mantener durante años sin necesitarla.
Estas preguntas funcionan igual si lo que delegas no es código. Sirven para un texto, para un análisis de números o para una estructura de carpetas. Es el mismo mecanismo: hacer que la máquina razone en voz alta te enseña a razonar.
Lo que sí se atrofia y cómo lo compenso
No voy a vender que esto salga gratis. Hay dos cosas que noto peor.
Arrancar desde cero. La pantalla en blanco pesa más que antes, porque sé que puedo pedir un primer borrador. Lo compenso obligándome a escribir yo el primer intento en las cosas que importan, aunque tarde más y aunque salga peor. No por deporte, sino porque mi primer intento se parece a mí y el borrador generado se parece a la media.
Detectar errores sutiles. Cuando lees mucho código correcto, bajas la guardia. Y lo que falla ya no es lo evidente, es el caso raro. Esto lo compenso probando de verdad las cosas en vez de fiarme de que "se ve bien". Se ve bien casi siempre. No es información.
Ninguna de las dos me parece motivo para volver atrás. Son el precio, y es un precio razonable.
¿Y si nunca has programado?
Aquí la respuesta es distinta y bastante más optimista.
Si partes de cero, trabajar con IA es la mejor forma de entrar que ha existido nunca. No porque te ahorre estudiar, sino porque te deja tener algo funcionando el primer día. Y tener algo funcionando es lo que sostiene las ganas de seguir, que es donde se cae casi todo el mundo que empieza con un curso de sintaxis de tres meses.
Lo he contado con más detalle en Claude Code para no programadores, y también por qué creo que Claude Code no es solo para programadores: la mayor parte de lo que yo hago con él ni siquiera es código.
Lo que sí te pido si empiezas así: no te saltes el entender. Es tentador quedarte en "funciona y no sé por qué", porque el resultado es el mismo hoy. Pero el día que se rompa, y se va a romper, o entiendes algo o estás vendido.
Entonces, ¿hace falta aprender a programar?
Esta pregunta se me cruza con la anterior en todos los comentarios, y le dediqué su propio artículo: ¿hay que aprender a programar en 2026?.
El resumen es que aprender la sintaxis de un lenguaje ha bajado mucho de valor, y entender cómo funcionan las cosas ha subido. Saber qué es una base de datos, qué es una API, por qué algo va lento, qué significa que un servicio se caiga. Eso vale más que nunca, porque es lo que te permite dirigir.
Y dirigir es lo que estás haciendo, aunque no lo llames así. La máquina ejecuta. Tú decides qué se construye, con qué prioridades y cuándo está bien. Ese trabajo no se delega, porque es el trabajo.
Mi respuesta, corta
Se aprende si lees. No se aprende si copias.
Y la diferencia entre las dos son quince segundos por cada cosa que pides. Es probablemente la mejor relación entre esfuerzo y retorno que vas a encontrar en todo esto.
Si no sabes por dónde meter la IA en lo tuyo ni qué te va a servir de verdad, tengo un test corto que te lo dice sin venderte humo.
Sigue leyendo
Por qué dejé ChatGPT por Claude (y cuándo uso cada uno)
Pasé de ser fan absoluto de ChatGPT a tener dos cuentas Max de Claude. Qué hace mejor cada uno y cómo me reparto el trabajo entre los dos.
Claude Code en Windows: guía completa y los pasos que atascan
En Windows hay tres pasos extra que nadie cuenta y que atascan a media internet. Instalación completa de Claude Code y cómo salir de cada atasco.
Las mejores plantillas de CLAUDE.md para empezar tu proyecto
Cuatro plantillas de CLAUDE.md listas para copiar según el tipo de proyecto, y lo que sobra en casi todas las que circulan por ahí sin que nadie lo diga.
Los mejores MCP para Claude Code en 2026: probados uno a uno
Los MCP que uso a diario, los que instalé y acabé borrando, y los que todavía no merecen el hueco de contexto que ocupan.