Toda persona puede ser, si se lo propone, escultor de su propio cerebro

La irrupción de los grandes modelos de lenguaje (LLM) en el trabajo diario está alterando, de forma silenciosa pero profunda, la manera en que pensamos, aprendemos y tomamos decisiones. En ingeniería del software, su efecto es especialmente visible: por primera vez contamos con herramientas que no solo autocompletan nombres de variables y métodos, sino que proponen arquitecturas, redactan pruebas, traducen entre lenguajes de programación y sugieren soluciones con una fluidez que compite con la pericia humana.

La evidencia empírica sobre productividad, aunque aún incipiente, ya apunta a mejoras medibles en tareas concretas. En un experimento controlado con GitHub Copilot, un grupo de desarrolladores completó una tarea de implementación significativamente más rápido que el grupo de control ^[1].  En paralelo, en escritura profesional se han observado incrementos de productividad y cierta convergencia de calidad cuando se introduce un asistente tipo ChatGPT ^[2].  A estos resultados se suman declaraciones especialmente llamativas de líderes del sector: Gustav Söderström (co-CEO de Spotify) afirmó recientemente, en la presentación de resultados del 4T de 2025, que sus desarrolladores “no han escrito ni una sola línea de código desde diciembre”, sino que se limitan a guiar herramientas de generación ^[3]. Boris Cherny, responsable de Claude Code, afirmó igualmente que “el 100% de su código en los últimos dos meses ha sido escrito íntegramente por Opus 4.5” ^[4]. Incluso Sam Altman ha sugerido que GPT-5 Codex ha sido parte activa de su propio desarrollo, programándose a sí mismo ^[5].

Este cambio de paradigma, sin embargo, convive con una pregunta incómoda, que motiva el tercer post de la serie sobre LLMs: ¿qué sucede con las habilidades que dejamos de ejercitar cuando “delegamos” parte del esfuerzo cognitivo?

En educación, el debate se ha polarizado entre el fraude y la oportunidad. Hay estudios que describen cómo el acceso generalizado a herramientas generativas puede modificar conductas (y, a veces, percepciones) en torno a la integridad académica; en particular, se han publicado análisis con datos previos y posteriores a la popularización de ChatGPT que exploran la estabilidad o el cambio de patrones de copia y reutilización de trabajos ajenos en secundaria ^[6]. Más allá del aula, preocupa el modo en que estas herramientas reconfiguran hábitos: si un texto “se produce” con suficiente corrección, la tentación de no revisar ni integrar el contenido en el propio marco mental es real.

En este punto conviene introducir una distinción: no es lo mismo usar un LLM como calculadora (externalizando un cálculo mecánico) que usarlo como sustituto del razonamiento (externalizando la construcción del modelo mental). La literatura reciente empieza a señalar riesgos compatibles con esta intuición: se han observado asociaciones entre mayor dependencia de la IA y niveles más bajos de pensamiento crítico, con mecanismos plausibles (como la fatiga cognitiva) y con el papel amortiguador aunque imperfecto de la alfabetización informacional ^[7].  Además, en tareas de aprendizaje donde se compara el uso de un LLM frente a un buscador tradicional, se ha reportado una reducción del esfuerzo mental junto con una reducción en la profundidad del razonamiento, lo que sugiere que la “facilidad” puede tener un coste en el aprendizaje si no se compensa con estrategias activas ^[8].

En ingeniería del software, esta “atrofia cognitiva” ^[9] puede interpretarse como un offloading mal calibrado: trasladamos al asistente pasos que antes eran clave en el entrenamiento deliberado de habilidades creativas y analíticas en desarrollo del software (leer un error, depurar hipótesis, diseñar una abstracción, elegir una estructura de datos) y nos quedamos, sobre todo, con tareas de supervisión y corrección. Paradójicamente, esa supervisión tampoco es trivial.

La investigación clásica sobre automatización ya advertía que el uso, el mal uso y el abuso de sistemas automáticos depende de factores como la confianza, la carga mental o la percepción del riesgo, y que estos factores pueden empujar tanto a la dependencia excesiva como a la infrautilización de nuestras capacidades mentales ^[10]. En el terreno experimental contemporáneo, también se ha observado que la mera conciencia de que un consejo provenga de una IA puede incrementar la tendencia a seguirlo incluso cuando contradice información contextual disponible y el propio juicio del usuario ^[11]. Trasladado al código, esto se traduce en aceptar sugerencias plausibles, pero defectuosas, con un coste diferido: fallos sutiles, deuda técnica y, sobre todo, aprendizaje que no llega a cristalizar porque el razonamiento se interrumpe antes de consolidarse.

