What Claude Code Actually Does When It Writes Your Backend

There's a particular kind of awe — and skepticism — that shows up when developers hear that a backend was written by AI. Either it's magic ("Claude wrote my whole API!") or it's snake oil ("there's no way that code is production-ready"). Neither is quite right. After spending three months building Echo3s — a PDF-to-audiobook SaaS — with Claude Code as my primary backend coding partner, I want to do something the breathless takes don't: show you what Claude Code actually does when it writes your backend. Real prompts, real code it produced, real bugs it shipped, and the loop that turns half-right output into something you'd ship.

What Claude Code Is (and Isn't)

Claude Code is a command-line agent that runs locally, reads your repository, edits files, runs commands, and reads output. The mental model that helps most: it's a fast, eager engineer who has no memory between sessions and has read every public Stack Overflow answer. It will absolutely write your Supabase Edge Function, configure your queues, and wire up Stripe webhooks. It will also confidently invent function signatures that don't exist, miss obvious race conditions, and ship the wrong default in a config file unless you push back.

The interesting question isn't "can it write my backend?" — it can. The interesting question is "what does the actual minute-by-minute work look like?" Because that's where the real surprises are.

Step 1: It Reads Before It Writes

The first thing you'll notice running Claude Code on a non-trivial change is that it spends the first 30 seconds doing nothing visible — except it isn't doing nothing. It's globbing your repo, reading package.json, opening adjacent files, and grepping for related symbols. When I asked it to "add a global concurrency cap to our PDF processing worker so we never exceed six concurrent Gemini calls platform-wide," the first batch of tool calls looked like this:

• Glob: supabase/functions/**/*.ts
• Read: supabase/functions/process-pdf-chunk/index.ts
• Grep: worker_slot across the repo
• Read: supabase/migrations/ (the ones referencing try_acquire_worker_slot)

This matters more than it looks. The biggest difference between Claude Code and "AI autocomplete in a textarea" is that it grounds itself in your actual code before generating. The result was a worker that called an existing Postgres RPC try_acquire_worker_slot rather than inventing a new in-memory cap that wouldn't survive multiple Edge Function instances.

Step 2: A Real Prompt and What Came Back

Here's a slightly trimmed version of what I actually asked for character voice assignment in Echo3s:

"In process-audiobook-segments, we currently assign every line to a single narrator voice. I want to detect characters per book, assign each character a distinct ElevenLabs voice from the catalog, and persist the mapping so re-runs are deterministic. Don't break existing audiobooks — gate behind a multiVoice column on the project."

Within about a minute, Claude Code had:

• Written a new SQL migration adding multi_voice boolean and a character_voice_map jsonb column to audiobook_projects.
• Added a new helper, assignCharacterVoices(characters, voiceCatalog, existingMap), that prefers the existing mapping where present and round-robins through suitable voices for new characters (preferring same-gender matches when known).
• Modified the segment loop to look up the voice via the map before falling back to the default narrator.
• Added a check at the top of the function so books without multi_voice = true followed the original code path unchanged.

That's a real, structured change — schema, helper, integration, feature flag. The kind of work that takes a human engineer most of an afternoon. Claude did it in maybe 90 seconds of generation time.

Step 3: It Runs Things and Reads the Output

The part that's still genuinely surprising — even after months of using it — is what happens after the code is written. Claude Code doesn't stop at "here's a diff." It runs the type-checker. It runs the test command if one exists. It runs the migration. When something fails, it reads the error output and tries again.

On the multi-voice change above, the first attempt failed type-checking because Claude had written:

const voice = catalog.find(v => v.gender === character.gender);

…but our VoiceCatalogEntry type didn't have a gender field — voices were tagged with a labels object that included gender as a string. The compiler said so, Claude read the error, opened the type definition, and corrected to v.labels?.gender === character.gender on the next pass without me intervening.

This is the loop that does the heavy lifting. It's not "AI writes perfect code." It's "AI writes plausible code, runs the verifier, reads the verifier's complaint, fixes it." The verifier — your type system, your tests, your linter, your runtime — is doing as much of the work as the LLM is.

Step 4: A Real Bug It Shipped

Lest this sound too rosy: Claude Code regularly ships bugs. Some of them are subtle. Here's one from the Echo3s codebase that survived several sessions before I caught it.

The audiobook compilation step concatenates segment audio files in order. The original implementation Claude wrote sorted segments by their created_at timestamp before concatenation. Looks reasonable. But because segments are generated in parallel by multiple workers, created_at doesn't match narrative order — segment 47 might finish before segment 12. The bug only manifested on books with enough parallelism that segments completed out of order, which on a small test PDF didn't happen.

The fix was a one-line change — sort by segment_index, not created_at — but Claude didn't catch it because the test it had run (a 5-page PDF) didn't trigger the parallelism. Lesson: Claude is great at making the verifier happy. If the verifier is weak, the bug ships. Strong tests, especially tests that exercise the same conditions production sees, are what convert "AI wrote it" into "AI wrote it and it works."

What It's Genuinely Good At

After three months of this, here are the categories of backend work where Claude Code consistently saves serious time:

Glue code. Webhook handlers, queue producers/consumers, retry wrappers, idempotency keys, error-to-HTTP-code translation. The boring connective tissue of any backend. Claude is excellent at it because the patterns are well-established and the verifier (it either works or it doesn't) is strong.

Schema migrations. Forward and backward migrations, including the data backfill scripts. Tell it the new shape, and it will produce a migration plus the application-layer changes to use it. Always read these before applying — the SQL is usually right but occasionally indexes get missed.

Surface-level refactors. Renaming a function across 40 files, splitting a large file into modules, extracting a shared helper. The kind of change that's mechanically tedious for humans and where the cost of a slip-up is high.

Translating between APIs. "Here's our existing Stripe integration; add a parallel path for paddle.com." Claude is very good at pattern-matching one well-documented API onto another.

What It Still Gets Wrong

It hallucinates function signatures from libraries it half-remembers. It picks defaults that are convenient for the example but wrong for production (overly permissive CORS, too-aggressive caching, retry counts that will hammer downstream services). It will happily write a feature that works in isolation but conflicts with an existing one elsewhere if you don't point it at both files. And it will sometimes confidently assert that a Postgres function exists when it doesn't, then write code that calls it.

The mitigation isn't "stop using it." The mitigation is the same skill that good code review has always required: read the diff before you ship the diff. The diffs are smaller and more frequent now, but that's the only difference.

What Changes About How You Build

The thing that took me longest to internalize: with Claude Code, the bottleneck shifts from writing code to knowing what code you want written. The 90 seconds Claude spent generating the multi-voice feature were preceded by maybe 20 minutes of me thinking about the data model, the gating, and the upgrade path for existing books. That thinking was the actual hard part. The typing — the part that used to feel like the hard part — was barely there.

This is genuinely different from how most of us learned to engineer. Reading code carefully, designing thoughtfully, and writing strong tests have always been valuable. With AI in the loop they go from valuable to load-bearing — they're what turn a fast generator into shipped product.

The Honest Bottom Line

Claude Code didn't write Echo3s on its own — I designed the architecture, made the trade-offs, and caught the bugs that escaped the verifier. But it wrote the vast majority of the typed lines, ran the migrations, and held the context across files in a way that would have taken me weeks longer alone. The result is a real production backend serving real users with PDF-to-audiobook conversion. If you want to see what shipped, our audiobook library is the output of that backend in action, and our three-month build story covers the wider founder side. If you've got a PDF you'd like to turn into an audiobook, the free tier is the easiest way to see the result of all this code in under five minutes.