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. Y la evidencia de aula sobre las calculadoras dice algo preciso que aplica directamente aquí: el beneficio aparecía cuando la herramienta se entretejía en una enseñanza diseñada en torno a ella, mientras que ponerla en manos de los niños demasiado pronto, sin estructura, podía de hecho frenar sus habilidades. La herramienta nunca fue el punto. Cuándo y cómo la introduces, sí.

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ñó. Debo ser honesto: esto es experiencia vivida más que ciencia asentada — la investigación encuentra que esta clase de transferencia es fuerte hacia problemas cercanos y solo modesta hacia los lejanos. Pero la transferencia cercana, llevar la base de un lenguaje al siguiente, es exactamente lo que es un fundamento.

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.

Si alguno de esos les resulta desconocido, aquí está cómo se ve cada uno en realidad — ninguno es complicado, y ese es justamente el punto:

Inicio Leer un número ¿Residuo = 0? No Es impar Es par Fin
Un diagrama de flujo: el óvalo inicia y termina el proceso, un rectángulo es un paso, y un rombo es una decisión que ramifica el camino.
muchos muchos ESTUDIANTE id_estudiante (PK) nombre se inscribe en CURSO id_curso (PK) título
Un diagrama entidad-relación: cada caja es algo sobre lo que guardas datos (una entidad), el rombo es cómo se relacionan, y “muchos a muchos” significa que un estudiante toma muchos cursos y un curso tiene muchos estudiantes.
es un tiene un Vehículo velocidadruedas mover() Auto marca conducir() Motor potencia arrancar()
Un diagrama objeto-relación (de clases): cada caja es un tipo de objeto con sus datos (arriba) y sus acciones (abajo). Las flechas muestran cómo se relacionan — un Auto “es un” Vehículo y “tiene un” Motor.
↓ solicitudes datos ↑
Presentación
lo que ve el usuario — pantallas, botones
Lógica de negocio
las reglas — lo que la app decide y hace
Acceso a datos
leer y escribir datos
Base de datos
donde viven los datos
Arquitectura en capas: cada capa solo habla con la que tiene directamente debajo. Separar responsabilidades evita que un sistema se vuelva una masa enredada.
Escuela Docente Coordinación No Idea de clase Enviar plan de clase Revisar y reenviar Revisar el plan ¿Aprobado? Publicar en el calendario
El mismo proceso en BPMN, ahora con carriles (swim lanes). Cada carril es un rol, y el flujo que cruza entre carriles muestra exactamente quién hace qué y dónde ocurre una entrega. Ese traspaso entre roles es lo que un diagrama de flujo no puede mostrar — y es el rasgo más distintivo de BPMN.

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.

De la teoría a la práctica: por dónde puede empezar un colegio de K-12

Para que esto no se quede en teoría — y porque sé que la mayoría leemos queriendo una respuesta clara, no solo un marco — permítanme ser concreto para los colegios de K-12. Si aún no tienen un programa de programación, o buscan transformar el que tienen, entonces, más allá de Scratch, hay algunos programas que les recomendaría directamente. Son completamente gratuitos, orientados a K-12, avalados por educadores y aprobados para su uso en escuelas; pueden adoptarlos o adaptarlos sin costo alguno, con los materiales de apoyo que un docente realmente necesita — guías para el maestro, planes de clase, ejemplos resueltos, videos. Están disponibles en varios idiomas. Y cada uno da a los estudiantes suficiente fundamento para captar la lógica y los elementos críticos de las ciencias de la computación mientras se divierten y construyen cosas reales.

  • Code.org — ahora CodeAI. La legendaria iniciativa Code.org se renombró en junio de 2026 como CodeAI, desplazando su énfasis de las ciencias de la computación hacia lo que llama fluidez digital (digital fluency) — que sigue conteniendo a las ciencias de la computación dentro, junto a las ciencias de la IA y de los datos. Y tengo que decirlo — fluidez digital es el término que muchos veníamos buscando. Ni siquiera es nuevo: Mitchel Resnick, la mente detrás de Scratch, lo usa desde hace dos décadas para significar diseñar, crear y remezclar — no solo navegar y chatear. Es pegadizo, y transmite exactamente de lo que trata este ensayo: fluidez, y preparación para lo que venga.
  • Experience CS, de la Raspberry Pi Foundation con el apoyo de Google.org — un programa excelente para primaria y secundaria, completo con planes de clase, rúbricas y guías para el maestro. experience-cs.org
  • Code Club. Si quieren hacerlo más divertido y participativo, pueden postularse para crear un Code Club y unirse a una red de clubes en todo el mundo — también de la Raspberry Pi Foundation.

Empiecen por ahí. Fíjense en que todo lo que construyen estos programas es el fundamento que he venido defendiendo: lógica, estructura, la alegría de crear algo real — la parte que la IA no puede construir por el estudiante, por muy bien que escriba el código.

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.

Las afirmaciones de este ensayo están respaldadas por las fuentes reunidas más abajo. Para conocer cómo se verificaron esas fuentes — y la infografía hecha con IA que decidí no publicar — vea la pieza complementaria, La infografía que no publiqué. — Carlos Miranda Levy

