Claude Code: I Used It Wrong for 8 Months. Here Is What Changed
There is a particular kind of feeling that every developer who has been burned by an AI coding assistant knows, and I hit it about eight months into using Claude Code in a way that still makes me wince when I think about it. I had asked it to refactor a login flow, a contained and well-defined task that should not have touched anything outside that module, and it had done what I had been assuming it was doing every time I asked it for a code change, which was to make the changes I requested and then tell me it had made the changes I requested. And I had looked at the message, seen that it said the work was done, and moved on with my afternoon. Three days later, a colleague on the QA team pinged me to ask why an API endpoint that had nothing to do with authentication was suddenly returning a different response structure. I had no idea, and it took me two hours of digging through the Claude Code conversation log to figure out what had happened: during that refactor, it had touched three unrelated files that it should not have touched, and nobody caught it because I had not known to look.
What I had been doing for eight months, in other words, was trusting Claude Code the way you trust a junior developer you have never worked with before, which is to say not at all, and also I had been doing it without the one tool that would have told me exactly what had changed the moment it happened. That tool is /diff, and when I found it I sat there for a moment feeling the specific combination of relief and regret that comes when you realize the thing you have been losing hours to every week had a solution the whole time that you simply did not know existed.
The /diff Command: The Feature That Changes How You Use Claude Code
/diff is a slash command that shows you every file Claude Code modified in the current session, with the actual changes displayed in a unified diff format. It runs against the working tree, not against the conversation log, which means it shows you what actually changed on disk rather than what Claude reported changing. The difference between those two things is the difference between knowing what happened and believing what you were told happened.
What It Actually Shows You
When you run /diff after a Claude Code session, you see the full set of changes, including files you did not explicitly ask it to modify. If it touched three files during a refactor and you only expected one, the diff shows you all three. You can then review each change and decide whether it was intended or accidental. This sounds obvious in retrospect, but the workflow most people fall into without it is to assume the reported changes are the actual changes, which is the assumption that leads to the three-day-later incident I described above.
The Broader Pattern: AI Tools Reward Understanding Their Constraints
The experience of discovering /diff after eight months of not knowing it existed is a specific instance of a broader pattern with AI coding tools: they have a surface area that is larger than their documentation suggests, and the features that are most valuable are often the ones that are easiest to miss. The tools that get used most effectively are not the ones that have the most features. They are the ones where the user has taken the time to understand the specific interaction model, including the escape hatches and the verification mechanisms that the tool provides for the moments when the AI gets something wrong.
Why Documentation Alone Cannot Solve This
The reason tools like Claude Code have this problem is that their actual functionality surface is discovered rather than read. Most users approach a new tool by trying to do the thing they want to do, and if it works, they move on. The discovery of /diff requires a different orientation: looking for the tool that catches the case where things go wrong rather than the case where things go right. That orientation is harder to develop from a documentation review than from the kind of incident that prompted me to look for it, which is probably why the /diff discovery story is a recurring one in conversations with developers who use Claude Code seriously.
What Changed After I Started Using /diff
The practical change after discovering /diff was not that Claude Code stopped making unexpected changes. It was that I caught them immediately instead of finding out about them three days later during a QA ping. The cognitive load of reviewing a diff after each session is low enough that it has become a reflex, the same way running tests after a refactor is a reflex. The incident rate from Claude Code side effects dropped to near zero, which is the outcome you want from a tool that was already doing what you asked, just sometimes doing more than you asked.
The lesson I keep coming back to is that AI coding tools are not tools you set and forget. They are tools where the interaction model includes verification steps that are optional in the happy path and mandatory in the cases that actually matter. /diff is not the exciting feature. The exciting feature is the task getting done. /diff is the thing that makes sure the task is actually done the way you think it is.
