Sebastian Gomez
La paradoja del aprendizaje con IA: Por qué la comodidad actual puede costar tu futuro como desarrollador
HaceA few days ago, I was listening to a reflection by Andrew Ng that resonated deeply with me, both as an Engineering Manager and as a university professor: the way the vast majority of people use artificial intelligence today is fundamentally detrimental to learning.
In an era where any tool can generate a React component, a backend script, or a complete algorithm solution in three seconds, a widespread illusion of competence has taken hold. It feels as though everyone has become more productive, but beneath that superficial speed, a quiet problem is emerging: the atrophy of a software engineer's most critical muscle, the ability to solve complex problems independently.
Whether you are starting out in programming or leading engineering teams, this is an urgent conversation we need to have openly.
The Classroom Reality: From Critical Thinking to Blind Copy-Pasting
Teaching at the university, I have had a front-row seat to how student dynamics have shifted over the last few semesters.
The pattern repeats itself constantly: when faced with a problem requiring abstraction or algorithmic design, the first impulse is no longer to sit down with pencil and paper to map out data flow. The first impulse is to throw the prompt at a language model. The most concerning part is not that they use the tool, but that they frequently do not even read the response the AI provides. They copy, paste into the editor, and if it compiles or passes basic tests, they consider the work done without having built a mental model of what just happened.
University programs and the early years of a developer's career are not designed solely to deliver code that runs; they exist so your brain experiences the friction of facing uncertainty, making mistakes, debugging, and structuring a solution.
When you outsource that initial cognitive struggle to a machine, you are outsourcing the exact biological process that builds engineering judgment.
The Great Asymmetry: Why AI Empowers Seniors but Makes Juniors Fragile
There is a fundamental difference in how an experienced engineer interacts with AI compared to someone still in training:
- The senior developer uses AI as a velocity multiplier on top of an already consolidated foundation. The senior knows exactly what architecture they want, recognizes design patterns, spots vulnerabilities instantly, and possesses the judgment to discard code when a model hallucinates or suggests inefficient solutions.
- The junior developer, having not yet built those fundamentals by hand, lacks the reference framework to evaluate what the AI produces. They end up operating as a prompt-suggestion consumer rather than a software architect.
The paradox is that AI is incredible for those who already know how to program, but can become a dangerous trap for those who are just learning.
Even senior engineers must stay mindful of this risk: if we stop grappling with raw code and manual problem solving, our own judgment will gradually rust over time.
Who Will AI Actually Replace?
There is endless discussion about AI eliminating junior developer roles across the industry. My stance is straightforward: AI will not replace junior developers who are eager to learn; it will replace developers (junior or senior) who limit themselves to being passive intermediaries between a prompt and a repository.
If your only value proposition is asking a model for code and committing it without understanding its memory footprint, concurrency behavior, performance implications, or security posture, your role is easily automated.
By contrast, the engineer who masters the fundamentals, understands underlying architecture, and uses AI as a Socratic tutor (interrogating its answers and demanding alternatives) becomes exponentially more valuable and difficult to replace. The real technical revolution is not about coding less, but about thinking deeper.
Whiteboard Discipline: The Irreplaceable Value of Deliberate Effort
To counteract this cognitive trap, there is one habit I consistently recommend to my studA few days ago, I was listening to a reflection by Andrew Ng that resonated deeply with me, both as an Engineering Manager and as a university professor: the way the vast majority of people use artificial intelligence today is fundamentally detrimental to learning.
In an era where any tool can generate a React component, a backend script, or a complete algorithm solution in three seconds, a widespread illusion of competence has taken hold. It feels as though everyone has become more productive, but beneath that superficial speed, a quiet problem is emerging: the atrophy of a software engineer's most critical muscle, the ability to solve complex problems independently.
Whether you are starting out in programming or leading engineering teams, this is an urgent conversation we need to have openly.
The Classroom Reality: From Critical Thinking to Blind Copy-Pasting
Teaching at the university, I have had a front-row seat to how student dynamics have shifted over the last few semesters.
The pattern repeats itself constantly: when faced with a problem requiring abstraction or algorithmic design, the first impulse is no longer to sit down with pencil and paper to map out data flow. The first impulse is to throw the prompt at a language model. The most concerning part is not that they use the tool, but that they frequently do not even read the response the AI provides. They copy, paste into the editor, and if it compiles or passes basic tests, they consider the work done without having built a mental model of what just happened.
University programs and the early years of a developer's career are not designed solely to deliver code that runs; they exist so your brain experiences the friction of facing uncertainty, making mistakes, debugging, and structuring a solution.
When you outsource that initial cognitive struggle to a machine, you are outsourcing the exact biological process that builds engineering judgment.
The Great Asymmetry: Why AI Empowers Seniors but Makes Juniors Fragile
There is a fundamental difference in how an experienced engineer interacts with AI compared to someone still in training:
- The senior developer uses AI as a velocity multiplier on top of an already consolidated foundation. The senior knows exactly what architecture they want, recognizes design patterns, spots vulnerabilities instantly, and possesses the judgment to discard code when a model hallucinates or suggests inefficient solutions.
- The junior developer, having not yet built those fundamentals by hand, lacks the reference framework to evaluate what the AI produces. They end up operating as a prompt-suggestion consumer rather than a software architect.
The paradox is that AI is incredible for those who already know how to program, but can become a dangerous trap for those who are just learning.
Even senior engineers must stay mindful of this risk: if we stop grappling with raw code and manual problem solving, our own judgment will gradually rust over time.
Who Will AI Actually Replace?
There is endless discussion about AI eliminating junior developer roles across the industry. My stance is straightforward: AI will not replace junior developers who are eager to learn; it will replace developers (junior or senior) who limit themselves to being passive intermediaries between a prompt and a repository.
If your only value proposition is asking a model for code and committing it without understanding its memory footprint, concurrency behavior, performance implications, or security posture, your role is easily automated.
By contrast, the engineer who masters the fundamentals, understands underlying architecture, and uses AI as a Socratic tutor (interrogating its answers and demanding alternatives) becomes exponentially more valuable and difficult to replace. The real technical revolution is not about coding less, but about thinking deeper.
Whiteboard Discipline: The Irreplaceable Value of Deliberate Effort
To counteract this cognitive trap, there is one habit I consistently recommend to my students and the engineers I mentor: whiteboard (or blank notebook) discipline.
When approaching a new feature or a complex bug:
- Step away from the prompt during the first few minutes: Before writing a single line of code or opening an AI chat, sketch the flow on paper or a whiteboard. What are the inputs? What are the outputs? What intermediate states exist?
- Struggle with the problem first: Try to work out the core logic yourself. Experience the roadblock, test hypotheses, and consult official documentation. That brief moment of mental friction is what creates lasting neural connections.
- Use AI as a Socratic tutor, not a shortcut generator: When you turn to AI, do not ask "give me the code to solve this." Ask "review my reasoning, what edge cases am I overlooking?" or "explain why this algorithmic approach carries higher time complexity."
We do not build things by hand because AI is incapable of doing so; we do it because it is the only proven way to cultivate rigorous analytical thinking and sound engineering judgment.
How are you or your team managing the use of AI tools day to day? Do you feel it accelerates your learning or encourages convenient shortcuts?
I would love to read your thoughts and experiences in the comments. Let us keep learning and building with purpose!
ents and the engineers I mentor: whiteboard (or blank notebook) discipline.
When approaching a new feature or a complex bug:
- Step away from the prompt during the first few minutes: Before writing a single line of code or opening an AI chat, sketch the flow on paper or a whiteboard. What are the inputs? What are the outputs? What intermediate states exist?
- Struggle with the problem first: Try to work out the core logic yourself. Experience the roadblock, test hypotheses, and consult official documentation. That brief moment of mental friction is what creates lasting neural connections.
- Use AI as a Socratic tutor, not a shortcut generator: When you turn to AI, do not ask "give me the code to solve this." Ask "review my reasoning, what edge cases am I overlooking?" or "explain why this algorithmic approach carries higher time complexity."
We do not build things by hand because AI is incapable of doing so; we do it because it is the only proven way to cultivate rigorous analytical thinking and sound engineering judgment.
How are you or your team managing the use of AI tools day to day? Do you feel it accelerates your learning or encourages convenient shortcuts?
I would love to read your thoughts and experiences in the comments. Let us keep learning and building with purpose!
unos días escuchaba una reflexión de Andrew Ng que me tocó de cerca tanto en mi rol como Engineering Manager como en mi faceta de docente universitario: la forma en que la gran mayoría de las personas utiliza la inteligencia artificial hoy en día es absolutamente perjudicial para el aprendizaje.
En una época donde cualquier herramienta puede generar un componente de React, un script de backend o la solución completa a un ejercicio de algoritmos en tres segundos, existe una ilusión generalizada de competencia. Parece que todos somos más productivos, pero debajo de esa velocidad superficial se está gestando un problema silencioso: la atrofia del músculo más importante de un ingeniero de software, que es la capacidad de resolver problemas complejos por cuenta propia.
Si estás empezando en la programación o lideras equipos de desarrollo, esta es una conversación urgente que debemos tener sin filtros.
La observación en las aulas: Del pensamiento crítico al copy-paste ciego
Como profesor en la universidad, he sido testigo directo de la transformación en la dinámica de los estudiantes durante los últimos semestres.
El patrón se repite constantemente: ante un problema que requiere abstracción o diseño algorítmico, el primer impulso ya no es sentarse con papel y lápiz a desglosar el flujo de datos. El primer impulso es arrojar el enunciado a un modelo de lenguaje. Lo más preocupante no es que usen la herramienta, sino que con frecuencia ni siquiera leen con atención la respuesta que la IA les entrega. Copian, pegan en el editor y, si compila o pasa la prueba básica, dan el trabajo por concluido sin haber adquirido el modelo mental de lo que acaba de suceder.
La universidad y los primeros años de carrera no están diseñados únicamente para que entregues código que funcione; están diseñados para que tu cerebro experimente el proceso de enfrentarse a la incertidumbre, cometer errores, depurar y estructurar una solución.
Cuando delegas ese esfuerzo inicial a la máquina, estás tercerizando precisamente el proceso biológico que construye tu criterio técnico.
La gran asimetría: Por qué la IA potencia a los seniors pero vuelve frágiles a los juniors
Existe una diferencia fundamental en cómo interactúa con la IA un desarrollador experimentado frente a uno en formación:
- El desarrollador senior utiliza la IA como un amplificador de velocidad sobre una base de conocimiento ya consolidada. El senior sabe exactamente qué arquitectura busca, reconoce patrones de diseño, detecta vulnerabilidades al vuelo y tiene el criterio para descartar código cuando el modelo alucina o propone soluciones ineficientes.
- El desarrollador junior, al no haber vivido el dolor de construir esas bases a mano, carece del marco de referencia para juzgar la calidad de lo que la IA produce. Se convierte en un operador de sugerencias automáticas en lugar de un arquitecto de software.
La paradoja radica en que la IA resulta fantástica para quien ya sabe programar, pero puede convertirse en una trampa peligrosa para quien apenas está aprendiendo.
Incluso los ingenieros senior deben ser conscientes de este riesgo: si dejamos de enfrentarnos al código en crudo y a la resolución manual de problemas, nuestro propio criterio comenzará a oxidarse con el tiempo.
¿A quién reemplazará realmente la inteligencia artificial?
Se habla constantemente de que la IA va a eliminar los puestos junior en la industria. Mi visión al respecto es muy clara: la IA no reemplazará a los desarrolladores junior con hambre de aprender; reemplazará a los desarrolladores (juniors o seniors) que se limiten a ser intermediarios pasivos entre un prompt y un repositorio.
Si tu único valor añadido es pedirle a un modelo que genere código y pegarlo sin entender cómo funciona la memoria, la concurrencia, el rendimiento o la seguridad de esa solución, tu trabajo es trivialmente automatizable.
Por el contrario, el profesional que domina los fundamentos, que entiende la arquitectura subyacente y que utiliza la IA como un tutor o asistente de exploración (cuestionando sus respuestas y exigiéndole alternativas) se vuelve infinitamente más valioso y difícil de sustituir. La verdadera revolución técnica no consiste en programar menos, sino en pensar con mayor profundidad.
La disciplina de la pizarra: El valor insustituible del esfuerzo deliberado
Para contrarrestar esta trampa cognitiva, hay un hábito que siempre recomiendo a mis alumnos y a los ingenieros que mentoreo: la disciplina de la pizarra (o del cuaderno en blanco).
Cuando te enfrentes a una nueva característica o a un bug complejo:
- Aléjate del prompt en los primeros minutos: Antes de escribir una sola línea de código o abrir un chat de IA, dibuja el flujo en un papel o en una pizarra. ¿Cuáles son las entradas? ¿Cuáles son las salidas? ¿Qué estados intermedios existen?
- Sufre el problema primero: Intenta resolver la lógica por ti mismo. Experimenta el bloqueo, prueba hipótesis y busca en la documentación oficial. Ese pequeño momento de fricción mental es el que genera conexiones neuronales duraderas.
- Usa la IA como tutor socrático, no como generador de atajos: Cuando recurras a la IA, no le pidas "dame el código para solucionar esto". Pídele "revisa mi razonamiento, ¿qué casos borde estoy pasando por alto?" o "explícame por qué este enfoque algorítmico tiene una complejidad temporal superior".
No hacemos las cosas a mano porque la IA sea incapaz de hacerlas; las hacemos a mano porque es la única manera demostrada de desarrollar una mentalidad analítica rigurosa y un criterio de ingeniería sólido.
¿Cómo estás gestionando tú o tu equipo el uso de herramientas de IA en el día a día? ¿Sientes que potencia tu aprendizaje o que a veces fomenta el atajo fácil?
Me encantaría leer tus reflexiones y experiencias en los comentarios. ¡Sigamos aprendiendo y construyendo con criterio!
Sebastian Gomez
Creador de contenido principalmente acerca de tecnología.