Construir y corregir

El bucle construir-probar-corregir

Has enviado tu mini-PRD, la IA ha generado la base de tu app. Empieza ahora la fase más larga — y la más formativa — del proyecto: la construcción iterativa. El ritmo es siempre el mismo: pides una cosa, la IA la hace, pruebas de inmediato, y según el resultado validas o corriges. Luego vuelves a empezar con la cosa siguiente.

Este ritmo puede parecer lento comparado con la tentación de pedirlo todo de golpe. En realidad es mucho más rápido a la larga, por una razón simple: cuando aparece un bug, sabes exactamente qué petición lo introdujo — la última. Sin esta disciplina, un bug puede venir de cualquiera de tus cinco últimas peticiones, y pasarás más tiempo buscando al culpable que corrigiéndolo.

flowchart LR
  D["Pide UNA cosa"] --> G["La IA genera"]
  G --> T["Prueba de inmediato"]
  T -->|"Funciona"| V["Valida y pasa a lo siguiente"]
  T -->|"Se rompe"| E["Copia el error exacto"]
  E --> C["Pide la corrección"]
  C --> T
  V --> D

Probar cada etapa: tu checklist

Después de cada generación, abre la app y prueba realmente la funcionalidad. No te limites a mirar la pantalla: usa la app como lo haría un usuario. Para la función «añadir un hábito» de Tom, eso significa: teclear un nombre, hacer clic en el botón, verificar que el hábito aparece, añadir un segundo, y luego recargar la página para verificar que todo sigue ahí.

Acostúmbrate también a probar los casos límite — ahí es donde se esconden los bugs: ¿qué pasa si añades un hábito con el nombre vacío? ¿Si añades veinte? ¿Si haces clic dos veces muy rápido? No necesitas ser exhaustivo, pero dos o tres intentos «fuera del carril» por funcionalidad revelan las fragilidades antes que tus usuarios.

• Probar el caso normal: ¿la acción principal funciona?
• Recargar la página: ¿los datos siguen ahí?
• Probar un caso límite: campo vacío, valor raro, doble clic.
• Verificar en el móvil (o encogiendo la ventana) si tu app es mobile-first.

La consola del navegador: tu mejor aliada

Cuando algo se rompe sin explicación visible, la respuesta se encuentra casi siempre en la consola del navegador. Pulsa F12 (o clic derecho → «Inspeccionar»), y luego abre la pestaña «Console». Ahí es donde el navegador escribe los errores: líneas rojas, a menudo en inglés, que indican qué falló y dónde.

No necesitas entender esos mensajes — solo necesitas copiarlos. Así es como se ve un error típico:

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
    at app.js:24:18

Traducción libre: «en la línea 24 del archivo app.js, el código intenta usar algo que no existe». Es exactamente el tipo de pista que la IA necesita para corregir en un mensaje en lugar de cinco. Errores frecuentes que encontrarás: TypeError (el código manipula un valor del tipo equivocado), ReferenceError (usa un nombre que no existe), SyntaxError (el propio código está mal formado), y 404 Not Found (un archivo no se encuentra).

El prompt de depuración perfecto

Cuando algo se rompe, no digas «no funciona». La IA no tiene forma de adivinar lo que ves en pantalla. Un buen informe de bug contiene cuatro elementos: lo que estabas haciendo, lo que esperabas, lo que pasó en su lugar, y el mensaje de error exacto de la consola. Con estas cuatro informaciones, el diagnóstico es casi siempre inmediato.

Bug a corregir.
Lo que estaba haciendo: hago clic en «añadir un hábito» después de teclear «Lectura» en el campo.
Lo que esperaba: el hábito aparece en la lista.
Lo que pasa: no se muestra nada, el campo se vacía.
Error en la consola: Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at app.js:24:18
Diagnostica la causa y corrige, explicándome de forma simple qué estaba mal.

Fíjate en la última frase: «explicándome de forma simple qué estaba mal». Es ella la que transforma cada bug en lección. Al cabo de diez correcciones, reconocerás tú mismo los errores corrientes — y escribirás peticiones que los eviten de entrada.

Cuando la IA da vueltas en círculo

Ocurre: señalas un bug, la IA «corrige», el bug sigue ahí, «corrige» de nuevo, y nada cambia — o peor, otra cosa se rompe. Al cabo de dos o tres intentos infructuosos, deja de insistir por la misma vía. Tres estrategias eficaces: pide a la IA partir de cero en esa funcionalidad («elimina todo el código del calendario y rehazlo más simple»), pídele añadir mensajes de diagnóstico («añade console.log para que veamos dónde se bloquea»), o reformula completamente tu petición inicial, que quizá era ambigua.

Ten también en mente la opción nuclear: volver a la última versión que funcionaba y retomar desde ahí. Para eso sirve exactamente Git, del que hablamos ahora mismo — una red de seguridad que hace las experimentaciones sin riesgo.

Guardar con Git: tu red de seguridad

Git es la herramienta que todos los desarrolladores usan para guardar el historial de un proyecto. La idea cabe en una imagen: en cada etapa que funciona, tomas una «foto» (un commit) de tu proyecto. Si una experimentación sale mal, vuelves a la última foto en un instante. Ya no hace falta tener miedo de romper: todo es reversible.

Si estás en una herramienta de navegador (Lovable, v0, Bolt), buena noticia: la mayoría gestionan el historial de versiones por ti — busca un menú «History» o «Versions» y localiza cómo restaurar un estado anterior. Si estás en Cursor o Claude Code, pide simplemente a la IA que haga los commits por ti, o aprende los tres comandos esenciales:

# En cada etapa que funciona, toma una foto del proyecto:
git add .
git commit -m "Añadir hábito funciona"

# Para ver el historial de tus fotos:
git log --oneline

El buen ritmo: un commit después de cada funcionalidad probada y validada. El mensaje del commit describe lo que funciona («marcado diario OK», «calendario mostrado»). Tom adopta este hábito desde la primera noche — y el día en que una experimentación de diseño rompe toda su maquetación, vuelve atrás en treinta segundos en lugar de reconstruirlo todo.

Avanzar con pequeños pasos seguros

Una funcionalidad probada y que funciona = un punto de apoyo sólido. Construyes sobre lo estable, no sobre arena. Eso es lo que evita el efecto «todo está roto y no sé por qué» que desanima a tantos principiantes. La secuencia completa de Tom para cada funcionalidad: pedir → probar → corregir si hace falta → hacer commit → pasar a la siguiente.

Este método tiene un efecto secundario valioso: la confianza. Cada pequeño paso validado es una victoria concreta, y la motivación se alimenta de victorias. Al final del capítulo, la app de Tom hace todo lo que preveía su v1 — añadir, eliminar, marcado diario, racha — y cada ladrillo ha sido verificado. Está listo para la puesta en línea.