What is Claude Code? It Fixed a Bug It Couldn't See

By Lazar Milicevic · Published July 7, 2026 · 8 min read

A PDF invoice bug sat open on a client's SaaS for two weeks. Claude Code closed it in nine minutes — and the fix wasn't visible in the source file I pointed it at. That gap between "what the code says" and "what the code produces" is the entire reason Claude Code exists, and it's the part every explainer skips.

The bug that made me stop pasting code into chat

The client runs an invoicing SaaS. Compliance-critical PDFs — one wrong margin and a downstream validator rejects the document, which means a customer refund and a support ticket that eats half a day.

The specific bug: the totals column on the invoice drifted three pixels to the right whenever the invoice had more than eight line items. Three pixels. Not visible in a screenshot. Enough to fail the strict validator the client's customers ran the PDFs through.

I had opened that file three times over two weeks. Each time I'd reproduce it, stare at the CSS-to-PDF mapping, get pulled into a client call, and close the tab. The observe step — reproduce the bug, render the PDF, diff the output against a known-good one — took ~20 minutes per iteration. That's the tax that keeps small bugs open forever on a solo-run SaaS.

So I ran Claude Code on it with one prompt. Nine minutes later the bug was closed. Three files touched. Four iterations. The root cause was a padding value being multiplied by row count instead of applied once. Boring. Findable. But only if you're willing to actually render the PDF and inspect the bytes every single loop — which I wasn't, and Claude Code was.

What Claude Code actually is (the definition I use with clients)

Claude Code is an agentic loop that runs on your machine: read files → run commands → observe output → edit files → repeat. The chat prompt is just how you start the loop. Everything interesting happens after you hit enter.

That's the definition. It sounds boring until you compare it to what most people call "AI coding":

In the browser, you are the loop. You paste code, it guesses, you copy the guess into your editor, you run it, you paste the traceback back into the chat, it guesses again. The model never sees the actual runtime — only your description of it. That's why it feels confident and keeps being wrong.

Claude Code eliminates the human middle-hop. When it edits the PDF generator, it then runs the generator, opens the resulting PDF, and inspects that PDF as a real artifact. The source code is one input among several. The rendered output is the ground truth.

Read, run, observe, edit — the loop in one debugging session

Here's what actually happened on the invoice bug, step by step, as it appeared in the terminal.

$ claude
> The totals column drifts ~3px right on invoices with more than 8 line
  items. Generator is src/pdf/invoice_generator.py, template is
  templates/invoice.html. Sample broken PDF: samples/broken_9items.pdf.
  Find it and fix it.

The loop:

1. Read. Opened invoice_generator.py, the Jinja template, and the CSS file it references. Also opened the broken PDF as binary and parsed its content stream.
2. Run. Rendered the generator against a fixture with 9 line items. Diffed the resulting PDF's coordinate stream against a known-good 7-item PDF.
3. Observe. Noticed the totals column x-offset increased by ~0.4pt per row past row 8. Not a rounding error — a linear drift, meaning something was being multiplied.
4. Edit. Traced the offset back to a CSS padding-right value that a helper function was applying inside a loop instead of once per column. Patched the helper.
5. Verify. Re-rendered. Diffed again. Column stable across 1, 8, 9, 50 line items. Ran the existing test suite. Green.

Four passes through that loop. Nine minutes wall-clock. The critical move was step 3 — reading the actual PDF content stream, not the code that produced it. A chat model that only sees invoice_generator.py cannot find this bug, because the bug is in an interaction between three files and only shows up in the rendered output.

