The Vibe Father
Playbook
A REST API is one of the best things to build with an AI agent, because the shape is well-known, the model has seen ten thousand of them, and the whole thing is testable end to end. It's also one of the easiest to build insecurely, because an agent racing to "make the endpoints work" will happily ship an API with no auth, no validation, and a SQL injection hole in the first query. This playbook is the order that gets you a real, secure REST API in a day — and the security checks we never skip, no matter how tight the day is.
Why the order matters
Build in the wrong order and you retrofit security onto a working API, which never fully happens — you run out of day, it "works," and the auth gets bolted on next sprint that never comes. Build in the right order and each layer constrains the next: validation before you trust input, auth before you expose data, tests before you call it done. The order is the security.
The one-day order
- Routes and models. Define the resources, the endpoints, and the data shapes first. Get the skeleton returning stubbed responses so the surface is real before any logic. Agents scaffold this in minutes on a boring stack.
- Validation. Every endpoint that accepts input validates it — types, required fields, lengths, allowed values — and rejects bad input with a clear error before it reaches your logic or your database. This is step two, not step nine, because everything after it assumes the input is safe.
- Auth. Decide who can call what, and enforce it on every endpoint. Token-based auth with a middleware that runs before the handler is the boring correct default. Every new route is guarded by default; public routes are the explicit exception.
- Business logic. Now, with clean input and known callers, wire the real behavior — the database queries, the calculations, the side effects. This is the part agents do fastest and where you keep them from injection with parameterized queries only.
- Tests. For each endpoint: the happy path, the validation rejections, the auth failures (no token, wrong token, someone else's resource), and the realistic error cases. See writing tests that actually catch bugs — an API is where always-pass tests hide worst.
- Docs. Generate reference docs grounded in the real routes, with examples that actually run. Keep them honest per documenting code with AI accurately — an API doc that lies is worse than none.
- Deploy. Ship it behind HTTPS, with secrets in environment variables (never in the repo), rate limiting on, and a health check. Boring hosting on a boring stack is the fast path.
The security checks we never skip
These are non-negotiable regardless of deadline. Run them as a pass before you call the API done:
- Every query is parameterized. No string-built SQL, ever. This is the single most common agent-introduced hole.
- Every endpoint checks authorization, not just authentication. "Logged in" is not "allowed to touch this specific record." Confirm the caller owns the resource they're asking for — broken object-level authorization is the classic API breach.
- No secrets in the repo. Keys, tokens, and connection strings live in environment variables. Grep the diff before every commit.
- Input validation on everything, output encoding where it's rendered. Reject bad input early; encode anything that flows to a client.
- Rate limiting and sane payload caps. An unlimited endpoint is a denial-of-service and a bill waiting to happen.
- Errors don't leak internals. A 500 returns "something went wrong," not a stack trace with your file paths and query.
The full list is in the AI coding security checklist; an API touches most of it.
Divide the work across agents
| Agent role | Owns | Parallel? |
|---|---|---|
| Builder | Routes, validation, logic | Yes |
| Builder (2nd) | Tests against the contract | Yes |
| Reviewer | Security pass, different lab | After |
If you split the work, the reviewer must be a different model than the builder — that cross-lab check is what catches the injection the author didn't see. Solo, run the review as a second pass with a second model. Either way, the AI code review workflow is the gate before deploy.
Model picks for a one-day build
Most of a REST API is value-model work — Sonnet 5 or GPT-5.3 Codex scaffold routes, validation, and tests cleanly and cheaply, and Gemini Flash's speed keeps the iterate-and-run loop tight. Save a top model (Opus 4.8 daily, Fable 5 for the hardest reasoning per our benchmarks) for the auth layer and any genuinely tricky business logic, and use a different lab's model for the security review. Pick a boring stack the models know cold — Laravel or Next with Postgres or SQLite — and the whole thing genuinely fits in a day.
The move
Scaffold the routes, validate before you trust, guard before you expose, test every failure path, then deploy behind HTTPS with secrets in the environment. That order is the difference between an API that ships secure and one that ships a breach. When you're ready to put a UI or a bot in front of it, building a chatbot with AI agents and the full ship your first product path pick up from here. In The Vibe Father, a Builder and a Reviewer run in parallel and the AutoVibe gate re-runs your real tests before any change is accepted — but this build ships fine from a single terminal with the order above.
