Todo el mundo trata a Claude como un oráculo de pueblo: le preguntas, te da una respuesta con la voz segura de quien nunca se ha equivocado, cierras la pestaña y ya está. El capítulo 8 dice, con otras palabras, algo que cualquiera que haya corregido un examen lleva años sabiendo sin necesidad de inteligencia artificial: la respuesta más convencida no es siempre la más correcta. A Víctor Vílchez, el científico escéptico de mis relatos, esto no le habría sorprendido nada — es el mismo principio con el que desenmascara charlatanes, solo que aquí el charlatán potencial no tiene mala intención, simplemente no siempre sabe que se equivoca.

Este documento coge las cuatro ideas del capítulo — leer bien el formato, saber si la respuesta es buena, regenerar con criterio, construir la conversación en varios turnos — y las cuelga de tres ganchos que ya son mi día a día: explicar qué es la IA, la robótica (micro:bit, Arduino, ESP32, CanSat y AstroPi), y una pieza de ciencia ciudadana que, para cuando leáis esto, puede que ya sea historia reciente: el eclipse del 12 de agosto.

Cada ejercicio de aquí en adelante sigue el mismo esquema: qué se aprende, cómo se hace paso a paso con el prompt exacto, y por qué (y cómo) la primera respuesta casi nunca es la definitiva.

---

Antes de nada: la actividad estrella (literalmente)

El 12 de agosto de 2026 hay un eclipse solar total. Desde Estepona no lo veremos total — lo veremos parcial, pero con el 94,5% del Sol cubierto, que para efectos prácticos es casi lo mismo que una tarde de invierno cayendo de golpe en pleno agosto. Empieza a las 19:43, el momento de máximo oscurecimiento es a las 20:38, con el Sol casi tocando el horizonte hacia el oeste-noroeste, y se acaba fundiéndose con la propia puesta de sol hacia las 21:30.

El problema, y aquí no hay ironía posible que lo arregle: es pleno agosto, no hay clase. Así que la captura de datos la hago yo (con el móvil, con una cámara, con lo que tenga a mano — temperatura, luz ambiental, fotos a intervalos regulares) y me la guardo para septiembre. El material de este documento está pensado para que, cuando vuelva el curso, el eclipse ya no sea un enlace a un CSV de Wyoming de hace nueve años, sino algo que pasó de verdad, encima de nuestras cabezas, en Estepona.

Qué necesito capturar antes del 21:30 del 12 de agosto: hora exacta de cada medida, nivel de luz ambiental (con un LDR y una micro:bit o un móvil con app de luxómetro), temperatura si es posible, y un par de fotos con el móvil a intervalos de 10-15 minutos desde las 19:30 hasta el anochecer. Con eso ya hay material de sobra para las tres etapas.

---

Los tres hilos, explicados una vez

Explicar la IA. En todos los niveles vamos a pedirle a Claude que se explique a sí mismo — qué es un token, qué es entrenar un modelo, por qué a veces suena convencido y se equivoca igual.

Robótica. Micro:bit en 1º de ESO (bloques, sensores simples), Arduino y ESP32 conforme se sube de nivel (código, IoT), y CanSat/AstroPi en 2º de Bachillerato.

Ciencia ciudadana con el eclipse. El hilo que cierra el curso: datos reales, capturados por nosotros, en nuestra ciudad.

---

1º ESO — Computación y Robótica

Ejercicio 1 — Leer antes de copiar

Qué van a aprender: que una respuesta de Claude con código no se copia de arriba abajo sin leerla — primero se lee todo, después se ejecuta.

Paso a paso:

1. Le pides a Claude que arregle o explique un programa de micro:bit o Arduino (por ejemplo, el del sensor de luz que ya conocemos).
2. Antes de tocar el ordenador, cada alumno subraya en la respuesta, con un color, el texto explicativo (lo que va antes o después del código), y con otro color, los comentarios que hay dentro del propio código.
3. Si algún bloque de código no tiene ninguna frase explicando por qué está ahí, ese es motivo para preguntar, no para copiarlo a ciegas.

