Digital products ·
Keep one error as one task
After several AI requests, a form might start submitting while losing its ability to save records. Debugging with AI needs a boundary: which error are we fixing, what establishes its cause and how will we know the neighbouring action still works? Begin with one short scenario.
Make the problem repeatable
Consider a learning example: the Save button in a test application sometimes changes nothing. “Fix saving” leaves too many questions open. Record the initial state, entered values, sequence of actions, expected outcome and actual result. This is a hypothetical exercise, not a client case study.
Repeat the actions in the same application version. If the error disappears, compare conditions: a new or existing record, the user's role, required fields and connection state. Avoid a broad rewrite based on an unclear observation. The first useful debugging result is a scenario another person can follow to see the same problem.
Locate the first difference between expectation and fact
Saving involves a chain: a click, form validation, a request, a response, a stored record and an updated screen. Establish which steps actually happened. Investigating storage is premature when no request was sent. A record that exists but is missing from the interface is a different problem from a failed write.
The VS Code debugging documentation describes breakpoints and inspecting program state. They can help pause at a relevant step and examine values. Choose tools that fit your project. Each observation should answer a specific question instead of adding another unexamined log.
Give the model a small evidence package
Provide the scenario, error text, relevant code and the observation showing where the chain stopped. Name the version under investigation and the checks already performed. Remove tokens, passwords, personal records and other people's document contents. Replace values in example responses with invented ones while preserving the structure needed to understand the issue.
For example: “After filling the required fields, no save request appears. Here is the handler and the error. Suggest a likely cause and a check that would confirm it. Do not change the code yet.” This asks for an investigation. It gives you something to assess before accepting a large set of edits.
Give each hypothesis its own check
Suppose the model suggests that validation treats an optional field as required. Inspect that field's state and the validation result. If the observation contradicts the suggestion, return to the evidence. A confident explanation is still a hypothesis until program behaviour supports it.
Once the cause is understood, request a small correction and an explanation of its scope. Preserve the earlier version using the project's available workflow. Keep a library replacement, form redesign and storage restructuring outside this fix. Several unrelated changes make it harder to identify what helped and what introduced another problem.
Finish by repeating the scenario
Run the original steps with the same test values. Then check the nearest relevant action: invalid required input should still be rejected, an existing object should update and another click should have an agreed outcome. The right checks follow from the cause. There is no universal three-button checklist that proves every fix.
Run appropriate automated checks if the project has them. For an important recurring defect, preserve a test that reproduced the failure before the change. A successful build alone does not prove that saving works; it answers a different question. Exercise the actual behaviour in the test environment before accepting the correction.
Leave a short record for the next investigation
Record the symptom, confirmed cause, changed location and verified outcome. List remaining uncertainties separately. If the correction fails its checks, return to the saved version or restrict further work. A long AI explanation cannot stand in for evidence that the application behaves correctly.
Try this exercise after starting with vibe coding and before publishing your first website. I share further practice in my Telegram channel about vibe coding. If the error exposes unclear product rules or a chain of connected systems, a development review can help define the problem before more changes are made.
From an idea to a digital product
If the task calls for a service or internal tool, we can define the first complete journey and a path to a working release.