Open source · AI code quality

wireline: find the code that's built but never wired

entry tests pass no edge in built · never wired
a green checkmark on an unreachable file is a lie about progress

AI coding agents have a signature failure. They write a module, it compiles, its unit tests pass, the diff looks great — and nothing in the running system ever calls it. The work exists; the feature doesn't. wireline is the open-source CI gate for exactly that lie.

Why: "done" and "wired" drifted apart

Humans forget to hook things up too. But agents do it at scale, and they do it while every signal says success. The file is there. The tests are green. The pull request reads like a finished feature. The one thing nobody checked is whether a single line in the live system reaches it. In an agent-driven workflow, that gap between "the agent says done" and "done" is the most expensive illusion you can ship, because it survives code review — the code is genuinely fine, it's just an island.

Inside Doric, where an agent team builds against a living spec, built-but-never-wired was our single most recurring failure. Recurring enough that the production system now gates "built" on reachability. wireline is that gate, generalised and pulled out.

What wireline is

wireline walks your real entry points — main, bin, and exports from package.json, plus anything you list — and computes what's provably reachable across both CommonJS and ES modules. Then it reports two different failure shapes. built-not-wired: source files no entry point reaches — work nobody can use. And unwired declared boundaries: things your manifest says should exist but that nothing connects to.

The declared half is the interesting one. After an agent builds a feature, you add one line naming the boundary it promised. wireline check then sorts every boundary into three honest states: ok (built and reachable), missing (spec'd, never built), unwired (built, but unreachable). That's the difference between a checkmark and a working feature.

How you use it

wireline scan reports unreachable source files. wireline check adds the declared boundaries and exits non-zero on findings, so it drops straight into CI as a gate. Two design choices keep it honest: files that use dynamic specifiers like require(someVar) are flagged opaque — wireline says it can't prove the closure rather than pretending — and tests deliberately don't count as wiring, because a test that exercises an orphan is exactly how unwired code hides.

Why it matters

As more of the diff is written by machines, the reviewer's hardest job shifts from "is this code correct?" to "is this code even connected?" The first has tools. The second didn't. wireline is a small, zero-dependency answer: a build that fails when built and wired stop being the same thing.

wireline is open source (MIT). npm install -g wireline  ·  github.com/Doric-builder/wireline

The family it belongs to

wireline is one of four tools pulled out of Doric's stack. Its sibling keepline keeps an AI honest about facts; plotline is the benchmark behind both; shipline deploys only what a change touches. The deeper architecture story is in why our agents run on real git branches and the map never lies.


← Back to all engineering notes

Make "done" mean wired.

View wireline on GitHub