Prompt de ejemplo:

Aquí tienes mi programa de micro:bit para el sensor de luz. Antes de darme el
código corregido, explícame primero, en 2-3 frases, cuál es el error y por
qué produce ese fallo.

Por qué la respuesta se puede mejorar, y cómo: si Claude responde solo con el código corregido y sin explicación, la respuesta técnicamente “funciona” pero no enseña nada. Se puede pedir explícitamente: “Antes de darme el código, explícame el fallo en pocas palabras” — igual que ya hicimos con el sensor de luz, cuando pedimos el diagnóstico antes que la solución completa.

---

Ejercicio 2 — Cuando Claude “suena seguro” pero no lo es tanto

Qué van a aprender: que una explicación puede sonar muy segura y, aun así, estar simplificando o callándose matices importantes.

Paso a paso:

1. Pedir una explicación normal de qué es la inteligencia artificial.
2. Pedir la misma explicación pero exagerando la seguridad con la que debe sonar.
3. Comparar las dos, frase a frase, y marcar qué matices (los “depende”, “no siempre”, “en general”) desaparecen en la segunda versión.

Prompts de ejemplo:

Prompt 1: Explícame qué es la inteligencia artificial, como si tuviera 12 años.

Prompt 2: Explícame qué es la inteligencia artificial, pero que suene
totalmente seguro y sin ninguna duda, como si fuera un hecho indiscutible.

Por qué la segunda respuesta “mejora” en tono pero empeora en honestidad: al pedir más seguridad, Claude tiende a quitar matices reales (por ejemplo, que “la IA no entiende como una persona” es una simplificación con más capas detrás). La mejora aquí no es pedirle una tercera versión: es que el alumnado aprenda a detectar cuándo un texto suena demasiado seguro para ser del todo cierto, en cualquier fuente, no solo en Claude.

---

Ejercicio 3 — Regenerar con criterio, no a lo tonto

Qué van a aprender: que cuando un resultado no está bien, no se trata de pulsar “reintentar” y esperar suerte, sino de decir exactamente qué falta.

Paso a paso:

1. Ejecutar el programa de la micro:bit que enciende los LEDs con poca luz (el que ya hicimos).
2. Comprobar en la placa real: ¿se apagan los LEDs cuando vuelve la luz?
3. Si no se apagan, no decir solo “no funciona bien” — decir la pieza exacta que falta.

Prompt de ejemplo (el que ya usamos de verdad):

Este programa enciende los LEDs cuando hay poca luz, pero nunca los apaga si
la luz vuelve. Añade la parte que falta para que se apaguen, y hazlo con un
tono más juguetón y cercano, que esto es para 1º de ESO.

Por qué esto es mejor que regenerar sin más: si solo hubiéramos pulsado “generar otra vez” sin decir qué faltaba, es muy probable que el segundo intento tuviera el mismo fallo, porque el problema real (falta la rama “si no”) no cambia solo por repetir la pregunta. Decir la pieza exacta que falta es lo que arregla el fallo a la primera.

---

Ejercicio 4 — El eclipse, primera vuelta

Qué van a aprender: a leer una tabla de datos propios sin dar por buena la primera interpretación que da la IA.

Paso a paso:

1. Con los datos ya capturados en agosto (hora, nivel de luz, si se pudo ver el Sol), montar una tabla sencilla de 5-6 filas.
2. Pedir un resumen “para mi edad” de lo que pasó.
3. Comprobar una cosa muy concreta: ¿dice Claude que fue un eclipse total o parcial? Si se equivoca (o si nosotros no se lo dijimos bien), hay que corregirlo.

Prompt de ejemplo:

Aquí tienen mis datos de luz ambiental del eclipse solar del 12 de agosto de
2026 en Estepona, medidos cada 15 minutos. Fue un eclipse PARCIAL, con el
94,5% del Sol cubierto, no total. Explícame qué pasó esa tarde, para alguien
de mi edad.

