Why a language, and not a TypeScript framework
Agents write backend code well. The problem is trusting it at the speed it arrives. Jadpo moves that trust into a compiler, and the price is a new language with no ecosystem.
The problem is trusting the code, not writing it
The usual process assumes a person writes the code and another person reads it. When an agent writes it instead, the rest of the process stays the same.
The usual loop
- The agent writes code
- The agent reviews its own code
- The agent may run a security check
- The agent judges its own findings
- A person skims a large pull request
- Ship
The same agent writes the code and the claim that it's safe.
With Jadpo
- You say what you want
- A strict language
- The agent writes it
- A check that gives the same answer every time
- An app you can run
The compiler's check sits between the agent and you.
A better AI model doesn't fix that. As the amount of code grows, nobody can read every line.
You review decisions, not every line
The compiler checks the rules, so you review only what a person must judge: what the app should do, who may see what, what happens to related records on a delete, and any exceptions you allow.
You read the diff, plus a report of who may do what that the compiler writes beside the code.
Who owns what
- You
Whether a route is public. Who may read or change which data. Whether a delete rejects, retains, anonymises or cascades. Which outside effects are acceptable. Any loosening of security.
- Your agent
Turns requirements into Jadpo, answers the compiler's errors and makes local choices inside what the language allows.
- The compiler
Refuses a program that breaks a rule. It sees routes, sign-in, queries, responses, where secrets go, failures, and which customer each record belongs to.
Every error says whether its next step is the agent's or a person's. So loosening a permission shows up as a decision, and the agent is told to ask you.
Why it has to be a language
Agent mistakes rarely sit in one layer. A route skips sign-in, which is fine for the router. A query returns another customer's row, which is fine for the query. A private field is sent, which is fine for the serialiser. Each layer passes. The bug is in how they connect.
A framework with lint rules checks each layer on its own, in a language that accepts anything that type-checks. Jadpo checks routes, queries, response fields, secrets, failures and which customer owns each record as one program. So it can refuse a program that would be valid TypeScript.
That works because Jadpo code has no raw SQL, no general HTTP client, no eval, no reflection and no hidden side effects. Each outside service is a typed package, so everything the app can reach is declared.
The reason for a language is the checks, not the native code or WebAssembly it compiles to. See a real refusal in policy.output_field_unproved.
What you give up
- Little or no training data
Jadpo is new and changes between versions, so models know little or nothing about it, and what they know may be out of date. The docs fill the gap: a primer, a step-by-step Learn path, a page for every compiler error, and a Markdown copy of each page. The measurement below is what will show whether that's enough.
- No ecosystem
There's no public package registry, and no libraries, tutorials or answers online.
- No way out to SQL or TypeScript
Real apps sometimes need raw SQL or a call to any HTTP address. Jadpo can't do either, and adding a way out isn't on the roadmap.
- One maintainer
Richard Willars builds and maintains it alone.
- Unmeasured against TypeScript
The test is written: 18 realistic changes, each given to fresh agent sessions in Jadpo and in TypeScript several times, and scored by tests the agents can't see. It measures whether the change is right, how many tries and tokens it took, where each mistake was caught, and how often an unsafe shortcut got through. The runs haven't been done, so there are no results yet. If Jadpo doesn't beat carefully written TypeScript, the results should say so quickly.
What the compiler can't guarantee
It targets mistakes that keep recurring: a route with no sign-in, one customer reading another's data, input nobody checked, queries that ignore the rules, private fields in responses, leaked secrets, calls to services nobody declared, forgotten transactions, and deletes that leave records behind. It doesn't make software correct.
- Requirements can be wrong.
- A policy a person approved can be wrong.
- Business logic can express the wrong rule.
- Providers and infrastructure can fail or be compromised.
- The compiler and runtime can have bugs.
- Some vulnerabilities fall outside what it models.
Not built yet
The compiler marks a loosened permission as your call, but it doesn't hold the change back until you accept it. Until it does, tell your agent to stop and ask you, as the prompt does.
There's no review that shows what a change loosened. Read the diff and the permissions report.
Is it right for you?
Read when to use Jadpo and when not to, or hand it to your agent.