What is Claude Code? It's a Codebase Reader, Not a Coder

By Lazar Milicevic · Published June 16, 2026 · 9 min read

A Serbian retailer using one of our invoicing tools sent in a ticket last week. Partial refund, mixed VAT rates, credit note total off by a few cents. On a credit note, a few cents isn't a rounding annoyance — it's a compliance problem. The app is four years old, 187 files, ~24,000 lines, and I hadn't opened the refund path in eight months. In the old workflow, this ticket eats my afternoon. It took 19 minutes end to end. Here's exactly what happened, and why I think most people are framing Claude Code wrong.

Claude Code is not an AI coder. It's an AI codebase-reader.

Every tutorial I've seen demos Claude Code by having it write a brand-new toy app. To-do list. Landing page. Snake game in the terminal. That's the easy 20%. Writing new code from a blank file is the part LLMs have been good at since GPT-3.5.

The hard 80% — the part that actually matters when you run production software — is reading code you've forgotten or never wrote. Tracing a request through 12 files. Finding the one helper that does the rounding wrong. Understanding why there are two code paths for refunds before you touch either of them.

That's the unlock. Claude Code is a terminal agent that lives inside your real repo. It can:

• Grep the codebase for symbols, strings, or patterns
• Open files and follow function calls across modules
• Run your tests and read the output
• Propose diffs and apply them after you approve

Compare that to the chat product, where you paste a snippet and it reasons about what you pasted. Different tool. Different category. The chat is a reasoning surface. Claude Code is an agent with hands on your repo.

If you internalize one thing from this post: the value isn't generation. It's navigation.

The actual session: three prompts, 19 minutes, one shipped fix

I'll walk you through the trace because nobody demos this on legacy code.

Prompt 1 — orientation:

Where is VAT refund logic handled in this codebase,
and walk me through the flow from API endpoint to PDF output.

Eleven seconds. It ran a grep, opened the refund controller, opened the invoice service, opened the credit note generator, then handed me a four-paragraph summary:

• Endpoint receives the refund payload at routes/refunds.js
• Service layer recalculates line items in services/invoiceService.js
• VAT split happens in helpers/vatSplit.js
• Credit note PDF is built in templates/creditNote.hbs

It also flagged something I'd forgotten: two distinct code paths for refunds, branching on whether the original invoice had mixed VAT rates. That branch is where the bug lived. I didn't tell it to look for the bug. It surfaced the suspicious branch while explaining the architecture.

Prompt 2 — drill into the suspect:

Show me the function that handles mixed VAT rate refunds
and explain how it calculates the credit total.

It opened the helper, walked me through the math line by line, and inside its own explanation said:

This calculation rounds each line item before summing, which can produce a one-cent drift on credit notes with three or more lines at different VAT rates.

That's the bug. Diagnosed mid-explanation. I never asked "find the bug." I asked "explain the code." The diagnosis fell out of the reading.

Prompt 3 — fix and test:

Propose a fix that sums first and rounds once, and show me the diff.

It generated a six-line patch in one file. Then, on its own, it noticed we had unit tests for the invoice service and asked if it should add a test case for the mixed-rate refund scenario. Yes. It wrote the test. I reviewed the diff in the terminal, approved, ran the suite. Green.

The workflow shift: you stop remembering, you start reviewing

Here's the part I want you to actually sit with if you run software you built years ago.

The agent re-onboarded itself to my codebase in 11 seconds. I did not. I never reopened a file in an editor. I never rebuilt the mental model in my head. The agent did it, told me what it found, and I made decisions on top of its summary.

That's the shift. You stop being the person who has to hold every file in working memory. You become the person who reviews and approves.

For a solopreneur with one, two, three production apps, this is the difference between code being an asset and code being a liability. Most of us hit a point where our own software starts to scare us, because the cost of context-switching back in is too high to justify a small fix. Tickets pile up. Customers churn on edge cases. Features stagnate.

Claude Code collapses the re-onboarding cost to seconds. Which means the small fixes get shipped instead of avoided. Which means tickets don't pile up. Which means your software stays alive.

Setup that actually matters: CLAUDE.md, project root, and review discipline

A few practical notes if you want to run this on your own codebase. These are the things I wish someone had told me on day one.

Run it in the actual project root, not a subfolder. The agent's navigation depends on being able to grep the whole repo. If you start it in /src it can't see your tests, your config, your migrations. It will give you confidently wrong answers about architecture.

Drop a CLAUDE.md at the root. This file makes every session smarter from the first prompt. Mine is short — three things:

# CLAUDE.md

