Directing AI to build good backends
Turn the whole module into leverage: specify an endpoint contract precisely and review AI server code for the mistakes it reliably makes.
This is where the module pays off. Backend bugs are quieter than UI bugs — a missing authorization check looks fine until someone exploits it — so the leverage is in specifying the contract precisely and reviewing for the failures AI reliably makes. Get good at the brief and the review, and you can direct an AI to build a backend that’s correct, secure, and won’t fall over.
Write the spec, not the wish
“Add a todos API” forces the AI to guess — and it guesses the insecure happy path. A real spec names the route, the method, the request and response shapes, the status codes, the authorization rule, and what to validate. Everything from this module shows up: the contract from 9.2, the ownership rule from 9.4, the validation discipline, the “move slow work to a queue” instinct from 9.6.
WISH: "Add an API for todos."
SPEC: "Add REST CRUD for todos. Every route requires auth.
GET /api/todos → 200 { todos } — only the logged-in user's todos
POST /api/todos → 201 todo — body { title: string (required) }; 400 if missing
PATCH /api/todos/:id → 200 todo — only if todo.userId === user.id, else 403; 404 if absent
DELETE /api/todos/:id → 204 — same ownership check
Validate the body, never trust a client-supplied userId, DB URL from env.
On signup, queue the welcome email — don't send it inline."That spec names the verbs, routes, shapes, codes, the ownership rule on every mutation, the validation, the secret handling, and the async boundary. You’ll get correct status codes and authorization checks on the first pass instead of finding the holes in production.
Review every handler — the checklist
AI server code compiles and passes the happy-path demo while quietly missing the checks that matter. Run the same list over every handler; each failure is a one-line ask you already know how to phrase.
| AI backend mistake | How you catch it | What you ask for |
|---|---|---|
| Missing authorization | “can user A act on user B's record?” | “add the ownership check; 403 otherwise (9.4)” |
| No input validation | send a bad/empty body | “validate the body; 400/422 on bad input” |
| Hardcoded secret | scan for keys/URLs in the code | “read it from an env var, never the repo” |
| N+1 query | look for a DB call inside a loop | “fetch the relation in one query (9.3)” |
| Swallowed error / 200-for-all | check catch blocks + status codes | “log it, return the right 4xx/5xx” |
| Slow work inline | third-party call in the handler | “move it to a queue (9.6)” |
Feedback in backend language — and lean on the platform
Vague feedback (“make it more secure”) gets vague results. The vocabulary from this module makes feedback precise and actionable: “scope this query to the logged-in user,” “validate the body and return 422 on bad input,” “this secret needs to come from an env var,” “move the email send to a queue,” “this is an N+1 — fetch the relation in one query.” And know when not to build: auth, an ORM, a queue, file storage — these are solved problems. Ask the AI to use a vetted auth provider, the project’s ORM, a queue service, rather than hand-rolling security-sensitive code. Reuse beats reinvention here even more than on the frontend, because the cost of a hand-rolled auth bug is a breach.
01 Learning objectives
0 / 6 done02 Curated reading
03 Knowledge check
- 01easy
You should run a fixed review checklist (validation, authorization, secrets, status codes, N+1) over AI-written handlers before merging.
- 02medium
A good backend build spec for an endpoint names… (select all)
- 03medium
Reviewing AI server code, what's the single most important thing to check for?
04 Interview questions
browse all ↗What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.
-
How do you review an AI-generated API handler before shipping it?
Run a fixed checklist, because backend bugs are quiet — a missing check looks fine until it's exploited. Ask: is the input validated? Is the action authorized (ownership checked), not just authenticated? Are secrets read from env, not hardcoded? Are the status codes right (no 200-for-everything)? Are errors handled (not swallowed, no leaked stack traces)? Is there an N+1 (a DB call in a loop)? Is slow work off the request path? Each failure maps to a one-line fix, and the first item — authorization — is OWASP's #1 risk.
What a strong answer coversValidated input; authorized (ownership), not just authenticated.
Secrets from env; correct status codes; errors handled, not swallowed.
No N+1; slow work moved to a queue.
Authorization is the highest-priority check (OWASP #1).
Follow-ups they push on- Which item on the checklist is most often missing in AI code?
- How do you phrase the fix as a one-line instruction?
Red flag Accepting a handler because it compiles and the happy-path demo works — that's exactly when the security checks are missing.
source: OWASP API Security Top 10 (2023) ↗