AI-Driven Development
Three Open-Source Infrastructure Tools, Built With AI Coding Agents
nftably, birdy, and meerkat — a firewall UI, a BGP control plane, and an IDS console — shipped in about four months with agents doing most of the typing and humans owning every design and merge decision.
- Discipline
- AI-Driven Development
- Built
- Reading time
- 3 min read
- AI
- Agentic Development
- Open Source
- Go
Context
Between February and May 2026 we shipped three open-source infrastructure tools, each a single Go binary with an embedded web UI and a SQLite database, each designed to run on the box it manages:
nftably
— a web UI for nftables that manages the firewall as its real object model, applies changes atomically, and arms an auto-revert so a bad rule can't lock you out. (announcement)birdy
— a web UI for BIRD 2.x: BGP peers, policies, RPKI, and RTBH modelled in a database and rendered into the wholebird.conf, with the same armed-revert safety. (announcement)meerkat
— a console for Suricata whose home page is source addresses rolled up into decisions, not a scrolling wall of alerts. (announcement)
All three are 0BSD-licensed, packaged for Debian and Docker, and in production on our own AS210622 edge. And all three were built with AI coding agents doing most of the typing — this case study is the condensed version of the full write-up.
Constraints
A small team cannot hand-type three products' worth of CRUD layers, renderers, and UI plumbing in a quarter — and routing and firewall software carries a failure mode most software doesn't: the tool's own mistake can sever the connection used to fix it. So the constraint set was: agent-scale output, with human-owned safety semantics, and no shipping anything unread.
Approach
Every project follows the same workflow:
- A human-written PLAN.md before any code — architecture, data model, milestones, explicit non-goals. A design doc turns out to be a far better prompt than any conversation.
- Milestone gating — each milestone independently usable, unable to break what the previous one didn't touch. You trust the tool as a read-only viewer before it ever writes a config.
- Agents type, CI verifies, humans review — the agents produced the handlers, renderers, tests, Dockerfiles, systemd units, and packaging; every diff passed lint, tests, and a human reader before merging.
- Safety semantics stay human. The armed auto-revert, the explicit config-ownership model, birdy's refusal to render what looks like a route leak — those were design decisions made by people who have been locked out of remote boxes. The agents implemented them well; they did not propose them.
What was hard
Review became the bottleneck
When code generation is cheap, every hour moves to reading diffs. We learned to reject oversized diffs and re-specify rather than line-edit them — the discipline captured in our field guide to reviewing AI code.Plans diverge, and that's fine
birdy's original PLAN.md lists tables that were never built and omits features that shipped. We keep the plan as a record of intent, updated at the end of each session so the next one starts with real context, not archaeology.Honesty about maturity
Every README says "beta software, expect bugs," with explicit warnings about what each tool will overwrite. Agent-scale output does not shortcut the testing a piece of routing infrastructure deserves, and we won't pretend otherwise.
Where it stands
Three tools public, in production on our own network, and maintained — evidence, not a benchmark. The output scaled far beyond what this team types by hand, and it did so because design and review stayed human, not despite it. The engineering philosophy they share — local-first, single-binary, safety-armed — is written up in Tools That Run on the Router.
If you want this working model inside your team — the plans, the guardrails, the review discipline — we consult on exactly that.
Want one like this?
We build and run these ourselves. Tell us what you need and we will quote it.