Distinguish a failure from an unresolved decision
A failure has an expected result that is clear enough to check. An unresolved decision leaves several possible answers, and each correction may follow a different one. If the team repeatedly changes its definition of correct behaviour, pause implementation of that part and resolve the outstanding choice before moving forward.
I have abandoned a version of an application after the idea changed too much during construction. The project accumulated contradictory instructions, and the AI kept finding old decisions in the files. Starting again with the understanding I had gained was the choice I made in that particular situation at the time.
That experience does not turn deleting work into a development rule. It shows the cost of continuing to build on decisions that no longer match the intention. Today, when faced with a sequence of corrections, I look at whether we are fixing identifiable defects or continually changing the definition of the product.
Imagine a prototype for booking rehearsal rooms. Initially, a booking occupies one room for an hour; later, it depends on shared equipment and a technician being present. If those conditions are added without revisiting the availability rule, the calendar may accumulate exceptions that become increasingly difficult to explain or verify.
When fixing one booking breaks another, ask what they have in common. There may be a local defect, but there may also be an unresolved decision about what is actually being booked. That answer guides the next piece of work far more usefully than asking for another generic correction.
To prepare your next step, explore Developing applications with AI.
Look for contradictions in rules and documents
The most useful signals appear when different parts of the project prescribe incompatible behaviours. Compare requirements, examples and what the application actually does. If the same situation receives different answers depending on the document consulted, establish the valid decision before asking the AI to continue developing the affected part further.
In the room prototype, one instruction might say that customers freely choose a time, while another requires manual confirmation from the technician. Both can make sense in different products. Keeping them without explaining their relationship forces the application to attempt two promises that the team has not yet reconciled.
Bring the relevant decisions together in a short record: what is accepted, what was replaced and what remains open. An old decision can remain documented as history as long as it stops looking like a current instruction. Anyone working on the project needs to recognise the rule that now applies.
It also helps to distinguish intended behaviour from the technical solution chosen to deliver it. You may need to prevent incompatible bookings, but that does not automatically determine how to organise the calendar. Separating the two allows you to revisit implementation without reopening the discussion about the need behind it.
The exercise of planning an application before coding remains useful at this stage, with an advantage: you already have concrete examples of what failed. Use them to improve the questions in the plan instead of writing a longer description that preserves exactly the same ambiguities as the previous version.
Compare options for the affected part
Before deciding to start again, compare the scope of a correction, a partial redesign and a new version. For each option, identify what can be preserved and what needs validating again. Base the choice on the cause of the problem and the dependencies that actually exist in the current application.
If the calendar displays the wrong time because of an incorrect transformation, a local fix may suffice. If availability has changed from a room alone to a combination of room, equipment and technician, that part may need deeper revision. The visible size of the error does not determine the solution's scope.
Ask the analysis to explain which data, journeys and rules depend on the part being changed. A simple screen may feed confirmation, cancellation and internal management. Rebuilding it without considering those connections can leave the same problem scattered elsewhere, with a new appearance but with logic that remains incomplete.
Count the future effort of verifying each option alongside the work of building it. What you have already spent helps explain the journey but does not prove that continuing is the best decision. Nor does it make reconstruction automatically worthwhile: losing correct behaviours can create a new list of problems.
Preserve what you learned before changing direction
A prototype can stop being a suitable foundation while still containing valuable learning. Keep demonstrated journeys, examples that exposed failures and decisions clarified along the way. Preserve a recoverable version before a redesign so you can consult and compare the behaviour that was already working in the application before the change.
In the room example, the contact form may be suitable and the messages understandable even though availability needs a different structure. There is no reason to treat every part as equally unsuccessful. Identify what can be reused and confirm that it remains compatible with the revised rules and expected behaviour.
The tests that uncovered contradictions should accompany the change as well. A booking that needs equipment already allocated to another room becomes a concrete validation case. If that example remains only in the conversation that prompted the redesign, you may finish a new version without checking whether it resolved the original difficulty.
When preparing a working session with Claude Code, this information deserves more attention than a long list of attempts. Provide the accepted state, revised rules and cases to demonstrate. History helps when it explains a decision, but it should not obscure the current request or the outcome being pursued.
Resume with a hypothesis you can check
Construction should resume when there is an explanation for the failure and an outcome that allows the proposed change to be evaluated. Choose a representative journey and implement what is needed to demonstrate it. Then expand the solution, keeping decisions that remain unresolved for other cases visible throughout the work.
For bookings, you could begin with a request involving a room, equipment and a technician, including the attempted overlap that previously failed. The objective is to confirm that the new definition of availability produces the expected response. A more attractive calendar does not, by itself, answer that particular question.
Also record who decides when a new exception appears. Reopening the same rule for every request has a cost similar to making the same decision repeatedly in a business. Making the choice explicit lets attention focus on situations that bring previously unknown information to the project and its requirements.
If the hypothesis fails, use the result to revisit the explanation without immediately adding another exception to the implementation. Stopping in time preserves learning and limits work dependent on a fragile decision. Useful progress means being able to justify the next version's behaviour and demonstrate it through the relevant cases.