Para perfiles junior el riesgo es doble. Los ingenieros jóvenes se encuentran frente a la dicotomía del Dr. JekyLLM y Mr. Hyde: la IA puede convertirse en una palanca de aprendizaje o en una tentación peligrosa que les roba la oportunidad de aprender de los errores iniciales cuando todavía son manejables. Por una parte, los LLM pueden acelerar la entrega y dar una falsa sensación de competencia (al escribir código con el que el sistema “funciona”), reduciendo el tiempo que antes se invertía en entender por qué funciona. Por otra, si las organizaciones priorizan únicamente el throughput, es fácil desplazar el entrenamiento desde la exploración guiada hacia la mera ejecución supervisada.

Los estudios de usabilidad son muy reveladores: en pruebas con ingenieros recién titulados aparecen fricciones (por ejemplo, dudas sobre qué aceptar), malentendidos (sobre lo que el modelo de IA realmente garantiza) y estrategias de compensación (revisión a posteriori, parcheo rápido). Por eso, no basta con escribir prompts: hay que aprender a incorporar los LLM sin sustituir el razonamiento ^[12]. Y, en paralelo, las comparativas de calidad advierten que la corrección, la mantenibilidad o la seguridad del código generado no son uniformes: la salida puede ser válida y, aun así, subóptima o frágil ^[13].

En este artículo quiero defender que este escenario no es inevitable: esconde una oportunidad extraordinaria. Con un esfuerzo modesto, el mismo LLM puede convertirse en una tecnología de andamiaje cognitivo, más que de sustitución; una herramienta que, en palabras de Ramón y Cajal, nos permita “convertirnos en escultores de nuestro propio cerebro” y potencie el aprendizaje a una escala difícil de imaginar décadas atrás.

El primer consejo (o truco) consiste en separar explícitamente dos modos de trabajo complementarios: modo entrega rápida y modo aprendizaje. En modo entrega, el objetivo es avanzar, pero con controles de calidad estrictos (tests, análisis estático, revisión por pares). En modo aprendizaje, el objetivo es también avanzar con esos controles, pero sin renunciar a fortalecer el modelo mental: pedir alternativas y sus compromisos; exigir explicaciones con invariantes y complejidad; solicitar que el asistente derive casos límite y justifique por qué se rompen soluciones “ingenuas”; o forzar una “segunda vuelta” en la que el propio ingeniero reescribe la solución sin mirar el resultado previo.

Esta vuelta de tuerca es consistente con los resultados de investigaciones que advierten sobre la “pereza metacognitiva”: cuando la herramienta mejora el producto final, puede no mejorar la ganancia de conocimiento si no se induce autorregulación, reflexión y cierto nivel de esfuerzo personal ^[14]. En la línea de revisiones críticas recientes sobre IA y aprendizaje, parece que la clave está precisamente en ese proceso en el que nos esculpimos a nosotros mismos con la práctica: , centrando menos la atención en la herramienta en sí y más en cómo se diseña la tarea y el proceso de aprendizaje: qué procesos cognitivos activa, qué tipo de atención promueve y qué hábitos consolida ^[15].

Estas estrategias pueden materializarse en rituales sencillos, compatibles con un entorno corporativo y equipos con miembros jóvenes. Por ejemplo:

1. Comparación activa: pedir al LLM una solución y, antes de aceptarla, escribir una propia (aunque sea parcial) y luego comparar.
2. Análisis post-mortem breve: tomar notas con nuestras propias palabras sobre qué se aprendió (un patrón, una API, un error conceptual) y qué señal te permitió detectar un fallo.
3. Restricciones deliberadas: reservar pequeñas “zonas sin copiloto” (katas, módulos de formación, revisiones) donde el perfil junior practique desde cero.
4. Prompts orientados de tutoría personalizada: “no me des el código final; hazme preguntas, sugiere pasos y valida mis hipótesis”.
5. Verificación como aprendizaje: convertir la revisión en una actividad intelectual más intensa (propiedades, invariantes, pruebas de estrés), no en un simple “pasa o no pasa el test”.

Si se mantiene esta disciplina, el LLM deja de ser un atajo que nos “apaga el cerebro” y pasa a ser un multiplicador de nuestra curiosidad y nuestras posibilidades de crecimiento profesional: un sparring intelectual con ciertas limitaciones, pero disponible 24/7, que exige que el ingeniero sostenga la responsabilidad del razonamiento.

