Backend recipes

The backend recipes are 11 pages of copy-paste prompts for Claude Code, Codex, and Cursor: one for API design, nine for languages and frameworks, and one for serverless. Each recipe pairs the prompt with a machine check, such as an integration test on a real database, a race detector, or a contract test, that proves the output without a human reading every line.

This hub is for developers who let an agent write server-side code. You know where it breaks: the unit tests pass, then production shows an N+1 query, a half-written order, a drained connection pool, or two requests that both win the same race.

Which backend recipe fits your stack?

Every recipe assumes the setup in the next section.

Your stack	Recipe	What the recipe covers and checks
HTTP API design, any language	API development patterns	Idempotent POSTs, keyset pagination, OpenAPI drift checks
Node.js with Express, TypeScript	Node.js/Express recipes	Prisma transactions, token rotation, rate limiting, BullMQ jobs
Python with FastAPI, Django	Python workflow recipes	FastAPI and Django REST, async SQLAlchemy 2.0, pytest API tests
Go	Go language patterns	go test -race, goroutine-leak checks, sized connection pools
Java with Spring Boot	Java and Spring Boot patterns	Testcontainers tests for JPA, resilience, security
C# with ASP.NET Core, EF Core	.NET and C# recipes	xUnit tests on real Postgres, analyzers that fail the build
Ruby on Rails	Ruby on Rails recipes	bin/ci as the definition of done, N+1 queries that fail specs
PHP with Laravel, Symfony	PHP development patterns	Thin controllers, N+1 removal, PHPUnit tests
Rust	Rust development patterns	Compile-checked SQLx queries, borrow-checker fixes, clean async shutdown
Elixir with Phoenix	Elixir/Phoenix recipes	mix precommit as the gate, OTP and Ecto tests
AWS Lambda, Cloudflare Workers, Vercel	Serverless development patterns	Idempotent handlers, binding checks, cold-start triage

Schema changes, ORM code, and slow queries live in database recipes.

Write the gate into the agent’s instructions first

Every recipe ends with “run the gate”, so the repository must name the gate. Put the exact commands and a definition of done in the instruction file, for example in a TypeScript service:

AGENTS.md

## Commands
- Types: `npx tsc --noEmit`
- Lint: `npm run lint`
- Tests, unit and integration (needs Docker): `npm test`
- One file: `npx vitest run src/orders/orders.test.ts`

## Definition of done
Types, lint, and tests pass, and your reply ends with the last lines of each.
Any change that touches the database adds an integration test against real
Postgres, not a mocked client. Never edit an existing test to make it pass
without asking first.

Where the file lives differs per tool:

Claude Code

Claude Code reads CLAUDE.md. From v2.1.277 (the latest channel) it also reads AGENTS.md when the project has no CLAUDE.md. On the stable channel (v2.1.274 on 2026-09-26), keep a CLAUDE.md that contains only the line @AGENTS.md. To turn the definition of done into a mechanical check, add a Stop hook that runs the test command: see hooks automation.

Codex

Codex reads AGENTS.md before it starts work. Since Codex 0.150.0, an untrusted project does not supply its project-level AGENTS.md, so trust the repository when Codex asks.

Cursor

Add a project rule that applies to every agent request and repeats the Commands and Definition of done sections. Cursor project rules covers the format.

An instruction file is advice. The CI job that runs the same commands on every pull request is the gate that decides; see CI/CD pipelines. For one source of truth across all three tools, see shared agent rules.

Copy-paste prompt: write the gate section for an existing service

Read the build files, lockfile, CI workflows and test config of this repository.
Write a "Commands" section for AGENTS.md with the exact type-check, lint, test,
single-test and migration commands this repo uses today, and a "Definition of
done" section. Then run every command you listed and report which ones failed
or need a service (Docker, a database) that is not running. Do not change any
source file in this step.

How do you verify backend code without reading every line?

Ask for the check that goes red for each failure, and require the agent to attach its output.

Failure	The check that catches it
N+1 queries	A test that counts queries per request and fails above a fixed number
Missing transaction	A test that forces an error halfway through the operation and asserts nothing was written
Leaked connections or goroutines	Pool statistics or a leak detector checked at test teardown
Race on shared state	A race detector where the language has one (go test -race), plus a test that sends parallel requests for the same resource and asserts the invariant
API contract drift	A generated OpenAPI spec diffed against the committed one in CI

A human signs off twice: on the acceptance criteria before the agent starts, and on irreversible steps after it finishes, such as a migration that drops data or an authentication change. Both approvals go into the pull request’s evidence bundle.

Copy-paste prompt: an endpoint that proves itself

Acceptance criteria: <paste them here>.
Implement POST /orders so that it meets these acceptance criteria.
Work test-first:
1. Write failing integration tests against the real database from the
   test setup (not mocks): happy path, validation error, duplicate
   Idempotency-Key returns the original order, and a forced error after the
   first insert leaves no rows behind.
2. Add a test that sends 10 parallel requests with the same Idempotency-Key
   and asserts exactly one order exists.
3. Assert the handler runs a fixed number of SQL queries, independent of the
   number of line items.
4. Implement until the full Definition of done in AGENTS.md passes, and paste
   the last lines of each command. Do not edit a test to make it pass.

Copy-paste prompt: audit an existing handler

Audit src/orders/ for four backend failures: N+1 queries, writes that are not
wrapped in one transaction, database connections or clients that are not
released on every error path, and shared state read and written without a lock
or a conditional update. For each finding, give the file and line, then write a
failing test that proves it before you change any code.

What breaks when agents write backend code?

• The tests pass because the agent mocked the database. Recovery: the definition of done requires integration tests against a real engine; the integration testing guide shows the Testcontainers setup.
• The agent edits a test until it goes green. Recovery: forbid it in the instruction file, review the test diff on its own, and read protect the oracle.
• The code uses a framework API from an older version. Recovery: give the agent current documentation through Context7, or through the framework’s own MCP server where the recipe names one.
• The gate is green locally and red in CI. Recovery: make CI run the exact commands from the instruction file, and have the agent reproduce the failure with them before it fixes anything.
• The agent skips the gate and says “done”. Recovery: add the Claude Code Stop hook, and make the CI job a required check for every tool.

Where to go next with backend recipes

API development patterns

Database recipes

API development with AI

Making a codebase agent-ready

AI Developer Cookbook