Por qué conviene decir “fue parcial” en el propio prompt: si no lo decimos, Claude puede asumir que fue total (que es lo más llamativo y lo que sale en las noticias) y montar la explicación sobre un dato equivocado. Dar el dato correcto por escrito, en vez de esperar que lo adivine, es la forma más simple de evitar ese error antes de que ocurra.

---

1º Bachillerato — Creación Digital y Pensamiento Computacional / TIC

Ejercicio 1 — El formato como pista, no como decoración

Qué van a aprender: a predecir qué tipo de información van a encontrar solo mirando cómo está formateada la respuesta, antes de leer el contenido.

Paso a paso:

1. Pedir una respuesta larga sobre IA (por ejemplo, diferencias entre IA generativa y de clasificación).
2. Sin leer el contenido todavía, mirar solo la estructura: ¿hay viñetas? ¿tabla? ¿pasos numerados? ¿negritas?
3. Anotar qué esperan encontrar en cada bloque según el formato (viñetas = opciones, tabla = comparación…).
4. Leer de verdad y comprobar si la predicción encajaba.

Prompt de ejemplo:

Explícame la diferencia entre la IA generativa y la IA de clasificación,
usando al menos una tabla comparativa y una lista de ejemplos de cada tipo.

Por qué merece la pena pedir el formato explícitamente: si no se pide, Claude decide el formato por su cuenta, y puede salir todo en párrafo seguido, más difícil de escanear rápido. Pedir “con una tabla” o “en pasos numerados” cuando se sabe qué tipo de información se necesita ahorra una vuelta entera de regenerar solo por presentación.

---

Ejercicio 2 — Cifras sospechosamente redondas

Qué van a aprender: a poner en duda un dato numérico concreto que suena “demasiado limpio” para ser real, y a verificarlo.

Paso a paso:

1. Pedir una cifra concreta sobre algún modelo de IA (parámetros, cantidad de datos de entrenamiento).
2. Fijarse si el número es sospechosamente redondo (500 millones, 1000 millones…).
3. Buscar esa cifra en una fuente externa (una web oficial, un artículo) y comparar.

Prompt de ejemplo:

¿Cuántos parámetros tiene aproximadamente un modelo de lenguaje grande
actual? Dame una cifra concreta si la tienes, y dime también qué tan seguro
estás de ese número.

Por qué pedir “qué tan seguro estás” cambia la respuesta: obliga a Claude a distinguir entre un dato verificado y una estimación general del sector, en vez de dar un número suelto sin más contexto — que es justo el tipo de “cifra convenientemente redonda” que el capítulo pide vigilar.

---

Ejercicio 3 — Regenerar para comparar, no para repetir

Qué van a aprender: que regenerar varias veces con un enfoque distinto cada vez, y quedarse con lo mejor de cada versión, da mejor resultado que aceptar la primera respuesta o repetir la misma pregunta esperando algo distinto.

Paso a paso:

1. Elegir un concepto técnico de ESP32 (por ejemplo, cómo funciona una petición HTTP a un servidor).
2. Pedir tres versiones, cada una con un enfoque distinto: una con analogía, otra centrada en el código, otra paso a paso.
3. Pedir a Claude que combine lo mejor de las tres en una versión final.

Prompts de ejemplo:

Versión 1: Explícame cómo funciona una petición HTTP desde un ESP32 usando
una analogía de la vida real.

Versión 2: Explícame lo mismo pero centrándote solo en el código necesario.

Versión 3: Explícame lo mismo, pero paso a paso, sin código todavía.

Petición final: Combina la analogía de la versión 1, con el código de la
versión 2, en una sola explicación paso a paso como en la versión 3.

Por qué combinar es mejor que elegir una sola versión: cada regeneración suele ser buena en un aspecto y floja en otro (una analogía clara pero sin código real, o código correcto pero sin ninguna intuición detrás). Pedir la fusión explícita, en vez de conformarse con la que “suena mejor” a primera vista, es la diferencia entre una buena explicación y una completa.

