What Is This?
A real home network, rendered as a solar system — built end-to-end by a team of AI agents in one afternoon.
The idea
Every device on a home Wi-Fi network is quietly orbiting the router: checking in, phoning home, leaking tracker requests. This page makes that visible. The data behind it is a live scan of an actual home network, baked down to an anonymised snapshot.
The whole system auto-fits your window — rendered as a printed instrument panel: the spacetime sheet dips where the Pi-hole sits, and the whole sky replays the last baked 24 hours. Drag the timeline to any moment. Scroll to zoom toward the sun, click a planet for its card (label, vendor, category, and when the router and Pi-hole have been consulted, current link TX/RX speed and DNS activity). The layout respects prefers-reduced-motion.
The privacy contract
This is the part of the brief that was non-negotiable: the public data file must never contain a MAC address, IP address, hostname, or family name. Three layers enforce it:
- Allowlist, not blocklist. The anonymiser builds each public device from an empty object — only vendor, category, a generic label, a flag, and a normalised size are ever copied in. Identifiers are used internally (to detect the gateway, to look up block counts) and then discarded.
- A hard-fail leak gate. Before anything is written,
leakCheckregex-scans the entire serialised JSON for MACs, IPs, and a list of forbidden names — and throws, killing the build, if anything matches. The tests deliberately try to smuggle data past it. - Agent isolation. The conductor agent that wrote this app never saw the raw scan. More on that below.
What you can see in network.public.json is the whole dataset: vendors, categories, sizes, synthetic ids like d7 — plus, when the bake had router and Pi-hole access, bare numbers for link speed and DNS counts and a connection type from a fixed four-value list. Free-form strings from the router never pass the gate; even the Wi-Fi band is re-mapped through a closed dictionary so an SSID can't hitch a ride. Nothing else survived the bake.
The brief
The build started as two documents in the repo: a design spec and a 15-task implementation plan with full test-first detail — written so that an agent could execute it task by task. The instruction given to the build agent was one sentence long: implement the plan, delegate the live scan to a separate Opus-model agent, and keep the privacy tests intact.
How it was orchestrated
The build ran inside Claude Code with Claude Fable 5 as the conductor. The conductor wrote almost no code itself. Instead it ran a subagent-driven development loop (from the open-source Superpowers plugin) — for every task:
- a fresh implementer agent (Claude Sonnet) got the task's full spec, followed strict test-driven development — failing test first, then code, then green — and committed;
- a spec-compliance reviewer verified the code against the plan line by line, explicitly told not to trust the implementer's report;
- a code-quality reviewer audited the diff for real defects;
- anything found went back to a fix agent, then re-verification.
By the numbers: 15 plan tasks, ~40 agent dispatches across four model tiers (Fable 5 conducting, Opus for the sensitive and final-review work, Sonnet for implementation and review, Haiku for trivial fixes), 27 tests, 22 commits, and one human decision point — the design call you can read about below.
The scan that the builder never saw
The live network scan is the privacy-critical moment: it produces a file full of real MACs, IPs and hostnames. So the conductor delegated it to a separate Claude Opus agent under a written contract: run the scan and the bake entirely in your own context, return only the leak-check verdict, the device count, and the path of the clean file. Raw data lives in a gitignored folder and never crossed back into the conductor's context — an information-flow boundary made of agent architecture, not just promises.
It mattered twice. The first bake came back 18-of-19 devices "unknown" — the plan's vendor lookup table was too small for the real network. A second Opus agent went back into the raw data alone, identified vendors from MAC prefixes, extended the lookup table (committing only 3-octet vendor prefixes, which identify manufacturers, not devices), and re-baked. Unknowns dropped to 10 — and the remaining 10 are genuinely unknowable randomised-MAC devices.
What the review gauntlet actually caught
The two-stage reviews weren't ceremony. Real catches, each fixed and re-verified:
- The plan's own privacy test was impossible to pass as written — its name-matching regex could never match the possessive in "Wyatts iPad". The implementer refused to weaken the test, escalated, and the gate was strengthened instead (leading-boundary matching: fail-closed beats precision).
- macOS prints MAC octets without leading zeros, which would have silently broken vendor lookup and let a malformed MAC slip past the leak gate's pattern. Caught in static review before the live scan ran.
- Sequential device ids hashed to nearly identical orbit angles — every planet would have clumped in a 10° wedge. Replaced with an FNV-1a hash.
- The comet was drawn but unclickable — no task in the plan produced a hit-target for it. Caught by a reviewer cross-referencing the acceptance criteria three tasks ahead.
- Shooting stars could only spawn from two of the four screen edges.
The one human decision
When the real data came back with ten flagged devices, the plan's "one dramatic comet" design collided with reality. The agents flagged the conflict instead of guessing; the human picked the fix: keep one comet, give the other unknowns their own honest slate-coloured outer ring.
The stack
| App | TypeScript, Vite, HTML5 Canvas 2D — no framework, ~7 kB of JS |
|---|---|
| Pipeline | tsx scripts: ARP scan + Pi-hole API → anonymise (allowlist) → leak-check → static JSON |
| Tests | Vitest, 27 tests, TDD throughout the pipeline and scene math |
| Agents | Claude Code · Fable 5 conductor · Opus scan/enrichment/final-review agents · Sonnet implementers & reviewers · Haiku fixers |
| Process | Superpowers plugin: written plan → subagent-driven development → two-stage review per task → publish gate before deploy |
| Hosting | Cloudflare Pages, fully static |
Why
This is a working demonstration of two things at once: that AI agents can take a written brief through plan, implementation, adversarial review, a privacy-isolated data pipeline and deployment with one human decision along the way — and that your home network has a story worth looking at.
It was built as part of Signal Over Noise, where Jim Christian writes about AI integration and knowledge management for humans who'd like to stay in the loop. If you want the longer version of builds like this one, the newsletter is the place.