Claude Code for backend development: APIs, databases, tests and migrations

Claude Code is well suited to backend development: it can build API endpoints across routes, services and tests, query a database through an MCP server, write migrations and run them against a dev database, and keep iterating until your test suite passes. The key is giving it checks to run and keeping it away from production data.

Claude Code reads your codebase, edits files and runs commands in your terminal. Backend work suits that loop because most of it has a clear signal: tests pass or fail, the server starts or crashes, the migration applies or errors. This guide covers what it does well, how to connect databases, a workflow, example prompts, skills and the guardrails to set first.

What can Claude Code do for backend work?

• API endpoints. Add a route with its handler, validation, service logic and tests in one change, following the patterns in your existing code.
• Databases. Read schemas, write queries, and explain slow ones, either from your migration files or live through an MCP server.
• Migrations. Write schema migrations and the matching model changes, run them locally, and check the result.
• Tests. Find untested code, add unit and integration tests in your project's style, run them and fix failures.
• Debugging. Read a stack trace or log, trace the request path through the code, and propose a fix with a regression test.
• Refactoring. Split a large service, rename across modules, or move to a new library version while the tests keep passing.
• Reviews. Run /code-review for correctness bugs and /security-review for vulnerabilities before you open a pull request.

Anthropic's prompt library uses two backend examples to show what a good prompt looks like: "add rate limiting to the public API and make sure existing tests still pass" and "write the migration, run it against the dev database, and confirm the schema matches". Both state the outcome and include a check.

How do you connect Claude Code to a database?

Add a database MCP server. The MCP docs show DBHub, which connects to a relational database through a connection string, and advise using "a read-only database user in the connection string so the queries Claude runs can't modify data":

claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
  --dsn "postgresql://readonly:pass@localhost:5432/app_dev"

Run /mcp and check that the db row shows a checkmark. Then ask questions like "show me the schema for the orders table" in plain language.

If you use a hosted database, check the vendor's plugin first. Anthropic's official plugin marketplace includes plugins for Supabase, Prisma, Neon, PlanetScale and MongoDB, among others. Install one with /plugin install <name>@claude-plugins-official. For errors in production, the Sentry server is a common addition:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

The Claude Code MCP guide covers scopes, auth and sharing servers through .mcp.json.

What does a safe backend workflow look like?

1. Write down the conventions. Put the stack, the commands to run tests and lint, the folder layout and the rules ("never edit applied migrations") in CLAUDE.md. The CLAUDE.md for FastAPI and CLAUDE.md for Django pages show examples.
2. Plan larger changes. Use plan mode for anything that touches the schema, auth or several services. Claude explores and writes a plan without editing.
3. Give it a check. Anthropic's best practices say "Give Claude a check it can run: tests, a build, a screenshot to compare." For backend work that is usually the test suite plus a type checker or linter.
4. Verify against the running app. The bundled /verify skill builds and runs your app to confirm a change does what it should, and /run-skill-generator records how to launch projects that need a database or env file. In the desktop app, Claude can start a backend server, test API endpoints and view the server logs.
5. Work in parallel safely. claude --worktree feature-auth starts a session in its own git worktree so two tasks don't collide. See Claude Code worktrees.
6. Review before merge. Run /code-review and /security-review, then open a pull request.

A PostToolUse hook can also run your formatter after every edit. The hooks docs show one that runs Prettier on each file Claude edits; swap in ruff format, gofmt or your own tool.

Which prompts work well for backend development?

These are example prompts written for this guide. Each names the outcome, points at existing code to match, and asks Claude to run a check.

Add a POST /v1/invoices/{id}/refund endpoint. Follow the structure of the existing payments endpoints, validate input with our schema library, make it idempotent with an Idempotency-Key header, and add tests for success, double refund and unknown invoice. Run the test suite and fix failures.

Add a nullable archived_at column to projects and filter archived projects out of the list endpoint. Write the migration, run it against the dev database, confirm the schema matches, and show me the migration file. Do not touch existing migrations.

This query is slow in production: @slow-query.sql. Use the db MCP server to read the schema and run EXPLAIN on the dev database. Propose an index or a rewrite, explain the tradeoff, and add a test that covers the query's results.

Here is the stack trace from Sentry: @trace.txt. Trace the request path, find the root cause, write a failing test that reproduces it, then fix it. Don't suppress the error.

Find functions in services/billing/ that have no tests. Add tests for edge cases: zero amounts, currency rounding, expired cards and retries. Run them and report coverage before and after.

The API design prompts, SQL prompts and API testing prompts collections have more.

Which skills and plugins help backend work?

The best backend skills page compares more. For type errors after each edit, install a code intelligence plugin for your language.

What guardrails should you set for backend work?

Claude Code runs commands with your credentials, so the same session that runs pytest could run a migration against production if your shell can reach it. Here is an example project settings file, written for this guide with the documented rule syntax, that allows routine commands and blocks destructive ones:

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "Bash(npx prisma migrate dev *)"
    ],
    "ask": [
      "mcp__db__*"
    ],
    "deny": [
      "Bash(npx prisma migrate deploy *)",
      "Bash(npx prisma migrate reset *)",
      "Read(./.env.production)"
    ]
  }
}

The permissions docs say rules are evaluated "deny, then ask, then allow", and mcp__<server>__* matches every tool from one MCP server. A Read deny rule covers Claude's file tools and shell commands it recognizes, such as cat, but not a script that opens the file indirectly, so pair it with the sandbox if you need an OS-level boundary.

Beyond rules: point local sessions at a dev database, give MCP servers a read-only user, keep production credentials out of the shell Claude runs in, and apply production migrations through CI after review. The permissions guide and Claude Code security cover the rest.

How do you keep backend prompts and conventions reusable?

Endpoint checklists, migration prompts and debugging recipes are worth keeping. Kipt saves prompts and Agent Skills as Markdown in your own private GitHub repo, with {{name}} blanks for things like the table or service name, and installs your skills into Claude Code or Codex with npx skills add. To turn a working prompt into a skill, use the free SKILL.md generator.