Las cuatro perspectivas

Dra. Saya Nakamura-Ellis
Dra. Saya Nakamura-EllisLa Clasicista

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.

Prof. Marcus Okonkwo-Brandt
Prof. Marcus Okonkwo-BrandtEl Experiencialista

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.

Zara Chen-Rodriguez
Zara Chen-RodriguezLa Futurista

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ó.

Carlos Miranda Levy
Carlos Miranda LevyEl Curador

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.

Fuentes y lecturas recomendadas

Este ensayo es un argumento personal. Las referencias siguientes son las fuentes primarias verificadas tras sus afirmaciones factuales — reunidas mediante investigación profunda y comprobadas. Donde la evidencia es genuinamente mixta (en particular cuánto se transfieren las habilidades del pensamiento computacional, y los estudios aún preliminares sobre IA y aprendizaje), las fuentes lo indican.

Vibe coding y el debate sobre aprender a programar

  • Andrej Karpathy, the “vibe coding” post, X, 2 February 2025. x.com/karpathy
  • Simon Willison, “Not vibe coding” (on the term’s precise meaning), simonwillison.net, 1 May 2025.
  • Matt Welsh, “The End of Programming,” Communications of the ACM, January 2023. doi:10.1145/3570220
  • Jensen Huang, remarks at the World Governments Summit, Dubai, February 2024.
  • TeachAI & CSTA, “Computer Science Education More Important than Ever in an Age of AI” (joint guidance), 2024.
  • Mark Guzdial, “Learning to Program Matters … in the Age of AI,” Medium, 2024.

Pensamiento computacional y construccionismo

  • Jeannette M. Wing, “Computational Thinking,” Communications of the ACM 49(3), 2006. doi:10.1145/1118178.1118215
  • Seymour Papert, Mindstorms: Children, Computers, and Powerful Ideas, Basic Books, 1980.
  • Mitchel Resnick et al., “Scratch: Programming for All,” Communications of the ACM 52(11), 2009. doi:10.1145/1592761.1592779
  • Scherer, Siddiq & Sánchez Viveros, “The cognitive benefits of learning computer programming: A meta-analysis of transfer effects,” Journal of Educational Psychology, 2019. (Near transfer strong; far transfer modest — the caveat behind the essay’s “foundation” claim.)

La ciencia cognitiva del aprendizaje frente a la delegación

  • Slamecka & Graf, “The generation effect: Delineation of a phenomenon,” Journal of Experimental Psychology, 1978. doi:10.1037/0278-7393.4.6.592
  • Robert A. Bjork & Elizabeth L. Bjork, “Desirable difficulties in theory and practice,” Journal of Applied Research in Memory and Cognition 9(4), 2020.
  • John Sweller, “Cognitive load during problem solving: Effects on learning,” Cognitive Science 12(2), 1988.
  • Kosmyna et al., “Your Brain on ChatGPT,” arXiv:2506.08872, 2025. (Preprint, not peer-reviewed — suggestive, not conclusive.)
  • Lee et al., “The Impact of Generative AI on Critical Thinking,” CHI 2025. doi:10.1145/3706598.3713778 (Self-reported, correlational.)

Las herramientas de modelado

  • Peter Pin-Shan Chen, “The Entity-Relationship Model — Toward a Unified View of Data,” ACM Transactions on Database Systems 1(1), 1976. doi:10.1145/320434.320440
  • Grady Booch, James Rumbaugh & Ivar Jacobson, the Unified Modeling Language (UML), adopted by the Object Management Group, 1997.
  • Object Management Group, Business Process Model and Notation (BPMN) — v1.0 (2004), OMG-maintained since 2005; also ISO/IEC 19510.
  • Frank & Lillian Gilbreth, “Process Charts” (the flow-process chart), ASME, 1921.

La historia como analogía: el debate de la calculadora

  • Hembree & Dessart, “Effects of Hand-Held Calculators in Precollege Mathematics Education: A Meta-Analysis,” Journal for Research in Mathematics Education 17(2), 1986. (Benefits when integrated into instruction; early unstructured use could hinder — outcomes depend on how and when, not on the tool alone.)
  • Ellington, “A Meta-Analysis of the Effects of Calculators on Students’ Achievement and Attitude Levels,” JRME 34(5), 2003.
  • National Council of Teachers of Mathematics, Principles and Standards for School Mathematics, 2000.

Programas gratuitos de K-12 y la «fluidez digital»

  • Code.org, “Code.org is now CodeAI,” 2 June 2026 (code.org); reported by GeekWire, 2 June 2026. (CodeAI retains computer science within “digital fluency,” alongside AI science and data science.)
  • Mitchel Resnick, on “digital fluency” — designing, creating, and remixing, not just browsing and chatting (MIT Media Lab, 2002; restated in the 2009 Scratch paper).
  • Raspberry Pi Foundation, Experience CS — free CS curriculum for ages 8–14, with Google.org (experience-cs.org), 2025.
  • Raspberry Pi Foundation, Code Club — global network of free coding clubs (codeclub.org), since 2012.
  • Plan Ceibal, Uruguay — national one-laptop-per-child program, launched 2007.