---

Ejercicio 4 — El eclipse en una conversación de varios turnos

Qué van a aprender: a corregir a Claude cuando entiende algo mal, y a usar el contexto de una conversación larga sin tener que repetir todo desde cero.

Paso a paso:

1. Primer turno — pedir un análisis inicial de los datos reales del eclipse (hora de inicio, máximo, fin, magnitud).
2. Segundo turno — decirle a propósito un dato incorrecto (por ejemplo, “en realidad fue un eclipse total”) y comprobar si Claude lo acepta sin más o si nota la inconsistencia con los datos que ya le diste antes.
3. Tercer turno — pedir que compare este eclipse parcial con el eclipse total de Wyoming 2017 que ya analizamos en un vídeo anterior, y que explique por qué en Wyoming la bajada de temperatura fue clara y aquí va a ser mucho más difícil de detectar.

Prompts de ejemplo:

Turno 1: Aquí tienes mis datos del eclipse del 12 de agosto de 2026 en
Estepona: hora, nivel de luz, temperatura. Dame un primer análisis.

Turno 2: En realidad fue un eclipse total, no parcial, ¿puedes ajustar el
análisis?

Turno 3: Compara este eclipse parcial con el eclipse total de Wyoming 2017
que ya analizamos. ¿Por qué allí la bajada de temperatura fue tan clara y
aquí puede que no se note casi nada?

Por qué el turno 2 es la parte más importante del ejercicio: si Claude corrige el análisis sin cuestionar el dato falso, hay que señalarlo: los propios datos numéricos que dimos en el turno 1 (94,5% de magnitud) no cuadran con un eclipse total. Detectar que la IA no siempre contrasta lo que le dices con lo que ya sabe es la lección real de este ejercicio, más incluso que el resultado científico final.

---

2º Bachillerato — Programación y Computación

Ejercicio 1 — Leer instrucciones técnicas completas antes de tocar nada

Qué van a aprender: que con hardware real (CanSat, AstroPi) no hay margen para “probar y ver qué pasa” — hay que leer todo el procedimiento antes de ejecutar una sola línea.

Paso a paso:

1. Pedir un script de Python para leer un sensor de presión o temperatura de una CanSat.
2. Antes de ejecutarlo, hacer la lista que pide el capítulo: requisitos previos, variaciones según la placa, manejo de errores.
3. Solo después de tener esa lista completa, ejecutar.

Prompt de ejemplo:

Necesito un script en Python para leer un sensor BMP280 de presión y
temperatura en una CanSat con Raspberry Pi Pico. Antes del código, dime:
qué librerías necesito instalar, qué conexiones físicas requiere, y qué
puede fallar si el sensor no responde.

Por qué pedir esto antes del código, y no después: con una CanSat lanzada de verdad no hay una “segunda ejecución” en pleno vuelo. Pedir los requisitos y los posibles fallos antes de tener el código en pantalla obliga a leerlos con atención, en vez de saltar directamente al código y descubrir el problema demasiado tarde.

---

Ejercicio 2 — Cuando la IA salta de la pregunta a la respuesta sin mostrar el camino

Qué van a aprender: a exigir el razonamiento completo, no solo la conclusión, sobre todo cuando el tema es la propia IA.

Paso a paso:

1. Preguntar por qué un modelo de lenguaje puede “alucinar” (inventar información con total seguridad).
2. Pedir la respuesta una vez sin más, y otra vez exigiendo el razonamiento paso a paso.
3. Comparar: ¿la segunda versión revela algún salto lógico que la primera escondía?

Prompts de ejemplo:

Prompt 1: ¿Por qué los modelos de lenguaje alucinan?

Prompt 2: ¿Por qué los modelos de lenguaje alucinan? Explícame el
razonamiento paso a paso, sin saltar directamente a la conclusión.

