You fix the checkout total. The discount stops working. You repair the discount, and an old customer can no longer open an invoice. After a few rounds, you are afraid to touch an app you built yourself.
This pattern does not automatically mean your vibe-coded project needs rebuilding. It means you need to understand what changed, which parts depend on it, and what evidence will show that the repair worked.
The problem is bigger than the latest error message
Imagine a booking app that uses the same price calculation for quotes, checkout, and invoices. An AI coding assistant changes that calculation to fix checkout. The page looks correct, but invoices still expect the old result. This is a hypothetical example of a regression: a change breaks something that previously worked.
The cause could be shared code, a changed data format, an updated dependency, or a setting that differs between your test app and the live version. The error message is a clue. It is not the full diagnosis.
Asking an assistant to fix the newest symptom can make progress harder if each attempt also changes unrelated files. The useful question becomes: which change first caused the failure, and what else relies on it?
Give the investigation a stable starting point
Pause unrelated changes to the affected part of the app. Preserve the current code version, error records, and an appropriate backup before an engineer starts repairing it. Keep customer information out of public screenshots and support posts.
Then write a short reproduction note:
- What were you trying to do, and with which type of account?
- What exact steps produce the problem?
- What did you expect, and what happened instead?
- When did it last work, and what changed afterwards?
“Invoices fail after applying a discount to an existing booking” gives an engineer much more to work with than “the app is broken.” Reproduce it with invented records in a separate test environment, not by experimenting on customer orders.
Protect the journeys that matter
You do not need a test for every pixel. Start with the few actions the business depends on: signing in, creating a booking, charging correctly, and reopening the resulting invoice.
A useful repair includes a check that fails when the original bug is present and passes after the correction. It also checks the nearby journeys that share the same logic. A screenshot of the fixed checkout cannot prove the invoice still works.
Playwright's testing guidance recommends checking behavior visible to users and keeping tests isolated. For a founder, the practical requirement is simple: ask to see the customer journey succeed with controlled test data.
What should you ask an engineer to deliver?
Ask for the cause, the smallest sensible repair, the checks performed, and the release plan. If the shared code is too tangled to repair safely, request a bounded proposal to separate that part before approving a rewrite of the whole product.
Also ask how recovery would work if the release fails. Rolling back code does not automatically undo a change to stored data. Someone must check compatibility between the earlier app and the current database.
The decision is whether the team can make the problem repeatable and contain the change. If every attempt expands the damage, a focused engineering assessment is worth more than another open-ended request to “fix everything.”
Five prompts to use with your AI coding assistant
Before you begin: Use the same project conversation for all five prompts. Inspect first, approve the plan yourself, and never test against live customer data or secrets.
These prompts assume your assistant can inspect the relevant project. Ask it to say clearly if it cannot. Use the prompts one at a time, reviewing each response before moving to the next step.
1. Map
Inspect the relevant project files and map the components, shared functions, data flows, and dependencies connected to the failing feature. Explain the map in plain English and cite the actual files. Do not change anything.
2. Audit
Compare recent changes with previously working behavior where history exists. Inspect logs and tests. Identify confirmed regression causes, missing coverage, and risky shared dependencies; distinguish evidence from speculation.
3. Plan
Propose the smallest safe fix for confirmed problems, with regression tests for both the failed feature and related workflows. Explain each code change, affected files, and acceptance criteria. Do not implement.
4. Challenge
Review your own plan as a second engineer. Look for hidden dependencies, database compatibility issues, and tests you forgot. Run only existing safe tests or isolated simulations, then revise the plan.
5. Implement
Only after I approve the revised plan, implement the approved changes in a development branch. Run regression tests and report changed files, test evidence, and remaining risks. Do not deploy or modify production.
DitchNow can help investigate an existing app and plan a controlled repair. Explore production hardening, or book a founder call with the failing journey and the last working version in mind.
About DitchNow
DitchNow is based in Haarlem, Netherlands, and helps founders and teams fix and extend software and put AI to work. Meet DitchNow.