Idea intuitiva: es la manera de pensar que usamos cuando organizamos un problema para que una persona o una máquina pueda resolverlo paso a paso.

Fundamento: Jeannette Wing (2006, Communications of the ACM) planteó que el pensamiento computacional es una habilidad fundamental para todas las personas, no solo para los informáticos: resolver problemas, diseñar sistemas y comprender el comportamiento humano apoyándose en conceptos de la informática. Más tarde, Wing (2011) lo describió como los procesos de pensamiento para formular problemas y sus soluciones de modo que una persona o una máquina puedan ejecutarlas con eficacia (citado por Grover y Pea, 2013). Aclaró que no se trata de pensar como una computadora: las máquinas ejecutan; las personas imaginan, deciden y crean. Grover y Pea (2013, Educational Researcher) revisaron el campo y señalaron que aún no hay una definición única, aunque hay acuerdo en elementos como la abstracción, el pensamiento algorítmico, la descomposición y la depuración. Shute, Sun y Asbell-Clarke (2017) llegaron a una conclusión parecida.

Ejemplo (ficticio): la profe Marcela, de 4.°, pide planear la salida a la biblioteca del barrio: qué llevar, en qué orden salir y qué hacer si llueve. Sin computador, sus estudiantes ya están descomponiendo, ordenando y previendo condiciones.

Error frecuente: confundirlo con la clase de sistemas o con manejar ofimática.

Aplicación: identifica un problema de tu área que tus estudiantes resuelvan por pasos y nómbralo así frente a ellos.

Idea intuitiva: un problema grande asusta; dividido en partes pequeñas, se vuelve manejable. Descomponer es partir un problema en subproblemas que se pueden resolver, probar y luego unir.

Fundamento: la descomposición aparece en los marcos revisados por Grover y Pea (2013) y en el informe del Centro Común de Investigación de la Comisión Europea (Bocconi y colegas, 2016). También es una práctica de la escritura, la ingeniería y la investigación: un ensayo se divide en párrafos y un experimento en etapas.

Ejemplo resuelto (ficticio): en 3.°, el profe Hernán propone organizar la venta de empanadas para la feria escolar. Paso 1: el grupo escribe la meta («recoger fondos para la salida»). Paso 2: la divide en partes: ingredientes, precio, turnos, publicidad y cuentas. Paso 3: cada equipo toma una parte y la vuelve a dividir si sigue siendo grande. Paso 4: los equipos comprueban que su parte encaje con las demás; por ejemplo, que el precio cubra el costo de los ingredientes. Así se trabaja también dinero y cambio.

Error frecuente: dividir en partes que dependen tanto entre sí que nadie puede avanzar solo.

Aplicación: pide a tu grupo que descomponga la próxima tarea larga antes de empezarla y que la escriba como lista de subproblemas.

Idea intuitiva: cuando reconocemos que algo se repite, no tenemos que resolverlo desde cero cada vez. Reconocer patrones permite generalizar: crear una regla que sirve para muchos casos.

Fundamento: el reconocimiento de patrones y la generalización están entre los componentes del pensamiento computacional que recoge el informe del JRC (Bocconi y colegas, 2016). En programación, un patrón repetido se convierte en un bucle (repetir) o en un procedimiento reutilizable. En matemáticas se conecta con series y patrones; en lenguaje, con rimas y estructuras de texto; en ciencias, con ciclos como el del agua.

Ejemplo resuelto (ficticio): en 5.°, la profe Diana muestra la serie 3, 7, 11, 15. Paso 1: los estudiantes calculan las diferencias (4, 4, 4). Paso 2: describen la regla con palabras: «se suma 4». Paso 3: la generalizan: el término que ocupa el lugar n es 4 × n − 1. Paso 4: la comprueban con el cuarto término: 4 × 4 − 1 = 15. Paso 5: la usan para predecir el término 10 (39) sin escribir toda la serie.

Error frecuente: «ver» un patrón con dos datos y no comprobarlo con más casos.

Aplicación: incluye en tu próxima clase la pregunta «¿qué se repite aquí y cómo lo diríamos como regla?».

