Vibe coding
Write a bug report that gets an AI app builder unstuck
Provide a reproducible starting state, the failing action and useful evidence without burying the problem in a long chat.
Zocri · 2 min read · Sources checked
Report the smallest failing journey
Playwright's trace viewer can associate browser actions with screenshots, errors and network activity during a recorded test. Whether your builder exposes such a trace or not, use the same idea: connect the action to its evidence. 'The app does not work' is difficult to investigate. 'My saved request disappears after I refresh' points to a specific journey.
Record the address, the user role and the starting state. Explain whether you began with an empty list or an existing request. Give the exact sequence of clicks and the visible result. Use an invented record so someone can repeat the case without exposing customer information.
State expectation and observation separately
Write what should happen and what actually happened in different sentences. For example, the new request should remain in the owner's list after refresh; instead, the list becomes empty. Do not state that the storage system is broken unless you have evidence identifying it as the cause.
Add when the issue began and the last known working version if available. Mention the most recent relevant change without assuming it caused the defect. A new filter, an expired session and an environment mismatch can all produce similar symptoms while requiring different corrections.
Attach evidence that narrows the question
Include a screenshot of the starting state and one after the failure. If logs or a trace are available, keep the relevant action and time window. Remove passwords, secret values and unnecessary personal information before sharing evidence outside its intended access boundary.
Ask the builder to reproduce the issue before proposing a broad rewrite. If it cannot reproduce it, identify the difference between your environment and its test. The account, browser, record age or published version may explain why two people see different outcomes.
Close the report with a regression check
After a fix, repeat the original sequence using a new sample record. Then check the adjacent path: edit an existing request, refresh again and confirm the change remains. Record the result on the address where the issue occurred, not only in a different preview.
Keep the final report short: symptom, cause when established, change made and verification performed. If the cause remains uncertain, say so. A good report ends with evidence that the original failure is resolved and enough context to recognize it if the same pattern returns later.