You paste an error into your AI assistant.
“Fix this.”
It changes a condition. Adds a null check. Wraps something in try/catch.
The error disapp...
For further actions, you may consider blocking this person and/or reporting abuse
The reproduction step has a trap worth naming: hard-coding 800ms for "react" builds the hypothesis into the test, so it can only confirm out-of-order responses, never reject them. That's why the START/FINISH/APPLY trace from the real app in step 3 is what carries the weight, and the fake delay is mostly useful afterwards, for checking that the fix holds. I'd almost reorder the steps so the instrumentation comes before the controlled reproduction. Have you had a case where the real trace disagreed with the reproduction the assistant proposed?
Good catch. The fake delay demonstrates the mechanism, but it doesn’t prove that’s what happened in the real app. Putting the trace first would make that distinction clearer. I don’t have a specific case to share, but if the trace disagreed, I’d revisit the hypothesis rather than adjust the reproduction to fit it. What do you usually log first for these bugs?
For out-of-order bugs I'd start with three timestamps per request, all tagged with the same request id: when it was sent, when the response arrived, and when its result was written to state. The bug is usually visible as two ids whose arrival order differs from their send order, with the later write winning. If those three lines don't show an inversion, the race theory is probably wrong and it's worth looking elsewhere before writing any reproduction. The useful part is that the log can disagree with you, which a hard-coded delay never can.
Asking for proof before a fix is a habit worth spreading. A fix without a demonstrated cause is a guess, and AI makes guesses look very tidy.
One thing we add on client systems: the proof should end up as a failing test that turns green with the fix. That way the cause is written down in a form the next person can run, and the bug cannot quietly return when someone regenerates the same file later.
It also keeps the change small. When the cause is proven, the fix usually touches one place. When it is not, you tend to see a patch spread across five files, which is where regressions come from. Do you ask the model for a reproduction first, or for a hypothesis and then a reproduction?
One thing worth emphasizing is that a reproducible failure doesn't automatically prove the root cause. AI can identify patterns in logs and traces, but correlation alone isn't enough to establish causality. The real value comes from testing competing hypotheses and verifying that the proposed fix addresses the underlying mechanism, rather than just making the symptom disappear.
Đúng trọng điểm. Mình từng mất 3 ngày debug một race condition vì AI liên tục gợi ý thêm
lockhoặcretry— sửa surface mà không hiểu tại sao state bị corrupt. Chuyển sang hỏi "walk me through the execution path that leads to this state" thì AI mới vẽ ra được sequence diagram, mình mới thấy root cause là callback đăng ký listener sau khi event đã fire.Lesson learned: prompt "prove the cause" buộc AI phải reasoning explicit thay vì pattern-match patch. Còn side effect hay là code review dễ hơn — diff chỉ thay logic core chứ không rải rác defensive check khắp nơi PS: the tool I meant is on labagent .tech
The out-of-order responses example makes it clear that a plausible-sounding fix like debouncing just reduces the window instead of addressing the race. Requiring the assistant to separate observed facts from assumptions before suggesting a change would turn a lot of those guess fixes into verifiable hypotheses instead. Would asking it to attach a single failing test to each proposed cause - one that fires on the current code and stops firing after the fix - keep it from proposing fixes that only reduce frequency?
Absolutly true! Today everything depends on your prompt and trust to AI.
Thanks! A clear prompt helps, but the evidence is what earns the trust. “What would disprove your explanation?” is a useful follow-up when AI sounds too certain. Do you use a similar check?