# Iterar por prompts sin perder el control del proyecto > Iterar con IA es pedir cambios pequeños, verificar cada paso y limpiar el contexto a tiempo. Cómo dar criterios de verificación y corregir pronto. *Tags: ia, prompts, iteracion, ux-para-ia* --- > [!info] Definición Rápida > **Iterar por prompts** es construir algo con una IA en pasos pequeños: pedir un cambio, comprobarlo, corregir si hace falta y seguir. Mantiene el control porque cada paso se puede revisar y, si algo sale mal, se puede volver atrás. ## ¿Por qué pedir todo de una vez sale mal? Un prompt largo con diez requisitos produce un resultado que es difícil de revisar. Si algo falla, no sabes qué parte lo causó. Y si lo corriges pidiendo otra cosa encima, la IA trabaja con un contexto más confuso. Las guías de Claude Code lo resumen así: la ventana de contexto es el recurso más importante, y el rendimiento se degrada conforme se llena. Una sesión con mucha información irrelevante puede hacer que la IA olvide instrucciones anteriores o cometa más errores ([Anthropic, Claude Code best practices](https://code.claude.com/docs/en/best-practices)). Por eso, la regla práctica es pedir un cambio a la vez y comprobarlo antes del siguiente. Si todavía no tienes claro qué es este estilo de trabajo, empieza por [[que-es-vibe-coding|qué es vibe coding]]. ## Cómo dar una forma de verificar La guía de Anthropic advierte que, sin criterios claros de éxito, la IA puede entregar algo que parece correcto pero no funciona. Sin una forma de comprobarlo, esa impresión es la única señal, y la persona se convierte en el único ciclo de verificación. La solución es darle un criterio que devuelva aprobado o no aprobado: pruebas, una compilación, un linter o una captura para comparar con el diseño. Para una interfaz, el criterio puede ser la lista de estados que deben existir (con datos, vacío, cargando, con error) o una captura comparada con el diseño. Para un texto, puede ser una lista de reglas de tono que se revisan una por una. Compara tres formas de pedir lo mismo: | Prompt débil | Prompt con verificación | |---|---| | "Escribe una función que valide correos" | "Escribe `validateEmail`. Casos: `user@example.com` es válido, `usuario` no lo es, `user@.com` no lo es. Ejecuta las pruebas al terminar" | | "Mejora el dashboard" | "Esta es la captura del diseño. Implementa, toma una captura del resultado, compara y lista las diferencias" | | "El build falla" | "El build falla con este error: [pegar]. Corrígelo y verifica que el build pase; no ocultes el error" | ## Explorar, planear, luego escribir código Otra práctica de la misma guía: separar la exploración de la implementación. Pedirle a la IA que lea el código, entienda cómo funciona y proponga un plan antes de tocar archivos evita resolver el problema equivocado. El plan puede editarse antes de que la IA lo ejecute, y herramientas como Claude Code tienen un [[modo-plan|modo plan]] pensado para esto. Esa separación es parte del flujo que describe [[spec-driven-development|spec-driven development]]. No siempre hace falta. Si el cambio cabe en una frase y afecta un archivo, pedirlo directo es más rápido. El plan vale la pena cuando no conoces el código o el cambio toca varios archivos. ## Corregir pronto y limpiar a tiempo Osmani recomienda avanzar en pasos pequeños: "Small, incremental testing prevents nightmare debugging sessions", y tratar el código generado como el de un desarrollador junior que necesita revisión antes de entrar ([Osmani, Beyond Vibe Coding](https://beyond.addy.ie/)). Tres reglas de corrección: 1. **Corrige en cuanto notes el desvío.** Detener a la IA a mitad de un cambio ahorra más tiempo que esperar al final. 2. **Si corriges más de dos veces lo mismo, limpia.** La sesión se llena de intentos fallidos. Un contexto limpio con un prompt mejor suele ganar. 3. **Separa las tareas.** Una sesión por tarea. Lo que no tiene relación con la tarea actual sólo estorba. Los puntos de restauración también ayudan. Muchas herramientas guardan el estado antes de cada cambio, de modo que puedes volver a un punto anterior. Ojo: esos puntos no reemplazan a Git, porque no capturan cambios hechos desde la terminal. ## Ejemplo Ejemplo ilustrativo: un diseñador quiere una página de preguntas frecuentes con búsqueda. En lugar de pedir todo, hace cuatro pasos: primero la lista con datos de prueba, luego el buscador, después el estado vacío, y al final la versión móvil. Tras cada paso mira la pantalla y revisa la consola. En el buscador, la IA cambió el nombre de un componente que usa otra página; el diseñador lo ve en la prueba de la página anterior y pide corregirlo antes de seguir. Cuatro pasos pequeños costaron menos que un solo prompt que falló en todo. El mismo método aplica a [[de-idea-a-app-en-un-dia|el flujo de idea a app]] y a la forma de depurar, que se ve en [[debugging-con-ia|debugging con IA]]. ## Cómo aplicarlo mañana 1. Elige una tarea de tu semana y divídela en cuatro pasos que se puedan revisar por separado: datos, estructura, comportamiento y acabado. 2. Escribe antes de cada paso el criterio con el que lo vas a aceptar, en una frase. 3. Si el paso falla dos veces, cambia la descripción, no la insistencia: limpia la sesión y reescribe el prompt con lo que aprendiste. 4. Al final del día, anota cuántos prompts necesitaste. Esa cifra te dirá si tus descripciones iniciales mejoraron con la práctica. ## Errores comunes - Pedir diez cambios en un solo prompt. - Corregir la misma cosa cinco veces en la misma sesión. - Aceptar cambios que "se ven bien" sin probarlos. - Mantener una sesión con tareas que no tienen nada que ver. - Pedir una explicación que no se verifica, o confiar en una frase que suena segura. - Creer que el historial de la IA reemplaza a Git. ## Fuentes - Anthropic, "Best practices for Claude Code": [https://code.claude.com/docs/en/best-practices](https://code.claude.com/docs/en/best-practices) - Addy Osmani, "Beyond Vibe Coding": [https://beyond.addy.ie/](https://beyond.addy.ie/) - GitHub Blog, "Spec-driven development with AI: Get started with a new open source toolkit": [https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) --- Source: https://www.fernandoux.com/es/wiki/ia/iterar-por-prompts/