## What this app does
Fakturko is an invoicing tool for Serbian small businesses.
It generates compliant invoices, credit notes, and VAT reports.

## Architectural boundaries
- routes/ — Express endpoints, thin
- services/ — business logic, all VAT math lives here
- helpers/ — pure functions, no DB access
- templates/ — Handlebars for PDF output
- tests/ — Jest, mirrors services/ structure

## Conventions
- All money values handled as integer cents, never floats
- Tests live next to source: services/foo.js → tests/services/foo.test.js
- Run tests with: npm test
- Deploy command: npm run deploy:prod (do NOT run this yourself, ask me)

That's it. Two minutes to write. Every session afterwards starts smarter because the agent knows the shape of the codebase before it grep's a single file.

Always review diffs before approving. The agent is good. It is not infallible. I've caught it proposing a fix that would have silently changed behavior in an unrelated code path. Your job shifts from writing to reviewing — but reviewing is still your job. Reading a six-line diff takes 30 seconds. Skipping that step is how you ship regressions to production.

Quick checklist before your first real session

• Repo is committed and clean (so you can diff/revert easily)
• CLAUDE.md at the root with app summary + boundaries + conventions
• Test suite runs locally with one command
• You start the agent in the project root
• You review every diff before approving

What this means for the legacy code you're avoiding

Be honest with yourself. How many of these do you have right now?

• A side project from 2021 that still has paying users but you won't touch it
• A WordPress plugin or Shopify app where one customer keeps hitting an edge case you can't reproduce mentally
• An internal tool you built for your own business that's now indispensable but unmaintainable
• A client handoff from two years ago they keep emailing you about

Each one of those is a 90-minute re-onboarding tax every time a ticket comes in. That tax is why you ignore the tickets. That's why those projects feel like ghosts haunting your inbox.

The 11-second re-onboarding doesn't mean Claude Code writes your software for you. It means the activation energy to open up old code drops to near zero. You can answer "where does X happen in this codebase" in the time it takes to drink coffee, not the time it takes to clear an afternoon.

For me, this changed which tickets I take. I used to triage by "how painful is the re-onboarding," not by "how valuable is the customer." That's a terrible heuristic, but it's the honest one. Now I triage by value because the re-onboarding cost is gone.

Why bizflowai.io helps with this

A lot of what we build for clients at bizflowai.io sits on top of exactly this dynamic — small businesses with one or two custom apps they're afraid to touch, plus a support inbox full of "small" bugs that never get fixed because re-onboarding is too expensive. We set up Claude Code workflows on their repos, write the CLAUDE.md files, wire the agent into their ticket queue so support requests can be diagnosed against the actual codebase in minutes instead of afternoons. The result is usually the same: a backlog that's been frozen for months starts moving in a week.

Frequently asked questions

What is Claude Code and how is it different from a chat AI coder?

Claude Code is a terminal-based agent that reads, navigates, and edits a real repository on your machine. Unlike chat AI tools where you paste snippets for it to reason about, Claude Code has access to your whole repo. It can grep, open files, follow function calls across modules, and run your tests, making it useful for understanding existing production code, not just generating new code.

How do I use Claude Code to debug an unfamiliar codebase?

Open the terminal in your project root and ask plain-English questions about the code flow, like 'Where is X logic handled and walk me through the flow from endpoint to output.' The agent runs greps, opens relevant files, and summarizes what it finds. You can then ask it to explain specific functions, diagnose bugs, propose diffs, and add tests, reviewing and approving each step.

Why does Claude Code matter for solopreneurs maintaining production apps?

Solo developers often hit a point where their own software scares them because context-switching back into a forgotten codebase costs too much time to justify small fixes, causing tickets to pile up. Claude Code re-onboards itself to the repo in seconds and summarizes findings, so the developer reviews and approves instead of rebuilding mental models. This turns aging code from a liability back into an asset.

When should I use Claude Code instead of opening my editor manually?

Use Claude Code when you're returning to code you wrote months ago, haven't touched recently, or didn't write yourself, especially for bug fixes in large or aging codebases. Manual editing makes sense when you already hold the file's mental model. In the example given, a refund VAT bug in a 24,000-line, 187-file app took 19 minutes with Claude Code versus an estimated 90+ minutes manually.

What percentage of real coding work is reading versus writing code?

According to the narration, generating new code is the easy 20 percent of real software work. The other 80 percent is reading and understanding code you've forgotten or never wrote, including following imports, rebuilding mental models, and tracing how features branch through modules. This is why agents that can navigate a full repository are more useful for production software than chat tools that only reason about pasted snippets.

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.