Programar no es escribir código que funciona a la primera, es arreglar código que no funciona. Esa habilidad se llama depurar y es la más subestimada cuando trabajas con inteligencia artificial, porque te obliga a leer, cuestionar y mejorar lo que la IA te entrega.

Si tu código falla, no estás haciendo algo mal: estás programando. Los errores no son un accidente del proceso, son el proceso. Lo que distingue a quien avanza de quien se traba es qué hace con esos errores.

¿Por qué el código que genera la IA casi siempre falla en los bordes?

La IA rara vez te entrega código que no funcione en absoluto. Casi siempre te entrega código que funciona para el caso obvio y se cae en los casos que nadie pensó.

En el ejemplo de la clase [01:30], le pedimos a Gemini una función para un sitio de café que reciba la cantidad de tazas a reservar, con la regla de no permitir más de dos por persona. La función se ve bien: es corta, legible y respeta la regla.

Al probarla en el navegador con un input HTML y un botón de reservar [03:10], pasa lo siguiente:

• Con 2 tazas: reserva confirmada. Correcto.
• Con 3 tazas: rechaza la reserva. Correcto.
• Sin escribir nada: reserva confirmada. Absurdo.
• Con la palabra Hola: reserva confirmada. Aún más absurdo.

La función hace bien una parte, pero deja pasar reservas vacías, en cero o con texto. Y aquí empieza el trabajo real.

¿Qué significa depurar en programación? Es el proceso de encontrar por qué tu código se comporta distinto a lo que esperabas. Tiene cuatro pasos: reproducir el error, aislar dónde ocurre, entender por qué pasa y corregirlo.

¿Cómo aislar un bug usando console.log como linterna?

Reproducir el error es fácil: basta con repetir la acción que lo dispara. Aislar significa encontrar la línea exacta donde el código se comporta raro, y para eso vamos a resignificar una herramienta que ya conoces: console.log.

Hasta ahora la usaste para mostrar cosas. A partir de hoy es un instrumento de diagnóstico, una linterna que metes adentro del código para ver qué pasa en cada momento.

En el ejemplo [05:40] agregamos dos console.log: uno antes de llamar a la función para ver qué le mandamos, y otro adentro para ver qué evalúa. Al probar con el campo vacío, la consola nos muestra el hallazgo clave: la función no recibe nada "raro" como undefined, recibe un string vacío ("").

Y un string vacío técnicamente no es mayor que dos. Entonces la condición es falsa, la función devuelve true y la reserva pasa. El mismo problema ocurre con "Hola": no es mayor que dos en ningún sentido razonable, así que pasa.

¿Qué tipo de dato llega desde un input HTML?

Todo lo que escribes en un input llega a JavaScript como texto, incluso si parece un número. Por eso "" y "Hola" son strings válidos para la condición original. Este detalle es la raíz del bug y solo lo descubres cuando inspeccionas el tipo de dato con typeof.

¿Cómo escribir un prompt para que la IA no olvide casos?

El paso tres es entender por qué ocurre. Y la respuesta no es solo técnica: la IA verificó únicamente el caso del límite superior porque eso fue lo único que pedimos. El prompt original decía "no se puede reservar más de dos tazas por persona" y nada más.

La IA no es adivina, hace exactamente lo que le pides. Esto conecta con algo visto en la clase de condiciones: el error más común no es escribir mal una condición, sino olvidar un caso. ¿Qué pasa si la cantidad es cero, negativa o no es un número? Olvidado, olvidado y olvidado.

¿Cómo le pido a la IA que arregle un bug? Dale contexto: explica de dónde viene el dato, qué tipo es, qué casos debe validar y qué comportamiento esperas en cada uno. Un prompt vago produce código vago.

En el paso cuatro [09:20] puedes corregir a mano o, mejor, volver a la IA con un prompt mejor. Algo así:

1. Esta función recibe su parámetro desde el value de un input HTML, así que llega como texto.
2. Valida que el campo no esté vacío.
3. Valida que lo recibido sea un número.
4. Valida que ese número sea mayor a cero y no mayor a dos.

No solo describes qué hace la función: describes el contexto donde vive y los casos que debe manejar. Esa lista no salió de la nada, salió de combinar la pregunta "¿qué podría pasar?" con dejar que el código te muestre dónde se rompe.

¿Cuál es la diferencia entre pedir ayuda con un bug y pedirla bien?

Cuando le pidas ayuda a una IA con un error, la calidad de la respuesta depende del contexto que des. Decir "mi código no funciona" es como ir al médico y decir "me siento mal".

En cambio, decir algo como "esta función debería rechazar cantidades vacías o que no sean números, pero las está aceptando; cuando hago console.log de la cantidad, veo que el campo vacío llega como string vacío" es llegar con tus síntomas, tus análisis y tu hipótesis.

Para escribir esa segunda versión necesitas vocabulario: los nombres de las cosas como string, parámetro, condición, tipo de dato. Eso es justo lo que llevas construyendo en cada clase anterior.

Depurar código que tú no escribiste, encontrar el supuesto que la IA hizo y tú no validaste, y volver con una pregunta mejor: esa es una habilidad nueva del 2026 que antes no existía. Cuéntame en los comentarios qué bug raro te ha dejado pasar una IA últimamente.