Receptury backendowe

Receptury backendowe to 11 stron promptów do skopiowania dla Claude Code, Codex i Cursora: jedna o projektowaniu API, dziewięć o językach i frameworkach oraz jedna o serverless. Każda receptura łączy prompt z maszynowym sprawdzeniem, takim jak test integracyjny na prawdziwej bazie, detektor wyścigów czy test kontraktu, które dowodzi poprawności wyniku bez czytania każdej linii przez człowieka.

Ta strona jest dla programistów, którzy oddają agentowi kod po stronie serwera. Wiesz, gdzie to pęka: testy jednostkowe przechodzą, a na produkcji wychodzi zapytanie N+1, zapisane do połowy zamówienie, wyczerpana pula połączeń albo dwa żądania, które jednocześnie wygrywają ten sam wyścig.

Która receptura backendowa pasuje do twojego stosu?

Każda receptura zakłada konfigurację z następnej sekcji.

Twój stos	Receptura	Co receptura obejmuje i sprawdza
Projektowanie API HTTP, dowolny język	Wzorce rozwoju API	Idempotentne `POST`-y, paginacja kluczem (keyset), kontrola dryfu OpenAPI
Node.js z Express, TypeScript	Przepisy na Node.js/Express	Transakcje w Prismie, rotacja tokenów, rate limiting, zadania BullMQ
Python z FastAPI, Django	Przepisy na Python	FastAPI i Django REST, asynchroniczny SQLAlchemy 2.0, testy API w pytest
Go	Wzorce języka Go	`go test -race`, wykrywanie wycieków goroutine, pule połączeń o ustalonym rozmiarze
Java ze Spring Boot	Wzorce Java i Spring Boot	Testy Testcontainers dla JPA, odporności i bezpieczeństwa
C# z ASP.NET Core, EF Core	Receptury .NET i C#	Testy xUnit na prawdziwym Postgresie, analizatory, które przerywają build
Ruby on Rails	Receptury Ruby on Rails	`bin/ci` jako definicja ukończenia, N+1, przez które padają specy
PHP z Laravel, Symfony	Wzorce rozwoju PHP	Cienkie kontrolery, usuwanie N+1, testy PHPUnit
Rust	Wzorce rozwoju Rust	Zapytania SQLx sprawdzane przy kompilacji, walka z borrow checkerem, czyste zamykanie usług async
Elixir z Phoenix	Przepisy na Elixir/Phoenix	`mix precommit` jako bramka, testy OTP i Ecto
AWS Lambda, Cloudflare Workers, Vercel	Wzorce rozwoju serverless	Idempotentne handlery, kontrola bindingów, diagnoza zimnych startów

Zmiany schematu, kod ORM i wolne zapytania znajdziesz w przepisach bazodanowych.

Najpierw zapisz bramkę w instrukcjach agenta

Każda receptura kończy się poleceniem „uruchom bramkę”, więc repozytorium musi tę bramkę nazwać. Wpisz do pliku instrukcji dokładne komendy i definicję ukończenia, na przykład w usłudze w TypeScripcie:

## 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.

Miejsce pliku zależy od narzędzia:

Claude Code czyta CLAUDE.md. Od v2.1.277 (kanał latest) czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md. Na kanale stable (v2.1.274 w dniu 2026-09-26) trzymaj CLAUDE.md z jedną linią @AGENTS.md. Żeby definicja ukończenia stała się mechaniczną kontrolą, dodaj hook Stop, który uruchamia testy: zobacz hooki Claude Code.

Codex czyta AGENTS.md, zanim zacznie pracę. Od Codex 0.150.0 niezaufany projekt nie dostarcza swojego projektowego AGENTS.md, więc oznacz repozytorium jako zaufane, gdy Codex o to zapyta.

Plik instrukcji to tylko rada. Rozstrzyga job CI, który uruchamia te same komendy przy każdym pull requeście; zobacz automatyzację pipeline’ów. Jedno źródło prawdy dla wszystkich trzech narzędzi opisują wspólne reguły agentów.

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.

Jak zweryfikować kod backendu bez czytania każdej linii?

Dla każdej awarii poproś o sprawdzenie, które ją wykrywa i kończy się błędem, i wymagaj, żeby agent dołączył jego wynik.

Awaria	Sprawdzenie, które ją łapie
Zapytania N+1	Test, który liczy zapytania na żądanie i pada powyżej ustalonej liczby
Brak transakcji	Test, który wymusza błąd w połowie operacji i sprawdza, że nic nie zostało zapisane
Wyciek połączeń lub goroutine	Statystyki puli albo detektor wycieków sprawdzane przy sprzątaniu po testach
Wyścig na współdzielonym stanie	Detektor wyścigów, jeśli język go ma (`go test -race`), plus test, który wysyła równoległe żądania do tego samego zasobu i sprawdza niezmiennik
Dryf kontraktu API	Wygenerowana specyfikacja OpenAPI porównywana w CI z tą zapisaną w repozytorium

Człowiek zatwierdza dwa razy: kryteria akceptacji, zanim agent zacznie, i nieodwracalne kroki, gdy skończy, na przykład migrację usuwającą dane albo zmianę uwierzytelniania. Oba zatwierdzenia trafiają do pakietu dowodów pull requesta.

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.

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.

Co się psuje, gdy agent pisze kod backendu?

Testy przechodzą, bo agent zamockował bazę. Naprawa: definicja ukończenia wymaga testów integracyjnych na prawdziwym silniku; konfigurację Testcontainers pokazują wzorce testowania integracyjnego.
Agent poprawia test, aż zrobi się zielony. Naprawa: zabroń tego w pliku instrukcji, przeglądaj diff testów osobno i przeczytaj ochronę wyroczni.
Kod używa API frameworka ze starszej wersji. Naprawa: daj agentowi aktualną dokumentację przez Context7 albo przez serwer MCP samego frameworka, jeśli receptura go wskazuje.
Bramka jest zielona lokalnie i czerwona w CI. Naprawa: niech CI uruchamia dokładnie te komendy, które są w pliku instrukcji, a agent odtworzy nimi błąd, zanim cokolwiek poprawi.
Agent pomija bramkę i ogłasza „gotowe”. Naprawa: dodaj hook Stop w Claude Code i ustaw job CI jako wymagane sprawdzenie dla każdego narzędzia.

Dokąd dalej po recepturach backendowych

Wzorce rozwoju API

Przepisy bazodanowe

Rozwój API z AI

Jak przygotować repozytorium do pracy agentów

Książka kucharska dla deweloperów AI