Idea intuitiva: abstraer es quedarse con lo esencial para un propósito y dejar de lado los detalles que no importan. Un mapa de rutas del transporte público no muestra cada árbol ni cada casa: muestra paradas y conexiones, porque eso es lo que necesita el pasajero.

Fundamento: Wing (2006) subrayó que pensar computacionalmente exige pensar en varios niveles de abstracción, y Grover y Pea (2013) la incluyen entre los elementos ampliamente aceptados en los marcos que revisaron. Abstraer exige decidir qué información es relevante, y esa decisión depende del problema: para calcular el área de la cancha importan las medidas, no el color de las líneas.

Ejemplo (ficticio): en 7.°, el profe Julián pide modelar el camino de cada estudiante desde la casa hasta el colegio. Unos dibujan cada tienda; otros, solo cruces, tiempos y distancias. El grupo discute qué versión sirve para estimar quién llega primero y por qué.

Error frecuente: confundir abstracción con «resumen vago». Una buena abstracción es precisa: elimina detalles, pero conserva los datos que sí afectan la solución.

Aplicación: antes de un problema verbal, pide a los estudiantes que tachen los datos que no se necesitan y expliquen por qué los descartaron.

Idea intuitiva: un algoritmo es una secuencia finita de instrucciones precisas y ordenadas que resuelve un problema. Una receta, las indicaciones para llegar a un lugar o el procedimiento de la división son algoritmos.

Fundamento: el pensamiento algorítmico aparece en los marcos que revisaron Grover y Pea (2013). Para que una máquina lo ejecute, el algoritmo debe ser inequívoco: la máquina no «entiende lo que quisiste decir». Por eso escribir algoritmos entrena la precisión del lenguaje.

Ejemplo resuelto (ficticio), actividad «el robot literal»: en 2.°, la profe Luz se convierte en robot y solo obedece instrucciones exactas para guardar un cuaderno en la maleta. Paso 1: un niño dice «guarda el cuaderno» y Luz no se mueve: «¿cuál cuaderno?, ¿dónde está?». Paso 2: el grupo reescribe: «camina tres pasos hacia la mesa», «toma el cuaderno azul», «abre la maleta». Paso 3: Luz ejecuta y, si algo falla, el grupo corrige la instrucción en lugar de culpar al robot. Paso 4: comparan la versión final con la inicial y nombran qué la hizo precisa: orden, cantidades y objetos concretos.

Error frecuente: saltarse un paso porque a nosotros nos parece obvio.

Aplicación: pide a tus estudiantes escribir el algoritmo de un procedimiento de tu área y que otro grupo lo ejecute al pie de la letra.

Idea intuitiva: depurar es encontrar y corregir errores en un algoritmo o programa. En computación el error no es una vergüenza: es lo normal, y el trabajo consiste en hallarlo con método. Es la pedagogía del error en acción: «El error no nos detiene: nos enseña, nos fortalece y nos hace crecer».

Fundamento: la revisión de McCauley y colegas (2008, Computer Science Education) muestra que depurar es una habilidad distinta de escribir código y que los novatos suelen hacerlo al azar, cambiando cosas sin una hipótesis. Quienes tienen experiencia comparan lo que debía pasar con lo que pasó y formulan hipótesis sobre la diferencia. Esa habilidad puede enseñarse de forma explícita.

Rutina de cinco pasos para el aula: 1) ¿Qué debía pasar? 2) ¿Qué pasó en realidad? 3) ¿Dónde empieza la diferencia? 4) Cambio una sola cosa y vuelvo a probar. 5) Explico qué aprendí del error.

Ejemplo (ficticio): en 6.°, Valentina sigue su algoritmo para dibujar un cuadrado en la cuadrícula y le sale una «L». Al revisar paso a paso descubre que repitió «avanza y gira» dos veces, no cuatro.

Error frecuente: corregir el error del estudiante en lugar de enseñarle a encontrarlo.

Aplicación: usa la rutina con un ejercicio mal resuelto de tu propia área.

