How to Fix Bugs in AI-Built Apps Without Going in Circles

An AI builder can produce a convincing interface before anyone has proved that its data flow works. When the first bug appears, repeatedly asking the builder to “fix it” often creates a larger diff without a clearer explanation. The remedy is not a more forceful prompt. It is a smaller, observable debugging loop.

Treat generated software as software you now own. Reproduce the failure, identify the boundary where reality diverges from expectation, and change only enough code to test one explanation. That discipline protects working features while giving the assistant evidence it can actually use.

Capture a failure you can repeat

Start with a reproduction recipe, not a description such as “saving is broken”. Record the account role, starting page, relevant record state, exact actions, expected result, and actual result. Include whether the failure survives a reload. A disappearing notification and a missing database update are different defects, even when both look like a failed save.

Use a dedicated test account and synthetic records. Record the environment and deployed revision so another person can repeat the attempt. If it only happens intermittently, note the frequency and capture timing information rather than quietly simplifying it into a deterministic bug.

Collect boundary evidence from the browser console, network panel, and server logs. Preserve the request method, status, and a redacted response. Never paste session cookies, access tokens, customer details, or entire production logs into a builder conversation. An assistant does not need a real address to understand a validation error.

Use the JSON formatter to inspect a sanitised API response and compare its nesting and field types with the UI's expectations. For example, a list component expecting an array may receive an object containing an array. Formatting reveals structure; it does not prove the response matches the application's contract.

Locate the first broken boundary

Follow one action through its request lifecycle: input, client validation, request, authentication, server validation, database operation, response, and rendered state. Find the earliest point where expected and actual behaviour differ. A successful network response followed by an unchanged screen suggests a different investigation from a request that never leaves the browser.

Read the MDN Fetch guidance when inspecting client requests. A fulfilled fetch promise does not by itself mean an HTTP operation succeeded. Check response status and application errors explicitly before telling the user their change was saved.

Ask the assistant to explain competing causes before editing. Require each hypothesis to name evidence that would support or reject it. This creates a testable hypothesis instead of a plausible story. “The cache is stale” becomes useful only when you know which cache, which key, and what observation distinguishes it from a failed write.

If the generated project contains several overlapping data libraries, do not start by replacing all of them. Trace the component actually used by the failing route. Dead code and abandoned experiments can distract both people and assistants into repairing a path users never execute.

Request a bounded patch

Give the builder the reproduction, evidence, and scope together. Request a plan first when the proposed fix crosses authentication, schema, or payment boundaries. A small CSS adjustment needs less ceremony than a database migration, but both should have an observable acceptance condition.

A useful repair prompt looks like this:

Bug: editing a project name shows success, but reload restores the old name.
Evidence: PATCH returns 403 for a non-owner editor account.
Expected: editors may rename projects within their assigned workspace.
Inspect the route guard and server permission check before editing.
Propose the smallest fix; do not weaken workspace isolation.
Add regression tests for allowed and forbidden edits.
List changed files and explain why each change is necessary.

Set a change budget in terms of responsibility, not an arbitrary line count. Fixing a permission check may require a handler, policy helper, and test fixture. It should not require redesigning navigation or swapping the database client. Ask for an explanation whenever the assistant touches unrelated files.

Choose tools from the AI website builders directory with inspectable code and usable revision history. If the platform hides implementation details, insist on equivalent visibility into workflows, permissions, and deployment changes. A conversational interface is not a substitute for a reviewable patch.

Verify behaviour rather than appearances

Define regression coverage around the original failure before accepting the repair. Test the successful path, the original failing path, and an adjacent forbidden path. For the editor example, verify that an editor can rename an assigned project but cannot rename a project in another workspace.

Use the Playwright documentation for browser-level checks when the defect spans user interaction and rendering. Keep lower-level tests for validation and authorisation rules. A screenshot can show a success banner while the underlying write still fails, so assert persistent state after a reload as well.

Manually inspect loading, empty, and error states. Test slow responses and double submissions when relevant. Generated interfaces frequently handle the ideal response but leave a button enabled during a write, creating duplicate operations. A robust repair includes a sensible recovery path, not just the absence of a console error.

Review security-sensitive changes against the OWASP developer guidance. A builder may make an error disappear by relaxing a server policy or moving a secret into client code. That is a security regression, even if the original demonstration now works perfectly.

Keep an investigation ledger

Record each hypothesis, the change made, and its result. If a patch fails, revert it before testing an incompatible explanation. Otherwise several speculative repairs accumulate and make later evidence difficult to interpret. This single-variable loop is especially valuable when context windows become crowded with contradictory instructions.

After two unproductive attempts, stop generating changes. Re-read the reproduction, compare the current diff with the last working revision, and isolate the failing interaction in a smaller route or test. Ask for a second review of the evidence rather than a third rewrite of the feature.

Separate repair work from improvements discovered along the way. Put naming cleanups and component refactors in another task unless they are necessary to make the defect testable. The same principle applies when building internal dashboards: operational reliability matters more than making every screen look newly generated.

Close the issue with a release record: root cause, affected behaviour, test evidence, deployed revision, and rollback option. Watch the relevant error signal after deployment. A local success is evidence for a fix, not proof that production accounts, data, and infrastructure behave identically.

Key takeaways

• Capture a repeatable failure with sanitised request and response evidence.
• Find the earliest broken boundary before asking for code changes.
• Give the assistant one bounded hypothesis and explicit acceptance conditions.
• Verify persisted state, permissions, and recovery behaviour, not just visuals.
• Revert failed experiments and preserve a clear release and rollback record.