rederive is live

Friday I wrote that "vibe" in AI code isn't a defect of the models — it's the leftover freedom in an underspecified problem, and that freedom is a dial you can turn down with a contract and an oracle the author can't game. I ended by saying we'd spent months turning that dial into infrastructure, and I'd tell you what it was this week.

It's called rederive. It's open source, it's live, and the idea underneath it is simple and a little uncomfortable.

The registry hands you bytes and a name to trust

Think about what you actually get when you npm install something. You get bytes, and a name. You don't audit the code — nobody does, at the scale of a real dependency tree. You trust that the name behind it is honest. Every supply-chain defense we've built in the last four years hardens that: 2FA, signed provenance, SLSA, reproducible builds, release cooldowns. They all verify where the bytes came from.

None of them verify what the bytes do. In January 2022 the maintainer of colors — 27 million weekly downloads — shipped an infinite loop into his own package, with his own valid credentials. Nothing was hacked. It would have passed provenance, signatures, and a reproducible-build check flawlessly, because the sabotage was the source. Four years and a monthly drumbeat of incidents later — Shai-Hulud, axios, LiteLLM — the trusted maintainer is still a single point of failure for everything downstream. The long version of that argument is here.

So ship the contract, not the bytes

A rederive package ships its contract: a structural spec, plus a held-out oracle — worked input→output cases stamped by executing the original code, which the shipped implementation has never seen. The oracle is published in full and is an independent source of truth no publisher — us included — can quietly move. You do one of two things with it:

• 1 Verify. rdv check re-runs the held-out oracle against the shipped code and checks its content hashes. Deterministic, local, free — no account, no network, no LLM. Tamper with a byte and it fails two ways at once: the behavior misses the oracle, and the hash mismatches.
• 2 Re-derive. Don't want to trust the shipped bytes at all? Rebuild the implementation locally from the spec — the exact loop from Friday's essay — accepted only when independent blind workers agree, and it must pass the same rdv check. The oracle is the trust anchor. Not the publisher, not us, not any model.

Three things you can run right now

$ npm i -g rederive

# verify a package against its contract — deterministic, offline
$ rdv check node_modules/@rederive/colors      → ✓ VERIFIED

# see what your dependency tree ACTUALLY pulls in
$ npx rederive audit
  you chose                 2 dependencies (+ 3 dev)
  npm delivered             650 packages
  install-time code rights  … packages carry postinstall hooks

That last one tends to stop people. You reviewed a handful of dependency choices; npm resolved a tree of hundreds on your behalf, every node of it installable code. rderive audit just makes the number visible.

Or don't run anything — ask your agent

Here's the part I'm most excited about. If you work with a coding agent — Claude Code, Cursor — you don't install or learn anything. You point it at the site and say what you want, in English:

# in your repo, to your agent:
  "This project has a boatload of dependencies I don't want to trust —
   apply rederive.ai to it."

The agent fetches rederive.ai, follows the setup prompt published there, and runs the whole loop with you: verify a package, re-derive a single dependency into a zero-dep vendored copy, or de-dependency an entire project — enumerate the runtime tree, re-derive each unit against its upstream, vendor the verified sources, and prove your own test suite still passes. The site was built to be read by an agent as readily as a human; the domain name is the interface. We've watched a cold agent do the full run on a real package from that one sentence, with no setup at all.

What's here today, honestly

The catalog stands at 218 verified, zero-dependency packages — three public in the repo today (colors, rdv, request), the rest rolling out — concentrated where the risk actually lives: the abandoned-but-load-bearing tail of npm that nobody audits and everybody ships. The SIR contract format is an open spec; the verifier is a few hundred lines of dependency-free Apache-2.0 code you can audit yourself. Everything load-bearing is Apache-2.0, with a written charter of what we will never do to the community.

It is not magic and I won't pretend it is. A held-out oracle is evidence of behavior, not a proof of total correctness — which is exactly why check is dual-channel, why catalog packages are zero-dependency by construction, and why re-derivation requires quorum. Smaller attack surface, honestly bounded.

This week I'm writing one post a day on what it actually does — starting tomorrow with the part that surprised me most: a real bug, in a package with millions of weekly downloads, that its own 97%-coverage test suite couldn't see.