Working on your machine and safe for other people are different states. This is the gap.
Before anyone else touches it
Secrets. No keys in client code, no keys in the repository, no keys in prompts. Environment variables or a secrets manager. Check your git history, not just your working tree — a key committed once is compromised until rotated.
Input. Treat everything from a user as hostile. Length limits, type validation, a cap on request size. The same applies to anything retrieved from a document or a web page before it reaches a prompt.
Output. Never render model output as raw HTML. Never execute returned code without review. Never pass returned values into a query or a shell without validation.
Permissions. The project's credentials should be scoped to exactly what it needs. Read-only where you only read.
Rate limits. Per user and overall. Without them one person, or one loop, consumes everything.
Spend caps. A hard maximum per user and per day, enforced in your code rather than hoped for. Cost is unbounded by default, and a runaway loop against a paid API is the most common expensive surprise in this field.
Make failure visible
Ship with logging from the first day: every request, every model call, every tool call, cost per run, and every error with enough context to reproduce it.
Then alert on the things that mean something is wrong: error rate rising, cost per run rising, runs hitting the iteration cap, and — the one people forget — the system not running at all.
Tell users what it is
An honest interface is a safety feature. Say that answers are AI-generated and may be wrong. Show sources where you have them. Make uncertainty visible rather than smoothing it away. Give people a way to report a bad answer, and read those reports — they are the highest-quality signal you will get about where the system fails.
What to build next
Pick something you personally need, small enough to finish in a weekend, where you can judge the output quality yourself. That last condition matters most: build in a domain you know, so you can tell good from plausible.
Good next steps, in rough order of difficulty:
- Retrieval over a document set you actually use
- An automation replacing a repetitive weekly task, with approval on the irreversible step
- An agent with two or three tools inside a domain you know well
- Evaluation tooling for something you already built — unglamorous, and the thing that most improves a system
The through-line
Ten stages, and one idea underneath all of them: these systems are useful in proportion to how well you understand what they are actually doing. Every capability here comes with a matching failure mode, and you now know both halves — which is the whole difference between using AI and being used by it.