Debug Iron Rule: Log First, Fix Later
No speculative fixes allowed; answer three questions before fixing; declare impact scope after fixing
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Debug Iron Rule: Log First, Fix Later”?
No speculative fixes allowed; answer three questions before fixing; declare impact scope after fixing
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
No guesswork fixes. When the root cause cannot be confirmed, you must first validate your hypothesis through logs, breakpoints, or test scripts. "Let me just try changing this and see" is forbidden. Backend logs go to the terminal; frontend logs go to the browser Console. For any problem, the first step is always: add logs.
Click a path to observe the fix process. The counters on the right track the number of rounds and cumulative lines changed.
Guesswork Fix · Results
Log First, Then Fix · Results
The rule requires answering three questions before fixing any bug. Open each question in order — only after reading all three will the "Start Fix" button unlock.
Pre-fix research complete — proceed. After fixing, there is one last step: declare the impact scope so everyone knows what to regression-test.
No Mock to Bypass Real AI Interfaces
For any feature involving AI model calls, confirm the interface is truly accessible before delivery. If the user has not provided an API Key, stop and ask for it — hardcoding fake responses or local mocks to bypass the real call is forbidden. Once the key is in place, send a test request to verify it works before continuing development.
No Delivery Without Passing Unit Tests
Cover core business logic, API interfaces, data processing functions, and edge cases. Test files go in tests/, named test_{module_name}.py; Python projects use pytest. Temporary scripts used for debugging must be deleted after use.
Evidence first. The 2 minutes spent adding logs saves three rounds of guesswork rework and prevents the root cause from being buried. After fixing, declare the impact scope in the format ⚡ Impact scope: XXX, YYY, ZZZ, and pass both the real interface check and unit tests before delivery.
Turn the feeling in “Core Rule” into a judgment
“No guesswork fixes.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “Click a path to observe the fix process.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “Evidence first.” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Core Rule” to “Interactive Demo 1 · Same Bug, Two Approaches”
“Core Rule” grounds the problem in “No guesswork fixes. When the root cause cannot be confirmed, you must first validate your hypothesis through logs, breakpoints, or test scripts. "Let me just try changing this and see" is forbidden. Backend log…”. “Interactive Demo 1 · Same Bug, Two Approaches” then moves it toward “Click a path to observe the fix process. The counters on the right track the number of rounds and cumulative lines changed”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Core Rule”: No guesswork fixes. When the root cause cannot be confirmed, you must first validate your hypothesis through logs, breakpoints, or test scripts. "Let me just try changing this and see" is forbidden. Backend log…
- “Interactive Demo 1 · Same Bug, Two Approaches”: Click a path to observe the fix process. The counters on the right track the number of rounds and cumulative lines changed
- “The closing point”: Evidence first. The 2 minutes spent adding logs saves three rounds of guesswork rework and prevents the root cause from being buried. After fixing, declare the impact scope in the format ⚡ Impact scope: XXX, YY…
The final “The closing point” brings the discussion to “Evidence first. The 2 minutes spent adding logs saves three rounds of guesswork rework and prevents the root cause from being buried. After fixing, declare the impact scope in the format ⚡ Impact scope: XXX, YY…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.