Un hilo publicado en Lobsters bajo la etiqueta vibecoding alcanzó 114 votos a favor y 71 comentarios. El título era escueto: «On AI», y enlazaba a un artículo en jcs.org (actualmente inaccesible). Sin embargo, el debate en la sección de comentarios se convirtió rápidamente en el verdadero centro de atención.
En la parte superior del hilo, el usuario tmcb dejó una metáfora reveladora:
«Es como ser Sísifo, pero en una colina cercana la gente se lo pasa en grande viendo cómo una grúa sube las rocas a la cumbre con una precisión dudosa, golpeando de vez en cuando a algún espectador. Hay que imaginar a Sísifo absolutamente furioso.»
Esa intervención obtuvo 93 votos positivos porque tocó una inquietud compartida por cada vez más desarrolladores: las herramientas de IA son tan «convenientes» que uno empieza a dudar de si realmente sigue aprendiendo algo.
Este artículo analiza qué ocurre cuando delegas en la IA la escritura de código y adónde va a parar ese proceso de «aprendizaje incidental» cuando desaparece.
Imagen: En el desarrollo moderno, la generación de código con IA se ha convertido en una infraestructura estándar. Sin embargo, tras el aumento de productividad, se suele pasar por alto el costo en el aprendizaje.
El paso del aprendizaje borrado por arte de magia
El usuario duck_tape resumió la tesis central de todo el debate en un comentario con 38 votos a favor:
«Hay algo a lo que aún no nos hemos enfrentado del todo: gran parte de nuestro aprendizaje ocurría de manera “incidental”, como un subproducto de las tareas cotidianas. Al implementar una función cualquiera o al lidiar con la configuración del CI para un nuevo objetivo de compilación, era imposible no aprender. Ahora podemos hacer desaparecer esos pasos como por arte de magia. Podemos “crear” directamente lo que tenemos en la cabeza. Pero ya no podemos aprender de paso. Resulta realmente difícil mantenerse concentrado mientras el LLM resuelve un error por ti.»
El «aprendizaje incidental» (incidental learning) no es un término pedante de la pedagogía. Describe la forma más natural de aprendizaje humano: adquirir un conocimiento o habilidad de manera no planificada mientras se intenta resolver otro problema. La programación ha dependido históricamente de este mecanismo.
Imaginemos a un desarrollador junior enfrentándose a la corrección de un error real. Su objetivo es simplemente solucionar el fallo, pero en el camino se ve obligado a entender la arquitectura del proyecto, aprender a usar el depurador, comprender por qué el problema se activa bajo ciertas condiciones y memorizar el uso de ciertas API. No se propuso «estudiar» esos temas de forma deliberada: el aprendizaje ocurrió de paso.
Desde el lanzamiento oficial de GitHub Copilot en 2022, el número de usuarios superó los 20 millones en 2025. Según datos de Microsoft, cerca del 46 % del código escrito por los usuarios proviene ya de sugerencias de IA (alcanzando hasta un 61 % en proyectos Java). Esa cifra continúa creciendo.
La IA interrumpe este bucle de retroalimentación. Su modelo de interacción esquiva de forma precisa la dinámica del «aprender haciendo». Tú introduces un prompt y el modelo genera código.
Cuando estas oportunidades perdidas se acumulan, el paso del aprendizaje borrado por la magia de la automatización desaparece por completo.
Imagen: El autocompletado por IA transforma el rol del desarrollador de «creador» a «revisor»: revisar es más rápido que escribir, pero la profundidad de comprensión disminuye.
Por qué esto no es un simple «Stack Overflow 2.0»
Existe una objeción recurrente: cuando apareció Stack Overflow, también se dijo que los programadores perderían la capacidad de consultar la documentación; cuando llegó el autocompletado en los IDE, se afirmó que dejarían de memorizar las API. Y sin embargo, la industria no colapsó.
No obstante, esta analogía es incompleta. El usuario bendmorris señaló una distinción fundamental:
«Por supuesto que siempre ha habido programadores que sobrevivían copiando y pegando de Stack Overflow sin entender realmente lo que hacían. En la burbuja laboral de la era de tipos de interés cero esto podía colar, y ahora esos programadores usarán LLM y su calidad promedio aumentará. No creo que el resultado sea brillante: el ser humano en esa ecuación apenas aporta valor real.»
Stack Overflow y el autocompletado del IDE mejoraban la eficiencia sobre una estructura de conocimiento previa. Seguía siendo necesario entender la respuesta encontrada para evaluar si encajaba en el contexto; el autocompletado solo funcionaba cuando ya sabías qué función querías llamar. Aceleraban la ejecución, pero no se saltaban la comprensión.
La generación de código mediante IA se salta la comprensión misma. Uno no aprende automáticamente la lógica de un fragmento solo por verlo en pantalla, especialmente si se trata de 30 líneas de patrones que nunca antes ha utilizado.
La psicología cognitiva ofrece dos conceptos clave para entender este fenómeno: la ilusión de fluidez (fluency illusion) y las dificultades deseables (desirable difficulties). Los psicólogos cognitivos de la UCLA Elizabeth y Robert Bjork demostraron en los años noventa que aquellos métodos de aprendizaje que se sienten «fáciles» son precisamente los que generan menor retención a largo plazo. Por el contrario, el aprendizaje que exige un esfuerzo deliberado —recordar con dificultad, resolver problemas de forma autónoma— produce una asimilación mucho más duradera.
Las herramientas de IA ofrecen la máxima fluidez con el mínimo esfuerzo. Es una decisión de diseño de producto entendible, pero el aprendizaje sufre las consecuencias.
Un ensayo controlado aleatorizado de 2025 puso a prueba esta hipótesis. Los investigadores dividieron a los participantes en dos grupos: uno utilizó ChatGPT para completar tareas y el otro empleó métodos tradicionales. Los resultados mostraron que el grupo asistido por IA rindiós mejor en la tarea inmediata, pero obtuvo puntuaciones significativamente menores en las pruebas independientes posteriores. Esto coincide con la teoría de la «descarga cognitiva» (cognitive offloading): el cerebro, al obtener las respuestas tan fácilmente, opta por no almacenar la información.
«Puedo seguir aprendiendo, pero no quiero ser solo un revisor»
Otro comentario muy valorado (29 votos) fue el de zetashift, quien describió una sensación de apatía extendida en la comunidad técnica:
«He dejado de hacer clic en enlaces de GitHub. Cuando veo que un repositorio contiene archivos como
CLAUDE.mdoAGENTS.md, mi acto reflejo es cerrar la pestaña. … Tras programar con un LLM, no siento ningún afecto por lo que he creado. No siento que el resultado sea mío ni tengo ganas de comprenderlo.»
Esta postura no es aislada. El usuario gered respondió que tras usar vibe coding se sentía «sucio» (“I almost feel dirty afterwards”), mientras que el usuario lake compartió su propia historia:
«Pasé un año y medio trabajando en un proyecto de código abierto. Luego vi a otros llegar con IA en pocos meses adonde yo quería llegar. Me alegra que estas herramientas existan, pero si hubieran existido antes de empezar, probablemente nunca habría iniciado el proyecto. Me digo a mí mismo: habrá gente que aprecie el código artesanal. Me digo: el código abierto no es una carrera. Pero ver cómo otros te adelantan a toda velocidad resulta sin duda desalentador.»
Tras estas emociones subyace un problema estructural a menudo ignorado. Cuando ingenieros sénior —con diez o veinte años de experiencia— usan IA, cuentan con el criterio para evaluar la calidad, detectar errores absurdos y refactorizar 50 líneas generadas en 10 líneas de lógica limpia. Sin embargo, un desarrollador principiante carece de ese criterio.
La conclusión de bendmorris fue contundente:
«Alguien como Andreas Kling puede pasar a usar LLM fácilmente porque ha acumulado suficientes habilidades para garantizar la calidad y resolver el problema correcto. Pero ¿cómo alcanzará ese nivel la próxima generación de programadores si usa LLM desde el principio? Las tareas básicas que construyen habilidades son precisamente las más fáciles de automatizar. La industria se está disparando en el pie.»
El problema no es la IA, sino el flujo de trabajo sin comprensión
Es necesario hacer una distinción precisa. No se trata de sostener que «la IA es una mala herramienta», una postura simplista que no se sostiene. Los asistentes de código aumentan significativamente la productividad, permitiendo a equipos reducidos lograr lo que antes requería multiplicar por diez la plantilla. También permiten a personas no técnicas construir aplicaciones sencillas con lenguaje natural. Ese valor es indiscutible.
El problema real es: cuando el diseño de la herramienta esquiva el bucle de aprendizaje, ¿quién se encarga de garantizar que el aprendizaje siga ocurriendo?
Actualmente, casi todos los modelos de interacción de IA para programación siguen la secuencia Necesidad → Código → Aceptación. La herramienta se diseña para completar la tarea, no para ayudar al usuario a comprenderla.
El artículo de investigación Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development (arXiv:2607.06101) analizó este problema y propuso por primera vez el concepto de «Deuda de Conocimiento» (Knowledge Debt):
Cuando los agentes de IA ejecutan cambios de código que el desarrollador no comprende del todo, esas brechas de comprensión se acumulan con el tiempo. Hoy la IA soluciona un error que no entiendes, mañana genera una optimización que no sabes explicar. Un año después, tu sistema funciona bien, pero ya no eres capaz de mantenerlo porque ignoras cómo funciona internamente.
Esta deuda es más difícil de detectar que la deuda técnica tradicional. La deuda técnica se manifiesta en métricas de calidad de código o análisis estático. La deuda de conocimiento no deja rastro en el repositorio: se esconde en la mente del desarrollador y solo sale a la luz cuando debe resolver un problema de forma independiente.
El costo de delegar el pensamiento
La pregunta del usuario pyj plantea un dilema sumamente práctico:
«Mi problema personal con la IA es que noto que retengo mucho menos. La tarea se completa, pero lo que aprendo y recuerdo es mucho menor que antes. ¿Existen buenas estrategias para mantener el aprendizaje mientras se usan herramientas de IA?»
Es una duda que aún no ha recibido una respuesta clara. Algunos programadores experimentados comparten sus métodos, como pedir a Claude que genere un prototipo inicial para luego refactorizarlo manualmente hacia una arquitectura más limpia. Sin embargo, para hacer eso se requiere saber de antemano qué aspecto tiene una «arquitectura limpia».
El debate en Lobsters derivó finalmente en dos posturas. Una sostiene que la programación manual se está convirtiendo en un oficio artesanal, comparable a la ebanistería o a tocar un instrumento acústico: se puede elegir usar herramientas eléctricas o cepillos manuales, y ninguna opción es intrínsecamente superior. La otra advierte de que, a medida que los incentivos de la industria se inclinen hacia la velocidad de la IA, el costo de programar manualmente será cada vez mayor, hasta el punto de que solo los más acomodados o apasionados podrán permitírselo.
Ambas visiones tienen parte de razón, pero ambas esquivan la pregunta central: si el camino del «aprendizaje incidental» se ha cortado, ¿cuántos rodeos deberá dar la nueva generación de programadores para alcanzar el nivel que la anterior logró simplemente haciendo su trabajo?
Nadie ofreció una respuesta definitiva en el hilo. Pero el mero hecho de plantear la pregunta resulta mucho más valioso que cualquier mensaje publicitario sobre IA.
Enlaces de referencia:
- Lobsters: On AI (114△, 71 comments) (item?id=zljfgp/on_ai)
- Joshua Stein: On AI (jcs.org)
- Hacker News: On AI discussion
- Bjork & Bjork (2011): Desirable Difficulties in Theory and Practice
- Anthropic: ChatGPT as a Cognitive Crutch
- arXiv 2607.06101: Agents That Teach
- Bjork (1994): Memory and Metamemory Considerations in the Training of Human Beings
- GitHub Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness
