When your AI builds your backend, the output isn’t magic — it’s a pull request. This post walks through exactly what happens between “build me one” and a live product on jerrycan, a self-hostable Rust backend framework for REST APIs, and why the result is code you can trust rather than a black box you rent.
Key takeaways
- The agent writes real Rust — routes, models, migrations — into a repository you control.
- Rust’s compiler catches a whole class of AI mistakes before anything ships.
- Batteries (auth, data, files, payments) live in the framework, so the agent composes instead of improvising.
- The same conversation that builds the product deploys and updates it.
Step 1: a sentence becomes a plan
The input is plain English: “Build me a client portal where customers see their invoices.” The agent decomposes it into what every real product needs — accounts and sign-in, data models, file storage, payment flows — and maps each need to a jerrycan building block.
This mapping is where an AI-native framework earns its keep. There is one right place for auth, one right shape for a data model, one standard way to expose a REST endpoint. The agent doesn’t choose between twelve ORMs and five auth strategies; it composes parts designed to fit.
Step 2: the agent writes code you can read
This step is the difference between owning and renting. The agent doesn’t click through a dashboard or wire five hosted services together — it writes Rust into your repo:
- Routes for every endpoint your product exposes.
- Models and migrations for your data, in a standard database you keep.
- Wiring for the batteries — sessions, roles, storage, payments — using the framework’s built-ins rather than bespoke glue.
Open the diff and read what your product does. Change it by hand, or ask again. Nothing about your own product is opaque to you.
Why compiled Rust makes AI output trustworthy
“AI-generated code” earns skepticism. Two properties do the heavy lifting here:
- The compiler is a relentless reviewer. Type errors, missing cases and broken references stop the build. The agent iterates until the backend compiles — an entire category of plausible-but-wrong output never survives to production.
- The framework narrows the blast radius. Security defaults, encrypted storage and backup wiring live in jerrycan itself, not in agent-written glue. The agent’s job is your product logic — the part you can actually read and judge.
Trust, but verify: the code is in your repo precisely so verification is always possible.
Step 3: shipping is the same conversation
“Ship it” deploys a small compiled binary to your VPS, your cloud, or a box in your office — TLS, domain and backups wired up. There’s no interpreter at runtime and no platform between you and your users. Updates use the motion that built the product: describe the change, review, redeploy.
Where this fails (and what happens then)
Honesty section. Agents mis-read vague asks, and products have edge cases no one described. When that happens you’re holding code, not a support ticket: ask the agent to fix it with a clearer description, or edit the Rust directly. Compare that with a rented backend, where the failure mode is a dashboard you don’t control and a pricing tier that holds the fix.
Hand-written frameworks remain great tools — FastAPI is a fine way to write Python by hand. The difference is who does the labor, and who owns the result.
Frequently asked questions
Which AI agents work with jerrycan? Any coding agent that can work in a repo: Claude, Cursor, GitHub Copilot, Windsurf, Cline, Gemini and friends.
Do I have to review Rust code? You don’t have to — the compiler and framework defaults carry non-technical builders. You can, and that option is the point.
Can it handle real scale? Compiled Rust with a small footprint goes a very long way on ordinary hardware; you scale by upgrading your own server, not your pricing tier.
The fastest way to believe it is to watch it once. Pick something small you rent — your team chat is a good first target — and say the sentence.