A Useful Bug Report Gives Agents Less Guesswork

A coding agent can inspect a project, edit its code, and run checks. It still needs a clear target. A report such as “the basket is broken” leaves it guessing about the screen, the trigger, and the intended behavior. A useful report gives it an observation it can investigate and a result it can verify.

You do not need to diagnose the defect before asking for help. Your most valuable contribution is often a precise account of something you saw.

Start with the behavior you actually observed

Describe the failure in everyday language. Name the feature, the action you took, and the result. For example: “After I remove the last item from my basket, the item disappears, but the total still shows its previous price.” That gives the agent a specific mismatch to trace.

Keep explanations separate from observations. You might suspect that an old value is being reused, but label that as a guess. Otherwise, the agent may spend its effort proving your theory instead of investigating the symptom.

A short reproduction makes the investigation repeatable

Give the smallest sequence of actions that reliably produces the problem. Include the starting state: whether you were signed in, whether the basket already contained items, and whether refreshing the page changes the result. A short sequence helps the agent reproduce the failure without inventing missing steps.

Useful details usually include:

• The page or feature where the problem appears.
• The actions needed to trigger it, in order.
• The expected result and the actual result.
• The browser, application version, or other relevant environment details.
• Whether it happens every time or only sometimes.

If the issue is intermittent, say so. “It happened twice during five attempts” gives the agent better evidence than “it randomly breaks.” Include any pattern you noticed, such as the problem appearing only after switching accounts.

Expected behavior gives the fix a finish line

A symptom identifies the problem; an expected result defines success. For the basket example, say that removing the last item should immediately show an empty basket and a zero total. Specify whether refreshing should be unnecessary.

If a product rule is uncertain, make that uncertainty visible. Perhaps delivery charges should disappear when the basket becomes empty, but you have not confirmed that policy. The agent can investigate existing behavior or ask a focused question instead of silently choosing a rule.

Relevant evidence helps without burying the signal

Include the exact error message when one exists. A short excerpt from a log can also help, especially when it corresponds to the moment of failure. Remove passwords, access tokens, personal information, and unrelated output before sharing it.

Tell the agent about a recent change if you know one, but avoid treating timing as proof. A problem first noticed after a release may have existed earlier. Distinguishing evidence from assumptions keeps the investigation open to other causes.

The connection supports the work without defining it

BestRelay publishes this guide and provides a quality-first API relay that forwards each request to the official model named in it, without substitution. It supports Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more, and works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. That connection still needs a clear task description.

Billing is pay-as-you-go, based on provider-reported token counts, with cache reads and writes priced separately. Members earn a referral commission when people they invite top up. Create a BestRelay account to get started.

Ask for a bounded fix and visible verification

Close the report by stating the work you want done: reproduce the issue, investigate its cause, make a focused correction, and verify the result. Mention relevant boundaries, such as preserving the current checkout design or avoiding unrelated cleanup.

Ask the agent to report the cause, the change, and the checks it completed. If it cannot reproduce the failure or run a check, it should explain that limitation. You can then judge the result against the behavior you described, with a clear record of the evidence supporting the fix.