Idea intuitiva: se puede aprender pensamiento computacional con papel, tarjetas, cuerdas y el propio cuerpo. Esto es valioso en aulas con pocos equipos y en Transición y primeros grados.

Fundamento: el proyecto CS Unplugged, creado en Nueva Zelanda por Tim Bell, Ian Witten y Mike Fellows, reúne actividades gratuitas de este tipo. La revisión de Bell y Vahrenhold (2018) describe cómo se ha usado (divulgación, formación docente y currículos escolares), revisa sus evaluaciones formales y advierte que todavía hay relativamente poca evaluación sistemática de su eficacia: es una puerta de entrada útil, no una garantía. Recomendación del curso: conectar después cada actividad con la programación para que no quede como un juego aislado.

Actividades listas: 1) Números binarios con cinco tarjetas de puntos (16, 8, 4, 2, 1) boca arriba o boca abajo. 2) Imagen por píxeles: colorear una cuadrícula siguiendo un código por filas. 3) Ordenar al grupo por estatura comparando solo de dos en dos. 4) Laberinto en el piso con flechas de cartulina para Transición. 5) El robot literal.

Ejemplo resuelto: con las tarjetas 16, 8, 4, 2 y 1, el número 13 es 8 + 4 + 1; se escribe 01101 (cero para la tarjeta boca abajo).

Error frecuente: quedarse en lo lúdico sin nombrar el concepto.

Aplicación: elige una actividad y ciérrala con la pregunta «¿qué haría una computadora aquí?».

Idea intuitiva: en la programación por bloques, las instrucciones son piezas que encajan como un rompecabezas. No hay que memorizar comandos ni preocuparse por comas: el estudiante se concentra en la lógica.

Fundamento: Scratch fue creado por el grupo Lifelong Kindergarten del MIT Media Lab y se lanzó en 2007. Resnick y colegas (2009, Communications of the ACM) describen su diseño con «piso bajo» (es fácil empezar), «techo alto» (permite proyectos complejos) y «paredes anchas» (admite proyectos muy distintos: historias, juegos, arte, simulaciones). ScratchJr, pensado para niños de 5 a 7 años, usa bloques con íconos y casi sin texto. Ambos son gratuitos, y Scratch tiene una aplicación que funciona sin conexión, útil cuando falla el internet del colegio.

Raíces: esta propuesta viene de Seymour Papert, quien en «Mindstorms» (1980) defendió que los niños aprenden construyendo objetos que pueden compartir y depurar, con el lenguaje Logo y su tortuga.

Ejemplo (ficticio): en Transición, la profe Sandra usa ScratchJr en tabletas compartidas: cada pareja hace que un gato camine hasta su casa con tres bloques.

Error frecuente: dejar que «jueguen con Scratch» sin una meta de aprendizaje.

Aplicación: define qué concepto de tu área modelará el primer proyecto.

Idea intuitiva: para saber qué aprende un estudiante cuando programa conviene mirar tres cosas: qué conceptos usa, cómo trabaja y cómo se ve a sí mismo frente a la tecnología.

Fundamento: Brennan y Resnick (2012), en un trabajo presentado en la reunión anual de la Asociación Estadounidense de Investigación Educativa (AERA), propusieron un marco de tres dimensiones a partir de lo que observaron en jóvenes que creaban con Scratch. Conceptos computacionales: secuencias, bucles, eventos, paralelismo, condicionales, operadores y datos. Prácticas computacionales: trabajar de forma incremental e iterativa, probar y depurar, reutilizar y remezclar, abstraer y modularizar. Perspectivas computacionales: expresarse (crear, no solo consumir), conectarse (crear con y para otros) y preguntar (cuestionar cómo funciona la tecnología).

Ejemplo (ficticio): en 6.°, Mateo hace un juego de preguntas de Ciencias. Usa condicionales y una variable de puntaje (conceptos), lo prueba con su compañera y corrige (prácticas), y decide compartirlo con el curso de 5.° (perspectivas).

Error frecuente: evaluar solo el producto final y no el proceso.

