Give coding agents visual feedback they can act on
Capture the issue, prepare the handoff and review a later fix.
Summary
A useful visual bug report shows the affected control, explains how the problem happens and separates the observed result from the expected behavior. Give a developer or coding agent that report with its visual evidence and project context. The brief and checklist below help you prepare the handoff and review a later fix.
Key points
- Show the sequence and describe it. A short clip identifies the interaction. Written steps make the report useful without replaying the video.
- Separate observation from expectation. Say what the interface did and what you expected it to do. Leave the cause open until someone investigates.
- Give the receiving agent the project context. Include the relevant repository, page and reference, then review any later fix against the original steps.
Watch the existing Denker example: a filter menu disappears while the user tries to select Open. The user records the interaction, dictates the observation and reviews a structured report with a clip in an unsent Gmail draft. We use that case to explain what a developer needs before investigating.
Watch: from spoken observation to a bug-report draft
Short transcript
Condensed speech and on-screen actions.
- 00:00Spoken observation, condensed: There’s a problem with this button in Chrome on macOS. When I click it and try to select Open, it disappears.
- 00:05Open Filter on the fictional Sample Tasks page. Hold Caps Lock to record the menu interaction and draw around the relevant area.
- 00:10Release Caps Lock to save the short clip, then return to the Gmail draft. The Cmd + 1 cue explains the saved Bug report prompt used to structure the dictation.
- 00:19Review the report and MP4 attachment in the unsent draft. Check the wording and evidence references before sharing. The drawing is inside the clip; this take does not show a separate marked screenshot.
Start with the issue the recording shows
The demonstration uses a fictional Sample Tasks page in Chrome on macOS. The user opens Filter and tries to select Open. The menu disappears. The recording captures the interaction and a drawing around the relevant area.
Denker's saved Bug report prompt structures the spoken observation. The final view shows a report and MP4 attachment in a Gmail draft, ready for review. The draft stays unsent. The clip ends at that report; a coding-agent investigation and fix would be a separate next step.
The spoken observation is condensed in the video's transcript:
There’s a problem with this button in Chrome on macOS. When I click it and try to select Open, it disappears.
| In the recorded case | Add before a coding investigation |
|---|---|
| The Filter interaction on a fictional Sample Tasks page is captured. | The real page or route, starting state and steps the recipient can reproduce. |
| The narration names Chrome on macOS and describes the disappearing menu. | Verified versions and any relevant conditions. Leave unknown details unspecified. |
| The final Gmail draft contains a report and MP4 attachment. | Access to the reference and relevant repository in the conversation doing the work. |
The video is a concrete example of preparing feedback. Its edited duration is not a measurement of how long a bug report or fix takes.
Write observed and expected behavior separately
“The filter is broken” leaves the recipient to discover which control, action and result you mean. Name the control and describe the sequence in order. For this case, the report can identify Filter, opening the menu and moving to select Open.
Put the observed result in its own field: the menu disappears during that interaction. Then state your expectation. For example, “The menu should remain available while I move to Open and select it.” That sentence is a proposed expectation for the brief, rather than a quotation from the recording.
Keep explanations such as a focus problem or hover-handler bug out of the observation. The developer or agent can investigate the cause. Add repetition counts, browser versions and error messages only after checking them.
Keep the visual reference with the steps
A screenshot helps identify a control or layout. A short recording is useful when the problem depends on a transition, such as a menu closing while the pointer moves. In this take, the drawing is inside the clip; a separate marked screenshot is not shown.
Describe the essential sequence in the report even when a clip is attached. Check that the recipient can open the attachment and understands which moment matters. Denker's dictation enhancement organizes the spoken account; it does not diagnose the attached video.
The recorded bug-report walkthrough explains the dictation prompt and report workflow. The recording guide covers capture controls and availability.
Add project context before asking for a fix
The recorded output is an unsent Gmail draft. To continue with a coding agent, bring the reviewed report and accessible reference into the conversation that has the relevant project access. Identify the repository, local page and starting state there.
Ask the recipient to confirm the target and reproduction steps before editing. If it cannot inspect the clip, provide the written sequence and suitable still images, or resolve access first. Do not assume that attaching a recording means the agent has watched it or that a screenshot supplies the underlying source code.
Keep the initial task bounded: reproduce the reported interaction, investigate the cause and propose a fix with a way to check it. Denker's Code setup guide explains the coding setup. Available session and approval controls depend on the route; see the provider controls guide.
Copy this UI-change brief
Fill in the fields and send the report with its reference to the conversation doing the investigation. Keep unknown facts explicit.
UI CHANGE BRIEF
Goal: [What should work differently for the user?]
Provider / project / repository: [The actual destination]
Receiving conversation: [The session doing this work]
Page and starting state: [URL, environment and relevant UI state]
Visual reference: [Accessible clip or marked image]
Affected control: [The exact control or section]
Reproduction steps:
[Actions in order, with any verified conditions.]
Observed behavior:
[What you saw. Separate observations from possible causes.]
Expected behavior:
[What should happen for the user.]
Unknown details:
[Facts still to check; do not infer them.]
Requested work:
Confirm the target and steps, reproduce the issue where possible, then
investigate and propose a bounded fix. Say if the reference is inaccessible.
Preserve:
[Existing behavior, content and surrounding areas that must stay intact.]
Acceptance criteria:
- [Repeat the original sequence and check the expected behavior.]
- [Check relevant adjacent interactions or viewport states.]
Return:
Changed file paths, a readable diff, actual check results and the local
page to review. State failed or skipped checks and remaining questions.
Boundary:
Keep the work local for review. Ask before sending the report, pushing
changes or deploying.For the recorded case, use Filter as the affected control, describe selecting Open and record the disappearing menu as the observation. Add the actual repository and page before requesting implementation. The Gmail draft alone does not establish a receiving coding session.
Use this outcome checklist
- The report identifies the affected control, starting state and steps.
- Observed and expected behavior are separate; unknown facts stay explicit.
- The reference opens and supports the observation described in the report.
- Before investigation, the receiving conversation has the report, reference and relevant project access.
- After a fix, the original sequence and relevant adjacent behavior have been checked on the running page.
- Changed files, check results and remaining questions are recorded before accepting the fix.
The recording supports the report-preparation stage. Complete the investigation and fix-review items only when you have performed those steps.
Review a later fix against the same sequence
Use the original report as the review plan. Open the local page in the stated starting state, open Filter and try selecting Open. Check the menu's behavior, the selected result and other relevant menu interactions. Add keyboard, touch or narrow-width checks when they matter to the affected interface.
Read the changed-file diff and applicable project checks alongside the visible result. A completion message starts your review. If the issue remains, describe the exact mismatch and return it to the same conversation with the reference.
Start with one issue you can describe and reproduce. Use the bug-report walkthrough to prepare the report, then set up the coding destination when you are ready to investigate it.