Vibe coding
Repair or rebuild an AI prototype? Inspect the failure first
Choose a focused repair or a new direction by separating unclear requirements, isolated defects and structural mismatch.
Zocri · 2 min read · Sources checked
Identify the kind of failure
Lovable documents code export and GitHub synchronization as ways to keep and collaborate on a project's source. Whatever builder you use, preserve a recoverable reference before deciding to abandon useful work. Then describe the problem precisely. An app that loses one field after saving presents a different decision from an app built around the wrong customer and owner workflow.
Separate three possibilities: the requirement is unclear, the implementation has a defect or the underlying model does not fit the job. A repeated conversation about whether requests are bookings is a requirements problem. Rebuilding without resolving that question may reproduce the same confusion.
Look for a reliable core
Try the smallest end-to-end journey and note what works. Can a customer create a record, can the owner act on it and can the customer return to see the result? If this core works, a focused correction may preserve more value than replacing every screen.
List the pieces worth keeping: approved content, a useful data model, verified connections or a layout the owner understands. Also list dependencies that remain uncertain. Do not infer that a beautiful interface has a reliable core, or that a plain interface must be technically unsound.
Compare two bounded proposals
Ask for a repair proposal and a replacement proposal addressing the same failed outcome. Each should name the affected data, existing users, external setup and verification work. Request reasons for major changes, particularly when a proposed repair changes unrelated parts of the app.
Choose a small proof before committing to either direction. For a repair, verify the failing case and a nearby working case. For a replacement, demonstrate the disputed workflow with sample data. This gives you evidence about the proposed approach without pretending to forecast the entire project's cost precisely.
Make the transition explicit
If you keep the existing app, record the clarified rule and the regression checks. If you replace it, plan how useful records, approved content and operating responsibilities move. A fresh project should not quietly become the new live system merely because its preview looks more promising.
Name a decision owner and a stopping condition for further iteration. For example, the new approach must demonstrate two distinct user roles and persistent requests before additional design work. The aim is to regain a reviewable path forward, grounded in the failure you actually need to resolve.