The title is a big claim. Framework authors always think they built the last one and they are always wrong. So let me say exactly what I mean, because I mean something more specific than the title suggests:
jerrycan is built for the moment where humans stop picking backend frameworks. That moment is already happening.
Who picks your framework in 2026?
For thirty years frameworks won by convincing humans. Rails won with a 15 minute demo video. Django won with docs you could actually read. Express won by staying out of the way. The contest was always developer experience - how the thing feels in a human’s hands.
That contest is ending. When a founder wants software today, they ask an agent. The agent picks the stack. The human hears about the framework choice in one summary sentence, if at all. When a developer works with an agent it is softer but the same: the agent proposes, the human accepts.
So the question that decided thirty years of infrastructure - what does it feel like to write code in this - gets replaced by a different one:
What can an agent build in this correctly, on the first try, and still maintain six months later?
No framework was designed for that question. Including the ones agents pick today. They pick Express and FastAPI because that is what dominates the training data, not because a machine would choose them on merit. Training data gravity is the real incumbent we are up against. The only way past it is being measurably better for agents. Not vibes-better, measurably.
What agents actually need
I watched agents build backends end to end a few hundred times - that is where jerrycan comes from. Agents fail completely different than humans. They don’t get bored, they don’t typo, they don’t skip the docs. Instead:
- They hallucinate structure when structure is implicit. If the auth middleware usually goes in app/middleware but sometimes not, you built a coin flip.
- They drift between sessions. Agent A builds the users route, agent B builds billing three weeks later, and without enforced conventions the two halves disagree on everything from error shapes to naming.
- They can’t verify what they can’t measure. An agent that cannot mechanically check its own code will confidently ship the bug.
- They are exactly as secure as the defaults. A senior engineer brings paranoia into every review. An agent brings whatever paranoia the framework defaults encode and not one line more.
Flip every failure mode and you get the design brief. Call it AX, agent experience, the metric that replaces DX:
- Contracts, not conventions. The application is described in a machine readable design contract: routes, models, auth requirements, validation rules. Code gets generated from it. The agent diffs against a spec, not against folder folklore.
- One canonical shape. Everything has exactly one place. Boring for humans, deterministic for machines. Two agents on two routes produce code that looks like one author wrote it, because structurally one did: the generator.
- Verification built in. Generate, verify, package is the native loop. The framework ships the conformance checks. “The agent says it works” becomes “the verifier says it conforms.”
- Security as default, not discipline. Secure response headers, body limits, strict input handling and errors that never leak internals, out of the box. Unsafe code is forbidden across the entire framework. Auth ships in the box (sessions, JWT, OAuth2) and guards are dependencies the compiler can see: a missing guard dependency is a build error, not something a code review has to catch.
- You own the output. A single Rust binary that runs anywhere. Docker, a 4 euro VPS, Kubernetes, a Raspberry Pi. No platform sitting between you and your backend that can reprice you next quarter.
What jerrycan is, concretely
jerrycan is a Rust backend framework plus a generation platform, exposed as CLI and MCP server, so any agent drives it natively. Nine crates - core, auth, db, validation, jobs, rate limiting, observability - on hyper, tokio and SeaORM. The loop the agent drives is fixed:
design: the agent’s requirements become a validated design.json. Pointed questions, not guesses.scaffold: jerrycan generates a crate-per-module workspace with a working data layer and compiler-enforced module boundaries.gen-tests: jerrycan generates failing acceptance tests from the design. The agent never has to remember to write tests, they exist before the handlers do.- The agent implements the handler bodies. In practice that is a few lines of obvious glue per route.
check: build, clippy, audit, tests and jerrycan’s own lints, with machine readable diagnostics. Green means tested and safe.package: a static binary, a hardened container image, k8s manifests or a systemd unit, with an SBOM.
And the agent deploys it too. jerrycan deploy render writes a deploy kit
the agent executes against the Render API with nothing but an API key. From
design.json to a live URL with no human in the loop. Render is the first
target, more are coming, and self-hosters get the Docker, k8s and systemd
artifacts either way.
This is measured, not asserted. A docs-only agent, given nothing but
jerrycan docs - no framework source, no fixtures - built 5 out of 5
reference CRUD apps green on the first run, and a full multi-tenant SaaS
slice: auth, per-tenant isolation, signed webhooks, CSV import, scoped API
keys, OAuth, driven live over HTTP. A negative control that deliberately
breaks tenant scoping turns the gate red, so the green is not hollow. The
whole eval runs as an unskippable release gate in CI.
Routes are modular on purpose: the explicit design goal is multiple agents maintaining one codebase without stepping on each other. No framework before 2024 had a reason to contain that sentence.
Why Rust: if a machine writes your code, the compiler is your last line of defense that does not depend on a human. Rust catches at compile time what Express lets you find in production. And agents don’t pay the famous Rust learning curve - that difficulty just isn’t their problem. You get the memory safety and the single static binary, the agent takes the pain.
The honest part
You should know exactly what you would be adopting. jerrycan is at 0.2. The ecosystem is one developer and a fleet of agents. There is no decade of Stack Overflow answers and no plugin marketplace. It is built for CRUD-shaped, multi-tenant REST APIs - the backbone of most SaaS - and it does not do realtime, WebSockets, GraphQL or gRPC yet. If you love writing backends by hand, Rails and Django are still great and you should use them. If your agent needs some obscure integration today, FastAPI’s ecosystem carries further than we can right now. And the thesis could simply be too early - maybe framework choice stays human for another five years.
The bet is narrow and falsifiable: agents will increasingly pick infrastructure by measurable properties - one-shot buildability, verifiability, security defaults - and on those measurements we intend to win. The benchmark is next: same agent, same prompts, building the same secure backend on jerrycan and on the incumbents, hours and defect counts published. If we lose our own benchmark, you will read that here too.
Why “last”
Not the last framework ever. The last one built for humans arguing about frameworks - because after this, the choice belongs to a machine that reads contracts, runs verifiers and counts defects instead of GitHub stars.
Your agent can form its own opinion: point it at the docs,
there is an llms.txt waiting for it. Or give it cargo add jerrycan and one
prompt and look at what comes back.