Aplicación: elige un concepto, una práctica y una perspectiva para tu próximo proyecto y escríbelos en la planeación.

Idea intuitiva: igual que en lectura, el pensamiento computacional se construye por niveles. Esta progresión es una propuesta orientativa del curso, no una norma del MEN: ajústala al diagnóstico de tu grupo.

Transición a 2.°: actividades desconectadas, secuencias con flechas, robots de piso o ScratchJr. Conceptos: secuencia, orden y repetición. Bers y colegas (2014, Computers & Education) mostraron que niños de preescolar pueden trabajar ideas de secuencia y depuración con un currículo de robótica adecuado a su edad.

3.° a 5.°: Scratch con historias y juegos sencillos. Conceptos: eventos, bucles, condicionales y variables simples.

6.° a 8.°: Scratch con proyectos de mayor alcance y MakeCode para micro:bit (sensores y medición). Conceptos: variables, operadores, listas y procedimientos.

9.° a 11.°: transición a un lenguaje de texto, por ejemplo Python, con análisis de datos, simulaciones y conexión con proyectos STEAM y con la formación técnica.

Ejemplo (ficticio): el equipo de tecnología de un colegio de la Comuna 15 ubica a sus grupos en este mapa con una tarea diagnóstica corta y descubre que 7.° necesita volver a los bucles antes de usar variables.

Error frecuente: saltar al código de texto sin dominar la lógica.

Aplicación: ubica a tu grupo en la progresión y escribe su siguiente paso.

Idea intuitiva: la computación física une el código con el mundo real: un programa lee un sensor y enciende luces, muestra la temperatura o cuenta movimientos.

Fundamento: la BBC micro:bit es una placa pequeña y de bajo costo con una matriz de 25 luces LED, botones y sensores como el acelerómetro y el de temperatura. Se programa con Microsoft MakeCode, un editor gratuito en el navegador que ofrece bloques, JavaScript y Python, e incluye un simulador: los estudiantes pueden programar y probar en pantalla aunque el colegio no tenga placas. Seguridad: la placa funciona con pilas o con el cable USB del computador; nunca se conecta a la red eléctrica.

Ejemplo resuelto (ficticio), 7.°, Ciencias: el profe Andrés quiere registrar la temperatura del salón. Paso 1: bloque «al presionar el botón A». Paso 2: «mostrar número (temperatura)». Paso 3: lo prueban en el simulador moviendo el control de temperatura. Paso 4: con la placa real toman lecturas a las 7:00, 10:00 y 12:00 y las grafican. Paso 5: discuten un límite: el sensor está en el procesador de la placa, así que la lectura puede diferir algo de la del aire; por eso la comparan con un termómetro.

Error frecuente: comprar equipos sin un plan pedagógico.

Aplicación: prueba el simulador antes de pedir materiales.

Ejemplo 1 (Scratch, 4.°, multiplicación; los nombres de los bloques pueden variar un poco según la versión en español): la profe Paola quiere que el gato pregunte tablas y cuente aciertos.
al hacer clic en la bandera verde
dar a [aciertos] el valor 0
repetir 5
  dar a [a] el valor (número aleatorio entre 2 y 9)
  dar a [b] el valor (número aleatorio entre 2 y 9)
  preguntar (unir (a) (unir « × » (b))) y esperar
  si <(respuesta) = (a * b)> entonces
    sumar a [aciertos] 1
decir (unir «Aciertos: » aciertos)

Cómo se lee: las variables guardan datos; «repetir 5» es un bucle; «si… entonces» es un condicional. La primera versión de Paola tenía un error: había puesto «dar a [aciertos] el valor 0» dentro del bucle, y el juego siempre terminaba en 0 o 1. Depuración: el valor inicial debe asignarse una sola vez, antes del bucle.

Ejemplo 2 (Python, 10.°):
for n in range(1, 11):
    print(n, "x 7 =", n * 7)
Escribe la tabla del 7 del 1 al 10. Si se escribe range(1, 10), solo llega al 9, porque range no incluye el número final: es el típico error «por uno».

