How do I give AI evidence to diagnose a broken site?
Start with reproducible steps and expected-versus-actual behavior, collect evidence at the right layer, and test one root-cause hypothesis at a time.
On this page
Direct answer
Turn “something is wrong” into a repeatable observation before changing code. Browser console output, server terminals, deployed runtime logs, and build logs serve different purposes. Provide the actual environment, relevant complete errors, and the actions that led to them, with secrets removed. A bug may throw an error or quietly produce incorrect data; no red messages does not prove correctness. Compare expected behavior, visible output, and stored state instead of letting AI rewrite a large area immediately after seeing an error.
When to use
- The page is blank, a button does nothing, or output is wrong.
- AI keeps changing code without a stable reproduction or fix.
- Local use succeeds but deployment or particular users fail.
Step by step
Record the shortest reproduction
Specify environment, URL, login state, input, and actions, and describe expected and actual results separately. Note frequency, first appearance, and recent changes. Use a minimal example without private user data and preserve the failure state before a refresh loses evidence.
Collect evidence where the failure happens
Inspect browser Console and Network for interface behavior, the running terminal or platform runtime logs for server endpoints, and build logs for deployment failures. Record related statuses, responses, and request IDs. Extension errors may be unrelated noise; connect evidence to the target call chain.
Ask for a falsifiable hypothesis
Have AI read the relevant implementation and callers before proposing the best-supported causes and checks, such as missing configuration, authorization failure, empty data, or version mismatch. State what observation would support or reject each hypothesis. A ranked guess is not an established cause.
Make one small root-cause fix
Once a common cause is supported, fix it in the shared location instead of patching each caller differently. Fix configuration when configuration is wrong rather than upgrading every dependency. Keep error handling; do not disable checks, swallow exceptions, or fake data to make the symptom disappear.
Repeat the original flow and verify the business result
Rerun the failing input and check output, database state, and external calls, then directly affected neighboring behavior. Add a focused regression check for significant logic. Record the evidence for the fix and environments not checked; absence of an error is not the only criterion.
Connect logs to the same user action
Open developer tools before reproducing. Find the business file and line in Console and the related request/response in Network. Match server runtime logs by time or request ID; use build logs for installation or compilation failures. A GET returning 200 can still render an exception. Compare content-script or interceptor messages in an isolated browser without extensions before blaming business code. Never remove a safeguard simply to eliminate red messages. Simulate missing configuration only in an isolated practice environment, never by breaking production.
Worked example
Hypothetical exercise: local success and deployed API failure
Generation returns 500; the browser only establishes that the request failed. Matching runtime logs reveal a missing server variable. Configuration comparison shows it exists in preview but not production. Configure the target environment, redeploy, and obtain a real model result with the original input before declaring the fix. Rewriting fetch or replacing UI components would not address this cause.
In another hypothetical case, /blog returns 200 but a reference to a nonexistent BlogdddList component causes a blank page. Match the console file/line to the recent rename, repair the reference, and confirm the list actually renders. If an unrelated extension interception message disappears in a clean environment, record it separately rather than treating it as the cause.
Action checklist
Reusable templates
Reproducible debugging request
Working template
Environment and versions: [read from the actual project]
Page/endpoint: [location]
Reproduction: [steps from a clean start]
Expected: [result]; actual: [result]
Related error and request records: [redacted evidence]
Recent changes: [files or commit]
Trace the call chain and verify the cause before refactoring. Make one minimal fix, repeat the original business flow, add necessary regression checks, and report evidence.
Log locations and evidence chain
Action time, environment, URL, and account state:
Minimal reproduction:
Browser Console: [relevant error, business file:line, redacted]
Network: [path, status, response type, business fields, request ID]
Server runtime log: [matching time/ID]
Build log: [first causally relevant error if build fails]
Possible extension noise and comparison:
Recent change and one root-cause hypothesis:
Smallest check → change → original reproduction:
Unavailable evidence:
Pitfalls
- Do not dump every log into AI. Redact secrets and private data while preserving relevant context.
- Deleting configuration or upgrading all libraries is not the first response to dependency problems. Inspect the toolchain and actual error.
- Suppressing errors or returning default success can turn obvious failures into hidden data corruption.