Why "observe" is the expensive step (and why this matters if you're not a developer)

Debugging cost isn't in typing the fix. It's in reproducing the bug and confirming the fix. On a solo-run SaaS, that observe step is what kills you.

Think about the bugs that actually eat time in a small business running custom software:

• The invoicing edge case that only happens for one customer, on Tuesdays, when they have EUR currency and a discount line.
• The reporting export that mangles one column when a customer name contains a comma.
• The webhook that silently drops one payload per day.
• The email that renders fine in Gmail and breaks in Outlook.

None of these are hard to fix. All of them are expensive to reproduce. You have to build the fixture, trigger the code path, capture the wrong output, compare it against the right output, then repeat that whole cycle for each attempted fix. On a Tuesday-only bug, one iteration can be a full day.

Claude Code does the reproduce-and-compare loop in tight cycles while you do something else. On the invoice bug I answered two client emails during the nine minutes. That's the actual value proposition — not "AI writes code," but "AI runs experiments on your system so you can stop being the human in the loop."

Anthropic's own Claude Code documentation frames it the same way: an agent that "takes actions" in your environment, not a chatbot that emits suggestions.

What you need to set up before you point it at production code

Running Claude Code on a demo project is trivial. Running it on a client SaaS where a wrong edit costs real money needs three things in place first.

The non-negotiables

• A CLAUDE.md at the repo root describing the project — what it does, which files are dangerous, what commands to run for tests, what the deploy pipeline looks like. This is the agent's onboarding doc. Without it, it wastes iterations guessing.
• A clean git working tree and a branch it can commit to. So you can git diff and git reset if it goes sideways.
• A test command that actually runs. pytest, npm test, make check — something that gives a clean pass/fail. The loop is only useful if it can observe success.

Here's a minimal CLAUDE.md for the invoice project:

# Invoice SaaS — Claude notes

## What this is
Tax-compliant invoice generator. PDFs are validated downstream by a
strict schema. Wrong margins = customer refund.

## Danger zones
- src/pdf/invoice_generator.py — compliance-critical, always render
  a sample PDF after edits and diff against samples/known_good/*.pdf
- src/tax/ — do not touch without asking

## How to test
- Unit tests: `pytest tests/ -x`
- Render sample: `python scripts/render_sample.py --items N`
- PDF diff: `python scripts/pdf_diff.py <a.pdf> <b.pdf>`

## Style
- Type hints required
- No new dependencies without asking

That file is the difference between an agent that thrashes for 40 minutes and one that closes a bug in nine. It tells the loop what "observe" means for this codebase — in this case, that inspecting a rendered PDF is the source of truth, not passing unit tests.

The second thing that matters is folder scope. I don't point Claude Code at the whole repo when I only want it in one subsystem. On the invoice bug I ran it in src/pdf/ with read access to templates/ and samples/. Narrow scope = fewer wrong turns.

Where this fits vs. Claude.ai, Cursor, and Copilot

Quick honest comparison, because these tools solve different problems and I've watched people burn weeks picking the wrong one.

• GitHub Copilot — inline autocomplete. Great for typing faster in known patterns. Does not run your code, does not debug, does not observe output. Different category.
• Cursor — an IDE with strong AI editing and multi-file context. Excellent for interactive coding sessions where you want to stay in the driver's seat. Has agent modes now, but the default workflow assumes you're watching every edit.
• Claude.ai in the browser — good for architecture conversations, code review, one-off snippets. The moment you need to run and observe, you become the bottleneck.
• Claude Code — a terminal-based agent that runs the loop itself. Best when the bug lives in the gap between source and runtime, or when the observe step is what's actually expensive.

I use Cursor for greenfield feature work where I want to feel the shape of the code. I use Claude Code for bugs, refactors across many files, and anything where I'd otherwise spend an hour reproducing before I could start thinking. They aren't competitors — they're different jobs.

Where bizflowai.io fits in

When we build custom automation and internal SaaS tools for clients at bizflowai.io, the CLAUDE.md, the test harnesses, the sample fixtures, the safe folder layout — all of that is part of the handoff. A client shouldn't have to know what an agentic loop is to benefit from one; they should just find that the "Tuesday-only" bugs get fixed the same afternoon they're reported. That's what a properly-scoped Claude Code setup buys a small operator: the expensive observe step, automated.

The reframe

Stop thinking of Claude Code as "an AI that writes code." It's an AI that runs experiments on your live system and iterates until the output matches what you asked for. The prompt is a hypothesis. The test suite and the rendered artifacts are the ground truth. The loop is what closes the gap.

For a solo founder shipping custom software, that's the difference between bugs that sit open for two weeks and bugs that close in nine minutes — on files you were previously scared to touch.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.