Aplicación: pide predecir la salida antes de ejecutar.

Idea intuitiva: antes de pedir que un estudiante escriba un programa desde cero, conviene que lea, prediga y modifique programas que ya funcionan. Es como aprender a escribir leyendo buenos textos.

Fundamento: Sentance, Waite y Kallia (2019, Computer Science Education) describen PRIMM, una secuencia de cinco momentos: Predecir (¿qué hará este código?), Ejecutar (comprobar la predicción), Investigar (rastrear línea por línea y explicar cada parte), Modificar (cambiar algo con una intención) y Crear (un programa nuevo propio). Leer y explicar código antecede a escribirlo, y el apoyo se retira poco a poco, como ocurre con los ejemplos resueltos en otras áreas.

Ejemplo resuelto (ficticio), 8.°: el profe Camilo proyecta un programa de Scratch que dibuja un hexágono. Predecir: en parejas escriben qué figura saldrá. Ejecutar: comprueban quién acertó. Investigar: ¿por qué gira 60 grados? Modificar: lo cambian para obtener un pentágono (giro de 72 grados). Crear: cada pareja dibuja un polígono de su elección y explica el ángulo.

Error frecuente: saltar directo al «crea tu propio juego» con novatos, lo que suele generar frustración o copia sin comprensión.

Aplicación: aplica PRIMM a un programa corto en tu próxima sesión.

Idea intuitiva: en programación el error aparece en casi todos los intentos. Si se enseña bien, el estudiante aprende algo valioso para cualquier área: que equivocarse es información y que se puede salir de un problema con método.

Fundamento: McCauley y colegas (2008) muestran que depurar requiere conocer el programa, el tema y estrategias de búsqueda, y que esas estrategias se pueden enseñar. Brennan y Resnick (2012) incluyen «probar y depurar» entre las prácticas centrales al crear con Scratch.

Rutina «detective del error» (/detective) en cuatro pistas: 1) Reproduce el error: ¿pasa siempre o a veces? 2) Lee el código en voz alta, bloque por bloque, como si fueras la máquina. 3) Aísla: separa partes hasta encontrar dónde nace el fallo. 4) Cambia una sola cosa y vuelve a probar. Al final, el estudiante escribe en su bitácora: «El error era…, lo encontré porque…, la próxima vez…».

Ejemplo (ficticio): en 9.°, Sara no logra que su personaje salte. Al leer en voz alta descubre que el evento era «al presionar la tecla espacio» y ella presionaba la flecha hacia arriba.

Error frecuente: que el docente arregle el código con su propio teclado.

Aplicación: crea con tu grupo un «muro de errores famosos» con lo aprendido de cada uno.

Idea intuitiva: programar obliga a hacer explícito lo que en matemáticas a veces queda implícito: para que el computador dibuje un polígono, el estudiante debe saber qué ángulo girar.

Fundamento: Weintrop y colegas (2016, Journal of Science Education and Technology) proponen una taxonomía para integrar el pensamiento computacional en matemáticas y ciencias con cuatro categorías: prácticas con datos, modelación y simulación, resolución computacional de problemas y pensamiento sistémico.

Ejemplo resuelto (ficticio), 6.°, geometría visual: la profe Natalia pide dibujar polígonos regulares con la extensión Lápiz de Scratch. Código: repetir (n) [mover 60 pasos, girar (360 / n) grados]. Paso 1: con n = 4 giran 90 grados y sale un cuadrado. Paso 2: con n = 3 algunos ponen 60 grados y la figura no cierra; descubren que el giro es el ángulo exterior, 120 grados. Paso 3: generalizan que la suma de los giros es 360 grados. Paso 4: prueban n = 36 con pasos más cortos (por ejemplo, mover 10 pasos, para que quepa en el escenario) y ven una figura que se parece a un círculo.

Matemática financiera: en 9.°, un programa simula el ahorro mensual con interés compuesto y permite comparar escenarios cambiando la tasa o el plazo.

Error frecuente: que el código resuelva todo y el estudiante no explique la matemática.

