Choose a case you can reason about
Keep the relevant function and its caller visible where possible. Describe the expected result and the actual result separately. “This crashes” is a starting point; “this three-item input should return 13 but returns 4” gives the explanation a concrete path to investigate. Use a small example rather than a production record containing private data.
In the illustrated example, a sum returns from inside the loop. The arithmetic is simple on purpose. You can focus on control flow instead of wondering whether the example itself is complicated. A different bug may need an empty input, a duplicate value, or an unexpected ordering.
Separate observation from a proposed explanation
Rayito can inspect the code visible on your screen, narrate a short step, and annotate the relevant line or relationship. Ask it to show how a value changes as execution proceeds. A proposed trace is an explanation to inspect, not proof that the application ran that way.
If the problem depends on a function outside the visible area, open it before accepting a conclusion. The assistant should ask for missing context rather than invent a definition. Keep error messages readable too: a concrete stack frame often narrows the question more effectively than a broad request to improve the code.
Use a visual that changes with the reasoning
In a loop, a marker can follow the current item while a small value label changes beside it. In a conditional, two branches can show which expression chose the path. In an asynchronous flow, a timeline can distinguish the order work starts from the order results arrive.
Pause after the first unexpected state. Predict the next value yourself before continuing. That moment checks whether you understand the cause. An explanation that marks every line at once makes this harder, because your attention has to decide which highlight belongs to the current sentence.
Make the smallest meaningful correction
Once the failure is clear, propose a limited edit. Moving a return statement is different from rewriting the function or changing its inputs. Keep those decisions separate so you can connect the edit to the failing case. Review any proposed action in the selected app before allowing it.
Run the relevant test in your own development environment and inspect its actual output. Then consider an adjacent case that the edit might affect. A passing example does not prove all behavior correct, but it does provide evidence that the specific explanation and correction agree.
Leave with an explanation you can reuse
Finish by stating the invariant or condition that should remain true. For this example, the result should be returned after every item has contributed. For another bug, the important rule might concern ordering, ownership, or an empty state.
Revisit the conversation in History when you want to review the visual reasoning. Rayito History can replay saved annotations; replay does not rerun the editor action or the test. That distinction keeps a useful explanation from becoming an accidental second edit.
A question to try“Help me understand this bug using one concrete input. Show where the behavior first differs from what I expect, then let me check the next step.”