The Setup
A few weeks ago I was deep in a project — a PHP-based internal tool running on shared cPanel hosting, session-driven authentication, no framework, just vanilla PHP doing its job. A client reported that users were getting randomly logged out after switching pages. Classic. The kind of bug that's boring to debug and nearly invisible in logs.
I had a rough hunch. I'd seen this before. But I decided to try something: instead of just diving into the code myself, I'd use Claude as a first-pass collaborator. Feed it the relevant code, describe the symptoms, see what it surfaces.
What happened next was genuinely instructive — not because Claude was useless, but because it was confidently wrong in a way that taught me a lot about how to use AI for code review properly.
Round One: The Confident Wrong Answer
I pasted in my session initialization code and described the problem. Claude came back quickly with a diagnosis: I wasn't calling session_start() before any output, which was causing headers to fail silently on some pages.
Except I was. I had session_start() at the very top of every page, before any HTML. I double-checked. Triple-checked. It was there.
I told Claude this. It apologized and gave me a new theory: my session.gc_maxlifetime was probably mismatched with the cookie lifetime, causing premature expiry.
Plausible! I checked my php.ini and the values were fine — both aligned. Dead end.
Third attempt: Claude suggested the session save path might not be writable on my hosting environment. I SSH'd in, checked the path, confirmed it was writable and that other sessions were saving fine.
Three confident answers. Three wrong answers. I'd wasted about forty minutes.
The Post-Mortem: What Was Actually Happening
I eventually found the bug myself. The issue was a specific page that was doing a redirect after setting a session variable — but it was using a relative redirect that, on the cPanel subdirectory setup, was resolving to a different subdomain context. The session cookie domain didn't match, so the browser silently dropped it.
It was a one-line fix. But here's the thing: Claude never could have found this with the information I gave it. I handed it isolated snippets of code and a vague symptom description. The actual bug lived in the intersection of my server configuration, my hosting directory structure, and a redirect URL — none of which I had shared.
That's not Claude's failure. That's my failure as the person asking the question.
What I Was Doing Wrong
Looking back, I made three critical mistakes when using Claude for this debugging session:
1. I gave it symptoms, not evidence
"Users are getting randomly logged out" is not a useful debugging input. It's a user complaint, not a technical observation. I should have come with logs, session data, reproduction steps, and environment context. I gave it the equivalent of calling a doctor and saying "I feel bad sometimes."
2. I gave it code out of context
I pasted individual files. The bug was architectural — it required understanding the whole request flow, the server config, and how pages were linking to each other. No AI can debug a system it can only see through a keyhole.
3. I treated it like a magic oracle
The moment Claude gave me a confident-sounding answer, I accepted it as a legitimate hypothesis worth testing before I'd even read it critically. I was outsourcing my thinking instead of using it as a thinking partner.
Round Two: Restructuring the Approach
After fixing the bug manually, I went back to Claude — not to re-debug, but to experiment. I wanted to see if I could get genuinely useful output by changing how I prompted it. Here's the structure I landed on:
Step 1: Establish full environment context first
Before sharing any code, I now write a context block that looks like this:
Environment:
- PHP 8.1 on shared cPanel hosting
- No framework — vanilla PHP
- Session storage: default file-based
- Directory structure: public_html/app/ with subdirectories per module
- Authentication: session-based, no JWT
- Known constraints: can't modify php.ini globally, .htaccess only
Problem: [specific, observable symptom with reproduction steps]This alone changed the quality of responses dramatically. Claude stopped suggesting server-level fixes I couldn't make and started working within my actual constraints.
Step 2: Ask for hypotheses, not answers
Instead of "what's wrong with this code?", I ask: "What are the five most likely causes of this symptom in this environment? Rank them by probability and explain your reasoning."
This forces a probabilistic framing instead of a single confident answer. It also makes it much easier for me to evaluate the output — I can immediately discard hypotheses I know are wrong and focus on the ones I haven't checked yet.
Step 3: Share the full request flow, not just a file
For auth bugs specifically, I now paste the entire flow: the login handler, the session initialization include, the redirect target, and the page that's failing. I annotate what each piece does in comments so Claude has narrative context, not just syntax.
Step 4: Ask it to identify what it can't see
This is the most underrated prompt I've found. After sharing code and getting an initial analysis, I follow up with: "What information would you need to be more certain about this diagnosis? What parts of the system are you not seeing that could affect this?"
Claude is actually quite good at this meta-level question. It'll often surface exactly the blind spots — "I can't see your redirect targets" or "I don't know how your session include is being loaded relative to your subdirectory setup" — that you need to go investigate yourself.
Where AI-Assisted Code Review Actually Shines
After this experience, I've recalibrated where I lean on Claude for code review and where I don't. Here's my honest breakdown:
- Great for: Spotting security issues in isolated functions (SQL injection, unescaped output, file path traversal)
- Great for: Reviewing logic errors in self-contained algorithms
- Great for: Suggesting improvements to code structure and naming
- Great for: Generating a checklist of things to verify when debugging a class of problem
- Weak for: Bugs that emerge from system architecture and configuration
- Weak for: Environment-specific issues (hosting quirks, shared server constraints)
- Weak for: Anything where the bug is in the interaction between components you haven't shown it
The Mindset Shift That Actually Matters
The biggest thing I took from this debugging post-mortem isn't a prompt template. It's a mindset reframe.
Claude is not a senior developer who knows your codebase. It's an extremely well-read collaborator who knows a lot about programming in general and nothing about your specific system. The quality of its help scales directly with the quality of context you provide — and with your willingness to critically evaluate its output instead of just running with it.
The session bug took me forty minutes to not-fix with AI and about eight minutes to fix once I sat down and read my own redirect URLs carefully. The AI didn't slow me down — my uncritical trust in it did.
That's the real lesson. AI-assisted code review is genuinely powerful when you treat the AI as a structured thinking partner and yourself as the final authority. The moment you reverse that relationship, you're just outsourcing your judgment to a system that sounds confident but has no idea what's actually running on your server.
What I Do Now
My current workflow for any non-trivial bug:
- Reproduce it myself and write down exact steps
- Check logs before opening any chat window
- Form my own hypothesis first
- Use Claude to pressure-test my hypothesis and surface alternatives I might have missed
- Use Claude to generate a checklist of things to verify — then go verify them myself
- Treat any single confident answer from Claude as one data point, not a verdict
It's slower than just asking "what's wrong?" and accepting the first answer. But it's actually faster than spending forty minutes chasing confident wrong answers down dead-end rabbit holes.
The tool is good. The discipline around using it is what takes practice.