Aplicación: pide siempre justificar con matemáticas cada número del programa.

Idea intuitiva: en STEAM, el código es una herramienta para preguntar y crear: medir, simular, componer y diseñar.

Ciencias: con micro:bit se registran datos de luz o temperatura y se comparan con predicciones (ciclo predigo, observo, explico). Con Scratch se simula un fenómeno sencillo, como la caída de un objeto o la propagación de un rumor en un grupo, y se discute qué deja por fuera el modelo: toda simulación simplifica.

Arte y música: patrones geométricos con bucles, animación de un cuento propio y ritmos con la extensión de música de Scratch.

Lenguaje: historias interactivas con decisiones del lector; los condicionales («si eliges A, pasa…») hacen visible la estructura narrativa.

Ejemplo (ficticio), proyecto de 8.°: «¿Cuál es el salón más caluroso del colegio?». Matemáticas: promedios y gráficas. Ciencias: transferencia de calor y control de variables. Tecnología: programa de registro con micro:bit. Arte: infografía para la comunidad. Ética: no registrar datos personales.

Límite: si el tiempo de programación se come el tiempo del contenido, el proyecto pierde sentido; planea qué aprendizaje de cada área se evaluará.

Error frecuente: proyectos vistosos sin pregunta de investigación.

Aplicación: escribe la pregunta guía de un proyecto que una dos áreas.

Pregunta clave: ¿aprender a programar mejora el desempeño en otras áreas? La respuesta honesta es «en parte, y con condiciones».

Evidencia: el metaanálisis de Scherer, Siddiq y Sánchez Viveros (2019, Journal of Educational Psychology) encontró un efecto de transferencia moderado en promedio (g = 0,49), mayor para la transferencia cercana (g = 0,75), es decir, a tareas de programación o de pensamiento computacional parecidas a las practicadas, que para la lejana (g = 0,47), a otras habilidades cognitivas. Dentro de la transferencia lejana, hubo efectos en pensamiento creativo, habilidades matemáticas, metacognición, razonamiento y habilidades espaciales; el rendimiento escolar general y la lectoescritura fueron los que menos se beneficiaron. Además, los efectos fueron mayores en estudios con grupos de control sin intervención que con controles activos, y en estudios publicados que en literatura gris, lo que pide cautela.

Por otra parte, Román-González y colegas (2017, Computers in Human Behavior) encontraron que el pensamiento computacional se relaciona con el razonamiento y las habilidades espaciales: no es una habilidad aislada, aunque una correlación no prueba causa.

Implicación: la transferencia no ocurre sola. Si quieres que la programación ayude en matemáticas, enseña de forma explícita la conexión y evalúala.

Error frecuente: prometer a las familias que programar «sube los puntajes» en todas las áreas.

Aplicación: escribe qué transferencia esperas y cómo la comprobarás.

Idea intuitiva: un producto puede funcionar aunque el estudiante no entienda por qué, y puede fallar aunque haya razonado muy bien. Por eso se evalúa el proceso además del resultado.

Fundamento: Brennan y Resnick (2012) proponen evaluar con el análisis de los proyectos, entrevistas sobre el producto («cuéntame cómo hiciste esto») y escenarios de diseño en los que el estudiante explica, corrige o amplía un proyecto ajeno, y sugieren combinar métodos porque cada uno capta algo distinto. Es coherente con el Decreto 1290 de 2009, que entre los propósitos de la evaluación incluye consolidar o reorientar los procesos educativos.

Mini-rúbrica (niveles: bajo, básico, alto, superior): 1) Descomposición: divide el problema en partes coherentes. 2) Algoritmo: usa secuencias, bucles y condicionales correctos y sin pasos sobrantes. 3) Depuración: identifica el error, formula una hipótesis y documenta la corrección. 4) Comunicación: explica su código y su relación con el contenido del área.

Ejemplo (ficticio): en 10.°, el profe Felipe pide a cada pareja un audio de dos minutos explicando un error que tuvo y cómo lo resolvió. Descubre que una pareja con un proyecto impecable no podía explicar su propio código.