En última instancia, la clave está en la práctica deliberada y el aprendizaje continuo para mantener las capacidades “afiladas”, en la línea de la máxima atribuida a Benjamin Franklin. Parte de mi trabajo es que la IA evolucione, sea útil y responsable en sectores donde el listón de calidad es muy alto. En este artículo comparto lo que he aprendido para que cualquiera (desde quien está empezando hasta quien tiene décadas de experiencia) pueda reflexionar y compartir su experiencia. Si esta serie de posts te ha ayudado a mirar la IA con un poco más de calma en un entorno sobrecargado de hype, ya ha cumplido su función.

Autor: David Miraut

Referencias:

[1]         S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, ‘The Impact of AI on Developer Productivity: Evidence from GitHub Copilot’, Feb. 13, 2023, arXiv: arXiv:2302.06590. doi: 10.48550/arXiv.2302.06590.

[2]         S. Noy and W. Zhang, ‘Experimental evidence on the productivity effects of generative artificial intelligence’, Science, vol. 381, no. 6654, pp. 187–192, Jul. 2023, doi: 10.1126/science.adh2586.

[3]         ‘Spotify asegura que sus programadores no han escrito “ni una sola línea de código” en 2026 y eso dice mucho del futuro que nos aguarda’. Accessed: Feb. 24, 2026. [Online]. Available: https://www.elconfidencial.com/tecnologia/2026-02-14/programadores-spotify-no-escriben-codigo-1qrt_4302850/?utm_source=chatgpt.com

[4]         M. Zeff, ‘Cómo Claude Code está transformando el software, empezando por Anthropic’, WIRED. Accessed: Feb. 24, 2026. [Online]. Available: https://es.wired.com/articulos/como-claude-code-esta-transformando-el-software-empezando-por-anthropic

[5]         B. Edwards, ‘How OpenAI is using GPT-5 Codex to improve the AI tool itself’, Ars Technica. Accessed: Feb. 24, 2026. [Online]. Available: https://arstechnica.com/ai/2025/12/how-openai-is-using-gpt-5-codex-to-improve-the-ai-tool-itself/

[6]         V. R. Lee, D. Pope, S. Miles, and R. C. Zárate, ‘Cheating in the age of generative AI: A high school survey study of cheating behaviors before and after the release of ChatGPT’, Comput. Educ. Artif. Intell., vol. 7, p. 100253, Dec. 2024, doi: 10.1016/j.caeai.2024.100253.

[7]         J. Tian and R. Zhang, ‘Learners’ AI dependence and critical thinking: The psychological mechanism of fatigue and the social buffering role of AI literacy’, Acta Psychol. (Amst.), vol. 260, p. 105725, Oct. 2025, doi: 10.1016/j.actpsy.2025.105725.

[8]         M. Stadler, M. Bannert, and M. Sailer, ‘Cognitive ease at a cost: LLMs reduce mental effort but compromise depth in student scientific inquiry’, Comput. Hum. Behav., vol. 160, p. 108386, Nov. 2024, doi: 10.1016/j.chb.2024.108386.

[9]         N. Kosmyna et al., ‘Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task’, Dec. 31, 2025, arXiv: arXiv:2506.08872. doi: 10.48550/arXiv.2506.08872.

[10]      R. Parasuraman and V. Riley, ‘Humans and Automation: Use, Misuse, Disuse, Abuse’, Hum. Factors, vol. 39, no. 2, pp. 230–253, Jun. 1997, doi: 10.1518/001872097778543886.

[11]      A. Klingbeil, C. Grützner, and P. Schreck, ‘Trust and reliance on AI — An experimental study on the extent and costs of overreliance on AI’, Comput. Hum. Behav., vol. 160, p. 108352, Nov. 2024, doi: 10.1016/j.chb.2024.108352.

[12]      P. Vaithilingam, T. Zhang, and E. L. Glassman, ‘Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models’, in Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems, in CHI EA ’22. New York, NY, USA: Association for Computing Machinery, Apr. 2022, pp. 1–7. doi: 10.1145/3491101.3519665.

[13]      B. Yetiştiren, I. Özsoy, M. Ayerdem, and E. Tüzün, ‘Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT’, Oct. 22, 2023, arXiv: arXiv:2304.10778. doi: 10.48550/arXiv.2304.10778.

[14]      Y. Fan et al., ‘Beware of metacognitive laziness: Effects of generative artificial intelligence on learning motivation, processes, and performance’, Br. J. Educ. Technol., vol. 56, no. 2, pp. 489–530, 2025, doi: 10.1111/bjet.13544.

[15]      E. Bauer, S. Greiff, A. C. Graesser, K. Scheiter, and M. Sailer, ‘Looking Beyond the Hype: Understanding the Effects of AI on Learning’, Educ. Psychol. Rev., vol. 37, no. 2, p. 45, Apr. 2025, doi: 10.1007/s10648-025-10020-8.