Por qué exigir el razonamiento cambia la calidad de la respuesta: un modelo que predice el siguiente token más probable no tiene, por diseño, un mecanismo interno que distinga “sé esto con certeza” de “esto suena plausible” — pedir el razonamiento paso a paso obliga a que esa distinción, si existe, aparezca explícita en la respuesta, en vez de quedar oculta detrás de una conclusión que suena igual de segura en ambos casos.

---

Ejercicio 3 — Depurar de verdad: Claude contra Claude Code

Qué van a aprender: a elegir la herramienta según lo que hace falta en ese momento — entender el fallo, o tener ya el código corregido.

Paso a paso:

1. Escribir (o dejar que se escriba con un fallo real) un script de lectura de sensores para AstroPi o ESP32.
2. Pasar el mismo prompt de depuración a Claude normal y a Claude Code.
3. Comparar: ¿cuál explica mejor el fallo? ¿cuál da el script completo ya corregido?

Prompt de ejemplo (el mismo esquema que ya usamos con el LDR):

Aquí tienes mi script de Python para leer un sensor en la AstroPi, pero los
valores que devuelve no tienen sentido. Revisa línea a línea y dime dónde
está el error.

Por qué probar en las dos herramientas, y no conformarse con la primera: ya lo vimos con el sensor de luz: Claude en el chat normal explica bien el fallo pero no siempre reescribe el script entero; Claude Code hace el repaso completo y entrega el código ya corregido. Para que el alumnado entienda el error, la primera respuesta puede ser suficiente — para que el profesor tenga rápido el material corregido para la clase, la segunda ahorra un paso.

---

Ejercicio 4 — El eclipse, análisis completo y con red flags activas

Qué van a aprender: a aplicar el marco de cuatro pasos completo (objetivo, calidad de datos, método, interpretación con cautela) exigiendo en cada respuesta que se señalen los propios red flags del capítulo 8.

Paso a paso:

1. Con los datos reales del 12 de agosto, definir el objetivo del análisis (¿qué relación buscamos entre luz y temperatura, si la hay, en un evento tan corto y con el Sol ya bajo?).
2. Pedir el análisis completo, exigiendo que Claude señale explícitamente cualquier cifra con una correlación sospechosamente limpia o cualquier generalización que los datos no sostengan.
3. Comparar la magnitud del efecto (si lo hay) con el eclipse de Wyoming, y decidir juntos si se puede afirmar algo con solo una tarde de datos.

Prompt de ejemplo:

Aquí tienes mis datos completos del eclipse del 12 de agosto de 2026 en
Estepona (hora, luz ambiental, temperatura, cada 15 minutos desde las 19:30
hasta las 21:30). Analiza la relación entre oscurecimiento y temperatura
siguiendo el marco de definir objetivo, revisar calidad, elegir método e
interpretar con cautela. Señala explícitamente si alguna cifra que me das
parece sospechosamente exacta, o si alguna conclusión generaliza más de lo
que estos datos concretos permiten afirmar.

Por qué pedir explícitamente los red flags dentro del propio prompt: con el eclipse de Wyoming ya vimos que la caída de temperatura fue clara porque duró horas y era un eclipse total; aquí, con el Sol ya poniéndose de forma natural en menos de dos horas, cualquier bajada de temperatura que aparezca en los datos puede deberse simplemente a que anochece, no al eclipse. Pedirle a Claude que marque sus propias afirmaciones dudosas, en vez de esperar a que el alumnado las detecte solo, convierte el ejercicio en una lección explícita sobre los límites de la propia herramienta, no solo sobre el eclipse.

---

Nota final para mí mismo

El hilo que conecta las tres etapas no es la dificultad creciente del código — eso ya lo sabía. Es que en las tres, el ejercicio de fondo es el mismo: enseñar a desconfiar con método, no por sistema. Ni el rechazo automático (que ya vimos con los timos de los libros de “Claude AI Bible”) ni la fe ciega en la respuesta bien escrita. El punto intermedio, que es incómodo de enseñar porque no tiene un eslogan bonito, es exactamente lo que este capítulo pone en palabras.