Error frecuente: calificar solo si «funciona».

Aplicación: adapta la rúbrica a tu próximo proyecto.

Idea intuitiva: el pensamiento computacional es para todos, no solo para quienes «son buenos en matemáticas» o tienen computador en casa.

Fundamento: el Diseño Universal para el Aprendizaje (CAST, pautas 3.0, 2024) propone ofrecer múltiples formas de implicación, de representación y de acción y expresión. En Colombia, el Decreto 1421 de 2017 reglamenta la atención educativa a la población con discapacidad, con ajustes razonables y el Plan Individual de Ajustes Razonables (PIAR). En programación esto se traduce en actividades desconectadas y manipulativas además de la pantalla; bloques con íconos para quienes aún no leen con fluidez; temas elegidos por el estudiante; y trabajo en parejas con roles que rotan: quien maneja el teclado y quien guía.

Equidad: muchos estudiantes no tienen computador en casa; las tareas que requieren equipo se hacen en el colegio o tienen una versión en papel. Cuida también que las niñas tengan igual protagonismo: rota los roles y muestra referentes diversos.

Ejemplo (ficticio): Samuel, de 4.°, tiene baja visión; trabaja con la pantalla ampliada y con una versión táctil del laberinto en cartulina con relieve.

Error frecuente: dejar que el más rápido haga todo mientras los demás miran.

Aplicación: define roles rotativos para tu próximo trabajo en parejas.

Idea intuitiva: hoy una IA generativa puede escribir código en segundos. Eso no vuelve inútil aprender a programar: hace más importante entender, leer y verificar el código.

Fundamento: la Guía de la UNESCO para la IA generativa en la educación y la investigación (2023) pide un uso centrado en las personas, con validación humana, protección de datos y atención a la edad, y propone 13 años como edad mínima para usar estas herramientas en el aula. El marco de competencias en IA para estudiantes de la UNESCO (2024) incluye comprender cómo funcionan estos sistemas y usarlos con ética.

Usos recomendados: pedir a la IA que explique un programa línea por línea y luego comprobar la explicación; comparar la solución propia con la de la IA; usarla para proponer casos de prueba. Uso que conviene evitar con novatos: copiar código generado sin leerlo, porque se pierde la práctica de razonar y depurar. La IA también se equivoca: su código puede tener errores o soluciones innecesariamente complejas.

Ejemplo (ficticio): en 11.°, la profe Alejandra entrega un programa generado por IA con dos errores ocultos; los estudiantes los encuentran con la rutina del detective.

Error frecuente: prohibir sin enseñar o permitir sin verificar.

Aplicación: diseña una actividad en la que la IA sea objeto de verificación.

Idea intuitiva: cuando los estudiantes crean y comparten en internet, también dejan rastros. Enseñar a programar incluye enseñar a cuidarse.

Fundamento: la Ley 1581 de 2012 protege los datos personales en Colombia y exige autorización para su tratamiento; en el caso de niños, niñas y adolescentes prima el respeto de sus derechos y su interés superior. Por eso, en proyectos escolares: no publicar nombres completos, fotos, voces ni ubicaciones de estudiantes; usar seudónimos en los usuarios; preferir cuentas de clase administradas por el docente (Scratch ofrece cuentas de profesor para crear cuentas de estudiantes) y revisar los términos de cada plataforma, incluidos los requisitos de edad.

Ciudadanía digital que se integra bien: contraseñas seguras y no compartidas; crédito al remezclar proyectos de otros; comentarios respetuosos; y qué hacer ante un contacto o contenido que incomoda: avisar a un adulto y activar la ruta institucional de la Ley 1620 de 2013.

Ejemplo (ficticio): un grupo de 7.° quiere publicar su juego con fotos de compañeros como personajes. La profe Liliana propone usar dibujos propios y nombres inventados.

Error frecuente: crear cuentas con correos personales de los estudiantes sin autorización de las familias.

Aplicación: revisa la configuración de privacidad de la plataforma que usas.