What does a real Claude Code debugging session actually look like?

An end-to-end transcript from 'reports are off by a day' through reproduction, root cause, fix, and test. Including the wrong turn we took along the way.

A real session, lightly edited. The bug: a weekly sales report was showing Sunday’s totals on Saturday’s row.

The opening prompt

The weekly sales report at /admin/reports/weekly is showing the wrong totals per day. Sunday’s number shows up under Saturday. I think it’s a timezone bug but I haven’t proven it. Don’t change anything yet — read the report code and tell me what you find.

I deliberately said “don’t change anything.” This is the cheapest moment to be skeptical.

Claude’s first read (paraphrased)

I read app/admin/reports/weekly.ts and lib/dates.ts. The report groups orders by order.createdAt::date in SQL, then renders them with date.toLocaleDateString() on the client. The DB is in UTC, the browser is in Helsinki time (UTC+2/+3). For orders created late Saturday Helsinki time, createdAt in UTC is already Sunday — so they get grouped under Sunday in SQL but rendered as “Saturday” by the client.

That’s a clean diagnosis. I almost approved it.

The wrong turn

I asked Claude to fix the SQL grouping by adding AT TIME ZONE 'Europe/Helsinki'. It did. The test I ran by hand still showed the bug.

That’s because the client-side label was the problem too. We had two layers each doing their own conversion, and fixing one without the other just shifted the inconsistency.

The right fix

I rolled back the SQL change. New prompt:

Roll back the last edit. The fix needs to live in one place, not two. Propose a plan where the server returns the date as a plain YYYY-MM-DD string already in Helsinki time, and the client renders it as a string with no further conversion.

That worked. The plan was three files (the report query, the API serializer, the React component), and Claude wrote a regression test that creates an order at 23:30 Helsinki time and asserts it shows up on Saturday.

What I’d do differently

Not approved the first fix until I’d seen a test that pinned the exact bug. “I think this fixes it” plus passing tests is much stronger than “I think this fixes it.”
Asked Claude to write the failing test first, before the fix. The test would have made the two-layer problem visible immediately — the SQL fix wouldn’t have made it green.