Déjenme comenzar donde siempre comienzo, porque el marco importa más que la respuesta. Es el mismo reto que enfrentamos con la educación en su conjunto. Sabes que la tienes que cambiar. Todos lo saben. La dificultad nunca fue si cambiarla — el reto está en cambiarla bien. Las reformas fracasan no porque la gente se resista al cambio, sino porque cambian lo que no era, botan lo que sostenía la estructura y conservan lo decorativo. Así que antes de decidir si eliminamos la programación del currículo, deberíamos tener muy claro qué era lo que la programación realmente enseñaba. Porque nunca fue realmente enseñar «programación».
La programación es la nueva matemática
La relevancia de la programación hoy es como la relevancia de las matemáticas. Y digo matemáticas deliberadamente — para esquivar la discusión más dura y más ruidosa sobre la relevancia de la química o de las otras ciencias — porque con las matemáticas casi todo el mundo ya acepta el punto. No enseñamos aritmética a los niños porque esperemos que pasen su vida adulta haciendo divisiones largas a mano. Tenemos calculadoras desde hace cincuenta años. La enseñamos porque construye algo por debajo: sentido numérico, razonamiento estructurado, la capacidad de pasar de una situación real y desordenada a un modelo abstracto y de vuelta.
Con la programación pasa lo mismo. El valor nunca fue la sintaxis. Era el fundamento — el pensamiento estructurado y el pensamiento de procesos. Es aprender a descomponer un problema en pasos, a nombrar y seguir el estado, a razonar sobre qué ocurre bajo qué condición, a construir algo que se comporta de forma predecible a partir de piezas que individualmente hacen muy poco. Eso no es una habilidad de programación. Es una habilidad de pensamiento que la programación resulta enseñar inusualmente bien.
Así que cuando alguien pregunta «¿hará la IA obsoleta la programación como las calculadoras hicieron obsoleta la aritmética?», mi respuesta es: fíjense en que las calculadoras no hicieron obsoleta la aritmética. Hicieron opcional el cálculo manual y volvieron la comprensión subyacente más importante, no menos — porque ahora la persona que entiende el modelo, y no solo el botón, es la que puede darse cuenta de cuándo la respuesta está mal.
Lo que realmente perdura
Si la sintaxis no es el punto, ¿qué lo es? Cuando lo reduzco hasta el fondo, lo que perdura se sostiene en tres ejes:
- Técnico — la capacidad de generar especificaciones. Decir con precisión qué debe hacer una cosa: sus entradas, sus salidas, sus estados, sus reglas, sus casos límite. Una IA construirá casi cualquier cosa que puedas especificar bien. Construirá disparates, bellamente, a partir de una especificación vaga.
- Creativo — la capacidad de visualizar e imaginar. Ver la cosa que aún no existe, sostenerla en la cabeza, imaginar cómo se comporta antes de que se escriba una sola línea.
- Productivo — la capacidad de estructurar, articular e interconectar. Tomar ideas, conceptos y funcionalidades y organizarlos en algo coherente — ver cómo se relacionan las piezas y dónde se conectan.
Miren esa lista otra vez y noten algo: ninguna de las tres es una habilidad de programación, y las tres son exactamente lo que no se puede delegar en una IA. La máquina es ahora extraordinaria produciendo el código. Sigue dependiendo por completo de un humano capaz de especificar, imaginar y estructurar. Esa es la parte que vale la pena enseñar. Esa es la parte que vale la pena proteger.
Una prueba personal a la que siempre vuelvo
Permítanme hacerlo concreto con mi propia vida, porque es la evidencia más clara que tengo. Todavía hoy sorprendo y produzco cosas reales con las habilidades de programación que aprendí por mí mismo a los nueve años en una Texas Instruments TI-99/4A, y que luego profundicé a los catorce en un par de cursos de IBM — COBOL y bases de datos en un System/34. Esas dos experiencias marcaron mi vida. Nunca volví a tomar un curso de programación. Ni uno. Y he entregado sistemas de misión crítica y plataformas de uso público, y supervisado su desarrollo.
Así que claramente hay algo ahí que no debemos descuidar. Cuando me pregunto qué era, la respuesta es siempre la misma: era la estructura. La base — variables, rutinas, procesos. Todo lo que construí después se construyó sobre ese fundamento, puesto antes de mis quince años y nunca revisado formalmente.
Y aquí está la señal. A lo largo de las décadas vi la programación evolucionar por técnicas y paradigmas que nunca aprendí formalmente. Pero como tengo la base, puedo leer y entender prácticamente cualquier código, en casi cualquier lenguaje. No sé programar en Python — nunca lo he aprendido — pero puedo leer Python y entender exactamente qué está haciendo. Las funciones cambian, las estructuras cambian; la lógica subyacente es legible para cualquiera que tenga el fundamento. Esa legibilidad, esa transferibilidad entre lenguajes y a través de cuarenta años, es lo que la escuela debería intentar instalar. Sobrevive a cada tecnología específica a través de la cual se enseñó.
Lo que yo enseñaría en concreto
Entonces, en concreto: si los niños aprenden a hacer cosas en Scratch, eso probablemente los deja cubiertos en los fundamentos — conocen procedimientos, estructuras de datos, variables, bucles, condiciones, secuencias. Eso es un fundamento real. Luego, dependiendo de la edad, yo añadiría el vocabulario de modelado y estructuración que convierte una intención vaga en algo construible:
- Diagramas de flujo — que la mayoría de los currículos ya introducen — para razonar sobre procesos y flujo de control.
- Diagramas Entidad-Relación y de Relación de Objetos — para pensar con claridad sobre los datos y cómo se relacionan las cosas.
- Arquitectura de software en capas — para entender cómo un sistema separa responsabilidades en lugar de convertirse en una masa indiferenciada.
- Y para los estudiantes mayores, un ascenso de los diagramas de flujo a BPMN (Business Process Model and Notation) — el mismo instinto, escalado a procesos y organizaciones reales.
Y luego — esta es la parte que responde la pregunta real de mi amiga — les enseñaría a ejecutar lo que diseñaron con vibe coding. Que la IA haga la mecanografía. Que el estudiante haga el pensamiento que le dice a la IA qué escribir. Eso no es una concesión; es la división del trabajo correcta para la era en la que realmente estamos. El diseño es del humano. La ejecución es aumentada. El juicio sobre si el resultado está bien se queda, siempre, con la persona que entiende la estructura por debajo.
La trampa: dos vibras y nadie aprendiendo
Pero yo mantendría Scratch — y quiero ser preciso sobre el porqué, porque es el quid de toda la pregunta. Lo mantendría por la razón construccionista de Seymour Papert: los niños aprenden de forma más duradera haciendo — construyendo una cosa externa que pueden mirar, probar, romper y arreglar. Y lo mantendría por una segunda razón que la gente olvida: la mano, el ojo y la mente comprometidos juntos en el trabajo. El compromiso físico y mental no es incidental al aprendizaje — en los primeros años, puede que sea el aprendizaje.
Porque este es el modo de fallo hacia el que estamos caminando directo. Si no tenemos cuidado, el estudiante va a «vibrar» la conceptualización — gesticular vagamente hacia lo que quiere — y la IA va a «vibrar» el código, y un artefacto terminado aparecerá en la pantalla. Y parecerá un éxito. Y nadie habrá aprendido nada. Dos vibras, un artefacto, cero fundamento. Eso no es educación; eso es tercerizar con pasos adicionales. El punto entero de construir el fundamento es que es lo único que no se puede «vibrar» a la existencia — tiene que ser construido, por quien aprende, a través de la dificultad productiva de realmente hacer algo.
Cámbiala — pero cámbiala bien
Así que mi respuesta a mi amiga, y a cada colegio y universidad y padre que se haga la misma pregunta este año, no es «mantengan la programación» y no es «eliminen la programación». Es: entiendan qué era lo que la programación realmente enseñaba, conserven eso con todo lo que tengan, y cambien la entrega a su alrededor. Conserven el hacer. Conserven la estructura. Conserven el vocabulario de modelado. Añadan la IA como ejecutora de una intención humana bien especificada, bien imaginada, bien estructurada. Y nunca dejen que la herramienta haga la única parte — el fundamento — que solo quien aprende puede construir por sí mismo.
Sabes que la tienes que cambiar. El reto entero está en cambiarla bien.
Un borrador de trabajo. Este ensayo expone mi posición; una próxima revisión incorporará investigación con fuentes — la literatura del construccionismo, los estudios sobre pensamiento computacional, los orígenes del «vibe coding» y la evidencia actual de la ciencia cognitiva sobre aprendizaje e IA — con citas completas. Si tiene trabajos que yo deba leer antes, dígamelo. — Carlos Miranda Levy
Las cuatro perspectivas
La versión más fuerte de este argumento es la afirmación de transferencia: que lo que la instrucción en programación construye es una capacidad general de razonamiento estructurado que sobrevive a cualquier lenguaje. Esa afirmación es plausible y es también exactamente el tipo de cosa que la literatura de investigación trata con cautela, porque la transferencia es notoriamente difícil de demostrar. Así que el encuadre honesto es el que usa Carlos — conservar el hacer, porque el hacer es donde la evidencia es más sólida — en lugar de apoyar todo el caso en una afirmación amplia de transferencia que habría que matizar. Cuando llegue la revisión con fuentes, la literatura del pensamiento computacional y del construccionismo es donde yo la anclaría.
Mi preocupación es la equidad, y corta en una dirección incómoda. «Que la IA escriba el código» suena liberador, pero los estudiantes que todavía aprenderán el fundamento son los de colegios con docentes que entienden la diferencia entre diseñar y vibrar. Los estudiantes de escuelas con menos recursos son los que con mayor probabilidad recibirán la herramienta con el mensaje de que con eso basta. Si no somos deliberados, «la IA escribe el código» se convierte en un mecanismo para ampliar la brecha mientras aparenta ser acceso. El vocabulario de modelado que Carlos enumera — diagramas de flujo, diagramas entidad-relación, BPMN — es barato de enseñar y difícil de fingir. Exactamente por eso pertenece a todas las escuelas, no solo a las innovadoras.
En lo práctico: mantengan Scratch para los pequeños, añadan los diagramas a medida que crecen y sí — que entreguen cosas reales con IA, absolutamente. El error que van a cometer algunas escuelas es prohibir la herramienta por miedo. El otro error es entregarla sin estructura. Hagan las dos cosas a la vez: que lo diseñen primero en papel o en un diagrama, que luego lo construyan con IA, y que después expliquen por qué funciona. El paso de la explicación es todo el juego. Si pueden explicar por qué funciona, aprendieron algo. Si no pueden, lo vibraron — y usted los atrapó.
Aprendí a programar por mi cuenta a los nueve años y tomé mi último curso de programación a los catorce, y todavía hoy sigo construyendo sobre ese fundamento. Eso no es nostalgia — es evidencia. Lo que perduró nunca fue el lenguaje; fue la estructura. Así que cuando un colegio me pregunta si debe seguir enseñando programación, escucho una pregunta distinta por debajo: ¿vamos a seguir enseñando a los niños a pensar en estructuras, a especificar con precisión, a imaginar y luego organizar lo que imaginaron? La respuesta a esa pregunta tiene que ser sí, y se vuelve más cierta, no menos, a medida que las máquinas mejoran en la mecanografía. Cambien el currículo. Solo no boten, al cambiarlo, lo único que vale la pena conservar.