Distingue un fallo de una decisión pendiente
Un fallo tiene un resultado esperado suficientemente claro para comprobarlo. Una decisión pendiente deja varias respuestas posibles y cada corrección puede seguir una de ellas. Si el equipo cambia repetidamente la definición del comportamiento correcto, conviene suspender la implementación de esa parte y resolver primero la elección que sigue abierta.
Llegué a abandonar una versión de una aplicación después de que la idea cambiara demasiado durante la construcción. El proyecto acumuló instrucciones contradictorias y la IA volvía a encontrar decisiones antiguas en los archivos. Empezar de nuevo con lo que había comprendido entretanto fue la elección que hice en aquel caso concreto.
Esa experiencia no convierte borrar trabajo en una regla de desarrollo. Muestra el coste de seguir construyendo sobre decisiones que ya no corresponden a lo que se pretende. Hoy, ante una secuencia de correcciones, busco entender si resolvemos defectos identificables o cambiamos continuamente la propia definición del producto.
Imagina un prototipo para reservar salas de ensayo. Al principio, una reserva ocupa una sala durante una hora; después pasa a depender de equipos compartidos y de la presencia de un técnico. Si se añaden esas condiciones sin revisar la regla de disponibilidad, el calendario puede acumular excepciones difíciles de explicar.
Cuando corriges una reserva y estropeas otra, pregunta qué tienen ambas en común. Puede existir un defecto localizado, pero también faltar una decisión sobre qué se está reservando realmente. Esa respuesta orienta el siguiente trabajo de forma mucho más útil que pedir otra corrección genérica.
Para preparar el siguiente paso, consulta Desarrollar aplicaciones con IA.
Busca contradicciones en las reglas y los documentos
Las señales más útiles aparecen cuando diferentes partes del proyecto defienden comportamientos incompatibles. Compara los requisitos, los ejemplos y lo que hace la aplicación. Si la misma situación recibe respuestas distintas según el documento consultado, define cuál es la decisión válida antes de pedir a la IA que siga desarrollando.
En el prototipo de las salas, una instrucción puede decir que el cliente elige libremente el horario, mientras otra exige confirmación manual del técnico. Ambas pueden tener sentido en productos diferentes. Mantenerlas sin explicar su relación obliga a la aplicación a intentar cumplir dos promesas que el equipo todavía no ha conciliado.
Reúne las decisiones relevantes en un registro breve: qué está aceptado, qué se sustituyó y qué permanece abierto. Una decisión antigua puede seguir documentada como historial, siempre que deje de parecer una instrucción actual. Lo importante es que quien trabaje pueda reconocer la regla vigente.
También conviene distinguir el comportamiento deseado de la solución técnica elegida para obtenerlo. Quizá necesites impedir reservas incompatibles, pero eso no determina automáticamente cómo organizar el calendario. Separar ambas cosas permite revisar la implementación sin volver a discutir la necesidad que la motivó.
El ejercicio de planificar una aplicación antes de programar sigue siendo útil en esta fase, con una ventaja: ya tienes ejemplos concretos de lo que falló. Utilízalos para mejorar las preguntas del plan, en lugar de escribir una descripción más extensa que mantenga exactamente las mismas ambigüedades de la versión anterior.
Compara opciones sobre la parte afectada
Antes de decidir empezar de nuevo, compara el alcance de una corrección, una reformulación parcial y una versión nueva. Para cada opción, identifica qué puede conservarse y qué necesita validarse otra vez. La elección debe apoyarse en la causa del problema y en las dependencias que realmente existen.
Si el calendario muestra la hora equivocada por una transformación incorrecta, puede bastar una corrección localizada. Si el concepto de disponibilidad pasó de sala a sala, equipos y técnico en conjunto, quizá sea necesario revisar esa parte más profundamente. El tamaño visible del error no determina el tamaño de la solución.
Pide que el análisis explique qué datos, recorridos y reglas dependen de la parte que cambiará. Una pantalla sencilla puede alimentar confirmación, cancelación y gestión interna. Reconstruirla sin considerar esas relaciones puede dejar el mismo problema repartido por otros puntos, con una apariencia nueva pero una lógica todavía incompleta.
Cuenta el esfuerzo futuro de verificar cada opción, además del trabajo de construir. Lo que ya gastaste ayuda a comprender el recorrido, pero no demuestra que continuar por él sea la mejor decisión. Tampoco vuelve automáticamente ventajosa la reconstrucción: perder comportamientos correctos puede crear una nueva lista de problemas.
Preserva el aprendizaje antes de cambiar de dirección
Un prototipo puede dejar de ser la base adecuada y seguir conteniendo aprendizaje valioso. Guarda los recorridos demostrados, los ejemplos que revelaron fallos y las decisiones aclaradas entretanto. Conserva una versión recuperable antes de reformular, para poder consultar y comparar el comportamiento que ya estaba funcionando.
En el caso de las salas, quizá el formulario de contacto sea adecuado y los mensajes comprensibles, aunque la disponibilidad necesite otra estructura. No hay razón para tratar todas las partes como igualmente fallidas. Identifica qué puede reutilizarse y confirma su compatibilidad con las reglas revisadas.
Las pruebas que descubrieron las contradicciones también deben acompañar el cambio. Una reserva que necesita el mismo equipo en otra sala pasa a ser un caso concreto de validación. Si ese ejemplo queda solo en la conversación que motivó la reformulación, puedes terminar una versión nueva sin confirmar que resolvió la dificultad original.
Al preparar una sesión de trabajo con Claude Code, esta información merece más atención que una larga lista de intentos. Entrega el estado aceptado, las reglas revisadas y los casos que hay que demostrar. La historia ayuda cuando explica una decisión, pero no debe ocultar la petición actual.
Retoma con una hipótesis que puedas confirmar
La construcción debe retomarse cuando existe una explicación del fallo y un resultado que permita evaluar el cambio propuesto. Elige un recorrido representativo e implementa lo necesario para demostrarlo. Solo después amplía la solución, manteniendo visibles las decisiones que todavía no se han tomado para los demás casos.
Para las reservas, puedes empezar por una solicitud que incluya sala, equipos y técnico, con el intento de solapamiento que antes fallaba. El objetivo es confirmar que la nueva definición de disponibilidad produce la respuesta esperada. Una presentación más bonita del calendario no responde por sí sola a esa pregunta.
Registra también quién decide cuando aparece una excepción nueva. Volver a discutir la misma regla con cada solicitud tiene un coste similar al de tomar repetidamente la misma decisión en la empresa. Hacer explícita la elección permite concentrar la atención en situaciones que aportan información realmente nueva al proyecto.
Si la hipótesis falla, utiliza el resultado para revisar la explicación, sin añadir de inmediato otra excepción a la implementación. Detenerse a tiempo mantiene disponible el aprendizaje y limita el trabajo dependiente de una decisión frágil. El avance que interesa es poder justificar el comportamiento de la siguiente versión y demostrarlo en los casos relevantes.