![\"SMS](\"https://jonno.nz/img/posts/sms-gateway/screenshot.png\")
Anthropic just dropped Project Glasswing — a big collaborative cybersecurity initiative with a shiny new model called Claude Mythos Preview that can find zero-day vulnerabilities at scale. Twelve major tech companies involved. $100M in credits. Found a 27-year-old flaw in OpenBSD. Impressive stuff.
\nBut let's be real about what's happening here. Anthropic trained a model so capable at breaking into systems that they decided it was too dangerous to release publicly. So they wrapped the release in a collaborative security initiative. The security work is genuinely valuable. But it's also a smart way to keep control of something they know is too powerful to let loose.
\nThe part that actually matters, though, is who benefits. Glasswing is for the big players. The companies with security teams, budgets, and the kind of infrastructure that gets invited to sit at the table with AWS, Microsoft, and Palo Alto Networks. What about the rest of us? The startups, the small SaaS shops, the indie developers running production systems on a shoestring?
\nThe internet is a dark forest. That's not a metaphor anymore — it's becoming the literal reality. Bots, scrapers, automated exploit chains, credential stuffing, AI-generated phishing. A server goes up and within hours it's being scanned, fingerprinted, and probed by systems that don't sleep. Visibility equals vulnerability. And AI is making the attackers faster, cheaper, and more autonomous every month.
\nThe ISC2 put it plainly — both offence and defence now operate at speeds beyond human intervention. The threats aren't people sitting at keyboards anymore. They're autonomous systems running campaigns end-to-end.
\nSo what do we do about it?
\nWhen I say offensive security, I don't mean red-teaming or penetration testing. I mean giving your systems the ability to fight back.
\nPicture an LLM that sits across your centralised logs — network traffic, database queries, user interactions, access patterns — and builds an understanding of what normal looks like for your system over weeks and months. Not just pattern matching against known signatures. Actually understanding the shape of healthy behaviour.
\nWhen something breaks the pattern, it doesn't just alert. It acts.
\nDisable a compromised account. Kill a service that's behaving strangely. Block a database connection that shouldn't exist. Create an incident with full context for a human to review. The response is proportional and immediate — not waiting for someone to check their phone at 3am.
\nThe architecture is pretty straightforward:
\ngraph TD\n A[Application Logs] --> D[Secure Isolated Log Store]\n B[Network Traffic] --> D\n C[Database Queries] --> D\n D --> F[Baseline Health Model]\n E[User Activity] --> D\n F -->|Anomaly Detected| G[LLM Analysis]\n G -->|Analyse & Plan| H{Threat Assessment}\n H -->|Low| I[Alert & Log]\n H -->|Medium| J[Restrict & Escalate]\n H -->|High| K[Disable & Isolate]\n I --> L[Human Review]\n J --> L\n K --> L\nThe key is that the logging and analysis layer has to be isolated and secured separately from the systems it's watching. If an attacker can compromise the thing that's watching them, the whole model falls apart.
\nIn practice that means separate infrastructure with its own auth boundary. Ingestion is write-only — your application services push logs in but can never read or modify what's already there. Append-only, immutable. The analysis layer gets scoped service accounts that can read logs, fire alerts, and pull specific emergency levers through a narrow API. Nothing else. If a compromised service tries to reach the log store directly, it hits a wall.
\nNone of this is exotic. Centralised logging, immutable storage, scoped IAM — the building blocks exist. The hard part is wiring an LLM into that loop with the right constraints. Enough access to act, not enough to make things worse.
\nTraditional security tooling runs on signatures and static rules. Known bad patterns, blocklists, threshold alerts. That worked when threats were mostly human-paced. It doesn't work when you're up against autonomous systems that adapt faster than you can write rules.
\nThe alternative is a system that learns what normal looks like for your environment — not a generic baseline, but the actual shape of healthy behaviour in your specific infrastructure. Traffic patterns, query frequencies, access timing, user behaviour. Weeks of observation before it starts making decisions.
\nWhen something breaks the pattern, the response is proportional. A sudden spike in unusual API calls might trigger deeper correlation — the system widens its search, pulls in more signals, lowers its threshold for flagging related activity. Repeated failed auth attempts from new IPs tighten access controls automatically. A database connection that shouldn't exist gets killed.
\nThis isn't a static ruleset you configure once and hope covers everything. It's a system that develops behavioural intuition from running in your environment, responding to your traffic. The difference matters — static rules are brittle against novel attacks, while adaptive systems can catch anomalies they've never seen before.
\nThe baseline isn't magic. It's watching five things:
\nThree layers of detection stack on top of each other. Layer one is simple thresholds — hard caps that trigger immediately. Layer two is statistical deviation — standard deviations from the learned baseline. Layer three is correlation — looking across multiple signals simultaneously. A spike in rate alone might be fine. A spike in rate plus unusual composition plus new source IP? That's a pattern.
\nA pure anomaly detector would go nuts during deploys. New code paths, changed response times, config reloads — all of it looks unusual. Same with cron jobs. Your 3am batch job that hits the database hard every night would trigger alerts every night.
\nTolerance patterns solve this. The system learns to recognise you.
\nMark a deploy event, and the system creates a tolerance window — elevated thresholds for the next 30 minutes. Register a recurring cron job, and the system expects that exact spike at that exact time. These aren't exceptions you configure manually. They're patterns the system learns from watching.
\nAfter a few weeks, it knows when your weekly cache warm-up runs, when your daily reports generate, when deploys happen. It stops bothering you about the things you do on purpose.
\nCalling an LLM for every anomaly would be expensive. The trick is building immune memory.
\nWhen the LLM analyses an anomaly and decides it's benign — say, a deploy spike or a legitimate traffic surge — that verdict gets stored. Next time the same pattern appears, the system recognises it. No LLM call needed.
\nThis is how your security bill drops over the first few weeks. Early on, everything is novel. The LLM gets called constantly. A month in, most anomalies match patterns it's already seen. The LLM only gets called for genuinely new situations.
\nThe more your system runs, the smarter it gets and the less it costs.
\nThe hardest part of any security tool is configuration. Getting thresholds right. Understanding your traffic patterns before you can tell the tool what's normal.
\ndarkforest init flips this. Point it at a log sample — a day's worth of traffic, a week if you've got it — and Claude reads it. Not just parsing, actually understanding the shape of your system. It figures out what your endpoints are, what normal request rates look like, what user agents show up, where your traffic comes from geographically.
Then it writes your config file for you.
\nYou review it, tweak anything that looks wrong, and you're running. No spreadsheets. No guesswork about what "normal" means for your specific stack. The LLM that's going to watch your logs already understands them.
\nGlasswing is cool. Open-source frameworks like CAI are making progress — but mostly on the offensive side, using LLMs for penetration testing and vulnerability research. On the defensive side, the tooling barely exists. There's no open-source equivalent for the kind of adaptive monitoring and response I'm describing here.
\nThe building blocks are around. Centralised logging is a solved problem. Open standards for security event formats are maturing. Smaller open models are more than capable of pattern analysis on local infrastructure. What's missing is the glue — a framework that takes logs in, builds a baseline, detects anomalies, and can actually respond. Something a small team can deploy without a six-figure security budget.
\nThe threats don't discriminate by company size. The defences shouldn't either. This can't be proprietary or locked behind enterprise contracts.
\nThe dark forest doesn't care how big your company is. The bots scanning your infrastructure don't check your headcount before they attack. If the threats are going to be this accessible, the defences need to be too.
\nI'm building this. An open-source security agent — adaptive, autonomous, acts when something breaks the pattern. Small enough for a startup to run on their own infrastructure. Centralised logging, open LLMs, scoped response actions. The pieces are all there. I'm wiring them together now.
\nFor v0.1, one real action working end-to-end: detect anomalous authentication patterns, call the LLM for analysis, and disable the compromised account via your identity provider's API. Not just alerting — actually responding while you're asleep. That's the proof of concept that matches the headline.
\nI'm actively working on this and looking for early testers. If you want alpha access when it's ready, or just want to follow along, drop your email below. I'll reach out when there's something to try.
\n","date_published":"Sat, 11 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/llm-kills-compromised-services-at-3am.png"},{"id":"https://jonno.nz/posts/booting-a-vm-in-4-seconds-and-talking-to-it-without-a-network/","url":"https://jonno.nz/posts/booting-a-vm-in-4-seconds-and-talking-to-it-without-a-network/","title":"Booting a VM in 4 Seconds and Talking to It Without a Network","content_html":"The first time I got a Firecracker VM to boot and respond to a vsock ping from the host, I sat there grinning like an idiot. Typed a command on my machine, it reached through a kernel-level socket into a completely separate Linux system with its own kernel, and got a reply. Under a second.
\nThat was about 30 hours into the project. The previous 29 were mostly fighting with rootfs images and iptables rules.
\nPart 1 covered why I built this — Firecracker MicroVMs for running Claude Code in full-permission isolation. This post is the actual build. Rootfs, networking, the guest agent, and the streaming pipeline.
\nA Firecracker VM needs two things: an uncompressed Linux kernel (vmlinux, not bzImage — there's no bootloader) and an ext4 filesystem image to use as the root disk.
The kernel is straightforward — grab a prebuilt 6.1 LTS vmlinux. The rootfs took more work.
\nIt's a standard ext4 image with Debian Bookworm, and it needs everything Claude Code might want: Node.js 24, Python 3.11, Chromium for browser automation, git, curl, jq, and the full Claude Code CLI installed globally via npm. The image ends up at about 4GB.
\nThe guest agent — the Go binary that listens for commands from the host — lives inside the rootfs as a systemd service:
\nsudo mount /opt/firecracker/rootfs/base-rootfs.ext4 /mnt\nsudo cp bin/agent /mnt/usr/local/bin/agent\nsudo chmod +x /mnt/usr/local/bin/agent\n\nsudo tee /mnt/etc/systemd/system/agent.service <<'EOF'\n[Unit]\nDescription=Orchestrator Guest Agent\nAfter=network.target\n\n[Service]\nType=simple\nExecStart=/usr/local/bin/agent\nRestart=always\nRestartSec=1\n\n[Install]\nWantedBy=multi-user.target\nEOF\n\nsudo chroot /mnt systemctl enable agent.service\nsudo umount /mnt\nThat RestartSec=1 matters. If the agent crashes for any reason, systemd has it back up in a second. The orchestrator polls vsock every 500ms waiting for the agent, so even a crash during boot is barely noticeable.
You build this rootfs once, by hand. Every new VM gets a sparse copy of it.
\ninternal/vm/manager.go handles the whole lifecycle. It's sequential with cleanup at each step — if anything fails, it tears down what it already set up and returns the error.
flowchart TD\n A["Copy rootfs (sparse)"] --> B["Mount & inject network config"]\n B --> C["Create TAP device"]\n C --> D["Add iptables rules"]\n D --> E["Setup jailer chroot"]\n E --> F["Write Firecracker config JSON"]\n F --> G["Launch via jailer --daemonize"]\n G --> H["Find PID, save metadata"]\n H --> I["VM ready — poll vsock"]\nThe sparse copy is the first thing that happens:
\ncmd := exec.Command("cp", "--sparse=always", BaseRootfs, vm.RootfsPath)\n--sparse=always means zero blocks aren't allocated on disk. A 4GB image might only use 2GB of actual disk space. Takes under a second on NVMe.
After copying, the rootfs gets mounted and three files are injected: a systemd-networkd config with a static IP, /etc/resolv.conf for DNS, and /etc/hostname. Then it's unmounted and copied again into the jailer chroot.
Yeah, that's two copies of the rootfs per VM. The first for network injection, the second because the jailer expects everything inside its chroot. I could collapse this into one copy by injecting the network config directly into the chroot copy, but it's never been a bottleneck — sparse copy of 4GB takes less time than Firecracker takes to boot. So I left it.
\nFirecracker's jailer is a separate binary that creates a chroot, sets up minimal /dev entries (kvm, net/tun, urandom), and runs the Firecracker process inside it. The VM config is a JSON file:
vmConfig := map[string]interface{}{\n "boot-source": map[string]interface{}{\n "kernel_image_path": "/vmlinux",\n "boot_args": "console=ttyS0 reboot=k panic=1 pci=off init=/sbin/init",\n },\n "drives": []map[string]interface{}{{\n "drive_id": "rootfs",\n "path_on_host": "/rootfs.ext4",\n "is_root_device": true,\n "is_read_only": false,\n }},\n "machine-config": map[string]interface{}{\n "vcpu_count": vm.VCPUs,\n "mem_size_mib": vm.RamMB,\n },\n "network-interfaces": []map[string]interface{}{{\n "iface_id": "eth0",\n "guest_mac": "06:00:AC:10:00:02",\n "host_dev_name": netCfg.TapDev,\n }},\n "vsock": map[string]interface{}{\n "guest_cid": vm.VsockCID,\n "uds_path": "/vsock.sock",\n },\n}\npci=off because Firecracker doesn't emulate PCI. Paths are relative to the jailer chroot. The vsock entry creates a Unix domain socket at /vsock.sock inside the chroot — that's how the host talks to the guest.
Launch looks like this:
\ncmd := exec.Command(JailerBin,\n "--id", vm.JailID,\n "--exec-file", FCBin,\n "--uid", "0", "--gid", "0",\n "--cgroup-version", "2",\n "--daemonize",\n "--",\n "--config-file", "/vm-config.json",\n)\ncmd.Run()\nAfter launch there's a 2-second sleep — Firecracker needs a moment to start — then the PID is found via pgrep and saved to a metadata file. If the orchestrator restarts, it reads these metadata files and picks up where it left off. VMs survive orchestrator crashes.
This is where I burned the most time. Not because the concepts are hard, but because of one specific bug that had me questioning reality.
\nEach VM needs internet access for Claude Code to fetch packages, clone repos, and hit the Anthropic API. The approach: each VM gets a Linux TAP device on the host, a dedicated /24 subnet, and iptables rules for NAT.
Subnets are deterministic, derived from the VM name using FNV-1a hashing:
\nfunc NetSlot(name string) int {\n h := fnv.New32a()\n h.Write([]byte(name))\n return int(h.Sum32()%253) + 1\n}\nVM named task-a3bfca80 might hash to slot 61, giving it subnet 172.16.61.0/24, guest IP 172.16.61.2, TAP IP 172.16.61.1. No coordination needed, no DHCP server, no IP pool to manage. The collision space is 253 slots — more than enough for 12-13 concurrent VMs.
A TAP device is a virtual ethernet interface. Firecracker attaches the guest's eth0 to it.
tap := &netlink.Tuntap{\n LinkAttrs: netlink.LinkAttrs{Name: cfg.TapDev},\n Mode: netlink.TUNTAP_MODE_TAP,\n}\nnetlink.LinkAdd(tap)\naddr, _ := netlink.ParseAddr(cfg.TapIP + "/24")\nlink, _ := netlink.LinkByName(cfg.TapDev)\nnetlink.AddrAdd(link, addr)\nnetlink.LinkSetUp(link)\nTAP names are fc-<vm-name>, truncated to 15 characters because Linux interface names can't be longer. A fun constraint to discover at runtime.
Three rules per VM:
\n// NAT — rewrite source IP when traffic exits the host\nipt.AppendUnique("nat", "POSTROUTING",\n "-s", cfg.Subnet, "-o", cfg.HostIface, "-j", "MASQUERADE")\n\n// FORWARD — allow outbound from TAP\nipt.Insert("filter", "FORWARD", 1,\n "-i", cfg.TapDev, "-o", cfg.HostIface, "-j", "ACCEPT")\n\n// FORWARD — allow established/related inbound\nipt.Insert("filter", "FORWARD", 1,\n "-i", cfg.HostIface, "-o", cfg.TapDev,\n "-m", "state", "--state", "RELATED,ESTABLISHED", "-j", "ACCEPT")\nSee those Insert calls with position 1? That's the bug fix.
I originally used Append for the FORWARD rules. Traffic from the VM would leave the host fine (NAT worked), but return traffic got dropped. The VM could resolve DNS but couldn't complete TCP handshakes. I spent an embarrassing amount of time staring at tcpdump output before I figured it out.
Ubuntu's UFW adds a blanket DROP rule to the FORWARD chain. If you append your ACCEPT rules, they land after UFW's DROP. They never match. The packets hit the DROP rule first and get silently killed.
Insert at position 1 puts the rules before UFW's. Return traffic flows, VMs get internet access, everything works.
The traffic path through a working VM:
\nGuest (172.16.61.2) → eth0 → TAP (fc-task-xxx) → FORWARD ACCEPT\n→ NAT MASQUERADE (rewrite src to host IP) → host interface → internet\n→ response → RELATED,ESTABLISHED → TAP → guest eth0\nVMs can't reach each other. Each TAP device is point-to-point on its own /24. There's no route between subnets.
cmd/agent/main.go — 420 lines of Go. It's a static binary that starts on boot, listens on vsock port 9001, and handles five request types: ping, exec, write_files, read_file, and signal.
The interesting one is streaming exec.
\nWhen the orchestrator wants to run Claude Code, it sends an exec request with stream: true. The agent spawns the command, reads stdout and stderr line by line, and sends each line back as a framed event over the vsock connection. When the process exits, it sends an exit event with the exit code.
Sounds straightforward. The tricky part is background processes.
\nClaude Code can start things that outlive the main command — dev servers, file watchers, whatever it decides it needs. These child processes inherit the stdout/stderr pipes. If the agent waits for the pipes to close (the normal approach), it hangs forever because the children are still holding them open.
\nThe fix has three parts:
\n// 1. Process group isolation\ncmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}\n\n// 2. Wait for the main process, not the pipes\n<-waitDone\n\n// 3. Kill the entire process group\npgid, _ := syscall.Getpgid(cmd.Process.Pid)\nsyscall.Kill(-pgid, syscall.SIGTERM)\ntime.Sleep(500 * time.Millisecond)\nsyscall.Kill(-pgid, syscall.SIGKILL)\nSetpgid: true puts the command in its own process group. When the main process exits, kill the group (-pgid means "everything in this group"). SIGTERM first, wait half a second, then SIGKILL for anything that didn't listen.
Even after killing the group, there's a 3-second timeout waiting for the pipe-reading goroutines to drain. If they're still stuck after that, move on and send the exit event anyway. Can't let a hung pipe block the entire task.
\nThe line-by-line reader uses a 256KB buffer because Claude Code's --output-format stream-json can produce enormous single lines — tool results that include the full contents of files it read.
Before Claude Code runs, the orchestrator writes five things into the VM via vsock:
\nOAuth credentials from the host's ~/.claude/.credentials.json (mode 0600). A settings file that allows all tools. An environment script that sets CLAUDE_DANGEROUSLY_SKIP_PERMISSIONS=true. Task metadata. And a marker file to create the output directory.
The prompt itself gets written to a temp file inside the VM to avoid shell escaping nightmares, then referenced in the command:
\nclaudeArgs := fmt.Sprintf(\n "claude -p \\"$(cat %s)\\" --output-format stream-json --verbose",\n promptFile,\n)\ncmd := []string{"bash", "-c",\n "source /etc/profile.d/claude.sh && " + claudeArgs}\nWhen the VM is destroyed, the rootfs — containing the credentials — is deleted. Credentials only exist for the lifetime of the task.
\nAfter Claude Code finishes, the orchestrator searches for files it created:
\n// Anything in the output directory\nvsock.Exec(jailID, []string{"find", outputDir, "-type", "f", "-not", "-name", ".keep"}, nil, "/root")\n\n// Any new files under /root, created after the prompt was written\nvsock.Exec(jailID, []string{"find", "/root", "-maxdepth", "2", "-type", "f",\n "-newer", "/tmp/claude-prompt.txt"}, nil, "/root")\nEach file gets downloaded via vsock.ReadFile and saved to /opt/firecracker/results/<task-id>/. The runner also scans the accumulated output for Claude's total_cost_usd field to record what the task cost in API credits.
Then the VM is destroyed. Firecracker process killed, TAP device removed, iptables rules deleted, jailer chroot deleted, VM state directory deleted. Clean slate.
\nThe whole cycle — boot, inject, run, collect, destroy — typically takes 30-120 seconds depending on how complex the prompt is. The 4-second boot and ~1-second teardown are rounding errors compared to the time Claude actually spends thinking.
\nPart 3 gets into the fun stuff — the MCP server that lets Claude delegate tasks to itself, the streaming architecture, the web dashboard, and what productionising this would actually look like.
\n","date_published":"Fri, 10 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/booting-a-vm-in-4-seconds-and-talking-to-it-without-a-network.png"},{"id":"https://jonno.nz/posts/can-you-beat-last-month/","url":"https://jonno.nz/posts/can-you-beat-last-month/","title":"Can You Beat Last Month? — Part 5: Baseline Models","content_html":"Every machine learning project needs a reality check.
\nIt's tempting to jump straight to the neural network — that's the exciting bit, right? But if you don't establish what a dead-simple model can do first, you've got no idea whether your fancy architecture is actually learning anything useful or just being expensive.
\nSo before ConvLSTM gets anywhere near this data, we're going to throw three gloriously simple baselines at it and see how they do.
\nThe dumbest possible model. To predict April, just use March's values. Every cell, every crime type — carbon copy.
\nIt sounds ridiculous, but it works surprisingly well when patterns are stable. And as we saw in the EDA, Auckland's crime hotspots are remarkably persistent. The CBD doesn't suddenly go quiet. South Auckland doesn't randomly calm down.
\nOn the six-month test set (August 2025 – January 2026):
\n| Crime Type | \nMAE | \nRMSE | \n
|---|---|---|
| Theft | \n1.42 | \n3.18 | \n
| Burglary | \n0.38 | \n0.91 | \n
| Assault | \n0.22 | \n0.64 | \n
| Robbery | \n0.04 | \n0.15 | \n
| Sexual | \n0.03 | \n0.12 | \n
| Harm | \n0.01 | \n0.04 | \n
Those MAE numbers for theft and burglary look small until you remember that most cells are zero. For the active cells — the ones we actually care about — the error is larger. A busy CBD cell might have 35 thefts in one month and 28 the next. Persistence would be off by 7 there, which is a 20% miss on an important prediction.
\nInstead of copying last month, copy the same month from the previous year. January 2026 gets predicted from January 2025. This should capture seasonal patterns — the summer spike, the February dip.
\nThe catch? We only have four years of data. The test set months (August–January) each have at most three prior examples of the same month. That's not a lot of seasonal training data.
\n| Crime Type | \nMAE | \nRMSE | \n
|---|---|---|
| Theft | \n1.51 | \n3.42 | \n
| Burglary | \n0.41 | \n0.97 | \n
| Assault | \n0.24 | \n0.68 | \n
| Robbery | \n0.05 | \n0.17 | \n
| Sexual | \n0.04 | \n0.13 | \n
| Harm | \n0.01 | \n0.04 | \n
Slightly worse than persistence across the board. That surprised me initially — shouldn't capturing seasonality help?
\nThe issue is that the 2023-to-2025 decline we spotted in the EDA bites hard here. If you predict January 2026 from January 2025, you're using data from a period when crime was higher. The seasonal pattern is real, but the year-over-year trend works against it. With more years of data, seasonal naive would likely pull ahead.
\nFor each cell and crime type, take the average across all 36 training months. This smooths out month-to-month noise and gives you a "typical" value for each location.
\n| Crime Type | \nMAE | \nRMSE | \n
|---|---|---|
| Theft | \n1.28 | \n2.95 | \n
| Burglary | \n0.35 | \n0.84 | \n
| Assault | \n0.20 | \n0.58 | \n
| Robbery | \n0.04 | \n0.14 | \n
| Sexual | \n0.03 | \n0.11 | \n
| Harm | \n0.01 | \n0.04 | \n
The best baseline. By averaging over three years, it smooths out the month-to-month noise and the year-over-year trend simultaneously. It won't capture seasonal peaks or sudden changes, but for the "typical month" prediction it's solid.
\nYou might wonder why I'm not reporting MAPE (Mean Absolute Percentage Error) — it's the standard metric in a lot of forecasting work. The reason: sparse data.
\nMAPE divides the error by the actual value. When the actual value is zero — which it is for 91.7% of our tensor — you get division by zero. Even for cells with small counts (1 or 2 crimes), a prediction of 0 gives you 100% MAPE while a prediction of 2 gives you 0–100%. The metric becomes wildly unstable.
\nMAE and RMSE are more honest here. They tell you the absolute magnitude of your errors in actual crime counts, which is what we care about. A miss of 3 victimisations means the same thing whether the cell usually has 5 or 50.
\nHere's the scoreboard going forward. Any deep learning model needs to beat the historical average baseline to justify its existence:
\n| Crime Type | \nHistorical Avg MAE | \nHistorical Avg RMSE | \n
|---|---|---|
| Theft | \n1.28 | \n2.95 | \n
| Burglary | \n0.35 | \n0.84 | \n
| Assault | \n0.20 | \n0.58 | \n
| All types | \n0.39 | \n0.95 | \n
Theft is the easiest to beat because there's the most signal — high counts, clear spatial patterns, strong seasonality. Robbery, sexual offences, and harm are essentially noise at this resolution. The models will probably predict near-zero for those types and be mostly correct.
\nThe real test will be the middle ground — can ConvLSTM or ST-ResNet predict the changes in theft and burglary better than a static average? Can they catch the months where a cell spikes or dips? That's where simple baselines fall flat, because they don't model dynamics at all.
\nIf the deep learning can't meaningfully beat "just use the average," then it's not worth the CPU cycles. Or in my case, the many hours of a Ryzen 5 grinding away.
\n","date_published":"Thu, 09 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/can-you-beat-last-month.png"},{"id":"https://jonno.nz/posts/i-built-anthropics-internal-sandbox-platform-on-a-single-linux-box/","url":"https://jonno.nz/posts/i-built-anthropics-internal-sandbox-platform-on-a-single-linux-box/","title":"I Built Anthropic's Internal Sandbox Platform on a Single Linux Box","content_html":"Running Claude Code with full permissions inside a Docker container is a terrible idea. I did it anyway for about a week, then built something better.
\nAnthropic has an internal platform — people have been calling it Antspace since it got reverse-engineered from the Claude Code source — that runs AI coding tasks in isolated environments. It's part of a vertical stack they're building internally: intent goes in, code comes out, and the agent never touches the host machine.
\nI wanted that. Not the whole platform-as-a-service thing, just the core idea: give Claude Code a prompt, let it run with zero permission restrictions, stream the output back, grab any files it created, and destroy everything when it's done. On a single Linux box sitting in my office.
\nThe result is about 3,200 lines of Go and 860 lines of TypeScript. It boots a fresh Linux VM in ~4 seconds, runs Claude Code inside it, and tears it down when the task finishes. Three ways to use it: a CLI, a REST API with a web dashboard, and an MCP server so Claude Code on other machines can delegate tasks to it.
\nThis first post is about why I built it this way. Parts 2 and 3 get into the actual implementation.
\nCLAUDE_DANGEROUSLY_SKIP_PERMISSIONS=true — that's the environment variable that tells Claude Code to stop asking before it runs shell commands or writes files. It just does whatever it thinks it needs to. For autonomous tasks, you need this. Claude can't ask for confirmation when there's nobody watching.
The question is where you let it run.
\nDocker is the obvious first thought. Fast startup, everyone knows it, easy to orchestrate. But containers share the host kernel. Every container on the machine issues syscalls to the same Linux kernel, and a kernel vulnerability is a vulnerability in every container on the host. The isolation boundary is the container runtime, not hardware — and that surface area is big.
\nFor most workloads this is fine. Running a web server in Docker? No worries. But running an AI agent that can execute arbitrary shell commands with root-level permissions? That's a different threat model. A container escape gives you the host. And you've just given the thing inside the container permission to try anything.
\nAnthropic's own approach to sandboxing Claude Code uses OS-level primitives — bubblewrap on Linux, Seatbelt on macOS — for filesystem and network isolation. They report an 84% reduction in permission prompts internally. That's smart for the normal use case where Claude is helping you write code in your own project. But I wanted something more aggressive: full isolation where even a kernel exploit can't reach the host.
\nFirecracker is what AWS built for Lambda and Fargate. Each MicroVM is a real KVM-backed virtual machine with its own guest kernel, its own memory space, and hardware-enforced isolation via Intel VT-x or AMD-V. The attack surface is the KVM hypervisor — which the kernel team at AWS has spent years minimising.
\nThe trade-off is boot time. Containers start in under a second. Firecracker VMs take about 4 seconds on my hardware once you account for the guest kernel boot, systemd init, and the agent process starting up. For tasks that typically run 20-120 seconds, 4 seconds of overhead is nothing.
\nEach VM also copies a 4GB rootfs image. Sparse copies make this fast (<1 second), but it does use disk. On a machine with a 1TB NVMe, I'm not losing sleep over it.
\nThe hardware is an AMD Ryzen 5 5600GT with 30GB of RAM. Nothing exotic. About $400 worth of parts sitting under my desk. Each VM gets 2GB of RAM by default, so I can run roughly 12-13 VMs concurrently before the host runs out of memory.
\nThis was my favourite bit to figure out.
\nThe obvious way to communicate with a process inside a VM is SSH. Set up keys, open a port, connect over the network. But SSH means key management, an open network port inside the VM, and another service to configure. If the guest's network breaks during a task, you've lost your control channel.
\nvsock (AF_VSOCK, address family 40) is a kernel-level host-guest communication channel. It doesn't touch the network stack. No IP addresses, no ports, no keys. Firecracker exposes the guest's vsock as a Unix domain socket on the host side — you connect to the socket, send CONNECT <port>\\n, and you're talking directly to a process inside the VM.
func Connect(jailID string, port int) (net.Conn, error) {\n socketPath := fmt.Sprintf("/srv/jailer/firecracker/%s/root/vsock.sock", jailID)\n conn, _ := net.Dial("unix", socketPath)\n conn.Write([]byte(fmt.Sprintf("CONNECT %d\\n", port)))\n // Read "OK <port>" response\n return conn, nil\n}\nOn the guest side, Go's standard library doesn't support AF_VSOCK — address family 40 doesn't exist in the net package. So the guest agent uses raw syscalls:
fd, _ := syscall.Socket(40, syscall.SOCK_STREAM, 0) // AF_VSOCK = 40\n// Manually construct struct sockaddr_vm (16 bytes)\nsa := [16]byte{}\n*(*uint16)(unsafe.Pointer(&sa[0])) = 40 // family\n*(*uint32)(unsafe.Pointer(&sa[4])) = uint32(port) // port (9001)\n*(*uint32)(unsafe.Pointer(&sa[8])) = 0xFFFFFFFF // VMADDR_CID_ANY\nsyscall.RawSyscall(syscall.SYS_BIND, uintptr(fd), uintptr(unsafe.Pointer(&sa[0])), 16)\nsyscall.RawSyscall(syscall.SYS_LISTEN, uintptr(fd), 5, 0)\nYeah, that's unsafe.Pointer and manual struct layout. Not the prettiest Go you'll ever write. But it works, it's fast, and the whole vsock layer is about 160 lines shared between both binaries.
The wire protocol is dead simple — length-prefixed JSON frames:
\nfunc WriteFrame(w io.Writer, v interface{}) error {\n data, _ := json.Marshal(v)\n binary.Write(w, binary.BigEndian, uint32(len(data)))\n w.Write(data)\n return nil\n}\nEach operation (ping, exec, write files, read file) opens a new connection, sends one request, reads the response, and closes. Connection-per-request. Not fancy, but vsock connections are local and effectively instant, so there's no reason to complicate things with multiplexing.
\nThe whole system is two Go binaries — the orchestrator (runs on the host) and the agent (runs inside each VM).
\ngraph TD\n subgraph "Host — orchestrator binary"\n API["REST API + WebSocket :8080"]\n MCP["MCP Server :8081"]\n VM["VM Manager"]\n NET["TAP + iptables"]\n TASK["Task Runner"]\n STREAM["Pub/Sub Hub"]\n VSOCK["vsock Client"]\n end\n\n subgraph "Guest — agent binary"\n AGENT["Guest Agent vsock:9001"]\n CLAUDE["Claude Code"]\n end\n\n API --> TASK\n MCP --> TASK\n TASK --> VM\n VM --> NET\n TASK --> VSOCK\n VSOCK --> AGENT\n AGENT --> CLAUDE\n TASK --> STREAM\n STREAM --> API\nThe orchestrator is a single 14MB binary with the React dashboard embedded via //go:embed. Copy it to a server, run it with sudo, done. Seven Go dependencies total — chi for routing, netlink for TAP devices, go-iptables for firewall rules, mcp-go for the MCP protocol, and a few others.
The agent is a 2.5MB static binary compiled with CGO_ENABLED=0. It ships inside the VM's rootfs and starts via systemd on boot. Within about a second of the VM coming up, the agent is listening on vsock port 9001 and ready to accept commands.
They share exactly one file — internal/agent/protocol.go — which defines the wire protocol types and framing functions. Everything else is independent.
You give it a prompt. It does the rest.
\nFrom the CLI it looks like this:
\nsudo ./bin/orchestrator task run \\\n --prompt "Write a Python script that generates Fibonacci numbers" \\\n --ram 2048 \\\n --vcpus 2 \\\n --timeout 120\nOutput streams to your terminal in real time. When it's done:
\n=== Task Complete ===\nID: a3bfca80\nStatus: completed\nExit: 0\nCost: $0.0582\nFiles: [fibonacci.py]\nThe VM is gone. The rootfs is deleted. The TAP device and iptables rules are cleaned up. All that's left is the result files in /opt/firecracker/results/a3bfca80/.
Or you use the MCP server, and Claude Code on your laptop delegates the task to a VM on the box under your desk. Claude spawning Claude. That bit is properly cool, and I'll get into it in Part 3.
\nQuick aside on this because people always ask.
\nGo produces static binaries. The agent needs to be a single file with zero dependencies that runs inside a minimal Debian guest — CGO_ENABLED=0 makes this trivial. The orchestrator needs to manage concurrent VMs, and goroutines are a natural fit for that. Syscall support is first-class, which matters when you're doing raw vsock operations. And it compiles in about 2 seconds, which is nice when you're iterating.
build-agent:\n\tCGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/agent -ldflags="-s -w" ./cmd/agent\nThat -ldflags="-s -w" strips debug info and DWARF tables, dropping the agent binary from ~3.5MB to ~2.5MB. Every byte counts when you're baking it into a rootfs that gets copied for every VM.
Part 2 gets into the actual build — the rootfs, the networking (including a fun bug with Ubuntu's UFW that had me staring at iptables rules for an embarrassing amount of time), the guest agent, and the streaming pipeline that gets Claude's output from inside a VM to your browser.
\n","date_published":"Wed, 08 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/i-built-anthropics-internal-sandbox-platform-on-a-single-linux-box.png"},{"id":"https://jonno.nz/posts/stealing-nanoclaw-patterns-for-webapps-and-saas/","url":"https://jonno.nz/posts/stealing-nanoclaw-patterns-for-webapps-and-saas/","title":"Stealing NanoClaw Patterns for Web Apps and SaaS","content_html":"In Part 1 I pulled apart NanoClaw's codebase and found six patterns that make an 8,000-line AI assistant surprisingly robust. But NanoClaw is a single-user tool running on your laptop. Surely these patterns fall apart once you've got real tenants, real money, and real scale?
\nNah. Four of them translate almost directly — and the ones that don't still teach you something useful.
\nNanoClaw's credential proxy — where containers get a placeholder API key and a localhost proxy injects the real one — sounds like a neat trick for a personal tool. But this exact pattern is showing up in production Kubernetes deployments right now.
\nThe broader version is a sidecar proxy that handles credential injection for any service that needs API keys or tokens. Your application code never touches the real secret. A sidecar container intercepts outbound requests, swaps in credentials, and forwards them upstream.
\nAt Vend we managed a bunch of third-party integrations — payment gateways, shipping providers, accounting platforms. Each one had API keys that needed to live somewhere. We went through the typical evolution: environment variables, then a secrets manager, then a service that distributed keys at startup. Every step was an improvement, but the keys still ended up in the application's memory.
\nThe sidecar approach skips that entirely. Your app sends requests with a placeholder. The proxy — which is a separate process with its own security boundary — does the credential swap. Even if your application gets compromised, the real keys aren't there to steal.
\nIf you're running any kind of multi-service architecture where services call external APIs, this pattern is worth adopting. Your API gateway might already be doing a version of it — the insight is making it explicit and consistent across all outbound credential flows.
\nThis is the one I keep thinking about.
\nNanoClaw uses filesystem mounts to control what each container can see. No application-level permission checks — the security model is the infrastructure topology. If a container can't see a file, it can't access it. No bugs, no missed checks, no escalation vulnerabilities.
\nIn SaaS, we spend enormous amounts of time writing authorisation logic. Role checks, permission middleware, tenant-scoping queries. And it works — until someone forgets a WHERE clause.
\nAWS's own SaaS tenant isolation guidance makes this point explicitly: authentication and authorisation are not the same as isolation. The fact that a user logged in doesn't mean your system has achieved tenant isolation. A single missed tenant filter on a database query and you've got a cross-tenant data leak.
\nThe NanoClaw-inspired approach is to push isolation down the stack. Separate database schemas per tenant. Separate containers. Separate cloud accounts for your highest-value customers. Not instead of application-level checks — but as a backstop that catches the bugs your application-level checks inevitably have.
\nAt Xero, working across the integrations and app store teams, I saw first-hand how multi-tenant data isolation gets complicated fast. The teams that had the fewest incidents were the ones where the infrastructure itself enforced boundaries, not just the application code.
\nYou don't need to go full NanoClaw and give every tenant their own container. But you should be asking: if my application-level authorisation has a bug, what's my second line of defence? If the answer is "nothing" — that's the pattern to steal.
\nNanoClaw polls SQLite every 2 seconds. No WebSockets, no event bus, no pub/sub. Just a loop that checks for new stuff.
\nThe instinct for most teams is to treat polling as a temporary hack you'll replace with "proper" event-driven architecture later. Yan Cui wrote a solid breakdown of push vs poll in event-driven systems and the takeaway isn't that one is always better — it's that the right choice depends on your throughput, ordering, and failure-handling requirements.
\nFor a lot of internal systems, polling is the correct permanent answer.
\nAdmin dashboards. Background job status. Internal reporting. Webhook retry queues. Deployment pipelines. These systems don't need sub-second latency. They need reliability and simplicity. A polling loop against your database gives you both, with zero infrastructure overhead.
\nAt Xero we shipped multiple times per day, and some of the internal tooling that supported continuous deployment was surprisingly simple under the hood. Cron jobs. Polling loops. SQL queries on a timer. Not because anyone was cutting corners — because the requirements genuinely didn't need anything more sophisticated.
\nThe trap is reaching for Kafka or RabbitMQ because you think you'll need it eventually. 70% of startups fail due to premature scaling. The infrastructure you don't deploy is the infrastructure that never breaks.
\nNanoClaw uses JSON files on the filesystem for inter-process communication. Atomic rename, directory-based identity, simple polling to pick up new messages. No Redis. No message broker.
\nThat specific approach won't scale to a multi-tenant SaaS — but the instinct behind it absolutely does. The instinct is: use the infrastructure you already have.
\nFor most web apps, that means Postgres. The Postgres-as-queue movement has been gaining serious traction, and tools like PGMQ make it practical. You get ACID guarantees, you don't need to manage another service, and your queue is backed by the same database you're already monitoring and backing up.
\nNanoClaw's atomic write pattern — write to a temp file, rename into place — maps to INSERT INTO queue_table followed by a SELECT ... FOR UPDATE SKIP LOCKED consumer. Same principle: the message either exists completely or doesn't exist at all. No partial state.
The "just add Redis" reflex is strong in our industry. Sometimes it's the right call. But I've seen plenty of teams introduce a message broker for a workload that Postgres could've handled without breaking a sweat — and then spend the next six months debugging consumer lag and dead letter queues.
\nThe specific techniques matter less than the discipline behind them.
\nNanoClaw's developer looked at a 500,000-line framework and asked: what are my actual constraints? Single user. Local machine. One AI provider. And then built exactly the architecture those constraints required — nothing more.
\nMost teams don't do this. They build for imaginary scale, imaginary multi-tenancy requirements, imaginary traffic spikes. They reach for Kubernetes before they've outgrown a single server. They deploy event buses before they've outgrown a polling loop. They write complex authorisation middleware before they've considered whether infrastructure isolation would eliminate the problem entirely.
\nThe pattern worth stealing isn't the credential proxy or the polling loop or Postgres-as-queue. It's the habit of understanding your constraints first and letting them delete complexity from your architecture.
\nHardest pattern to adopt, though. Because it means admitting you're smaller than you think.
\n","date_published":"Sun, 05 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/stealing-nanoclaw-patterns-for-webapps-and-saas.png"},{"id":"https://jonno.nz/posts/what-if-your-browser-built-the-ui-for-you/","url":"https://jonno.nz/posts/what-if-your-browser-built-the-ui-for-you/","title":"What if your browser built the UI for you?","content_html":"We're at a genuinely weird inflection point in frontend development. AI can generate entire interfaces now. LLMs can reason about data and layout. And yet — most SaaS products still ship hand-crafted React apps, each building its own UI, its own accessibility layer, its own theme system, its own responsive breakpoints. Not every service, but the vast majority.
\nThat's a lot of duplicated effort for what's essentially the same job — showing a human some data and letting them do stuff with it.
\nI've been thinking about this a lot lately, and I built a proof of concept to test an idea: what if the browser itself generated the UI?
\nThe industry is circling this idea from multiple angles, but nobody's quite landed on it yet.
\nServer-driven UI has been around for a while — Airbnb and others pioneered it for mobile, where app store review cycles make shipping UI changes painful. The server sends down a JSON tree describing what to render, and the client just follows instructions. It's clever, but the server is still calling the shots. x.
\nGoogle recently shipped Natively Adaptive Interfaces — a framework that uses AI agents to make accessibility a default rather than an afterthought. Really cool idea, and the right instinct. But it's still operating within a single app's boundaries. Your accessibility preferences don't carry between Google's products and, say, your project management tool.
\nThen there's the generative UI wave — CopilotKit, Vercel's AI SDK, and others building frameworks where LLMs generate components on the fly. These are powerful developer tools, but they're still developer tools. The generation happens at build time or on the server. The service is still in control.
\nSee the pattern? Every approach keeps the power on the service side.
\nHere's the idea behind the adaptive browser: what if the generation happened on your side?
\nInstead of a service shipping you a finished frontend, it publishes a manifest — a structured description of what it can do. Its capabilities, endpoints, data shapes, what actions are available. Think of it like an API spec, but semantic. Not just "here's a GET endpoint" but "here's a list of repositories, they're sortable by stars and language, you can create, delete, star, or fork them."
\nYour browser takes that manifest, calls the actual APIs, gets real data back, and then generates the UI based on your preferences. Your font size. Your colour scheme. Your preferred layout (tables vs cards vs kanban). Your accessibility needs. All applied universally, across every service.
\nThe manifest for something like GitHub looks roughly like this — a service describes its capabilities and the browser figures out the rest:
\nservice:\n name: "GitHub"\n domain: "api.github.com"\n\ncapabilities:\n - id: "repositories"\n endpoints:\n - path: "/user/repos"\n semantic: "list"\n entity: "repository"\n sortable_fields: [name, updated_at, stargazers_count]\n actions: [create, delete, star, fork]\nThe browser takes that, fetches the data, and generates a bespoke interface — using an LLM to reason about the best way to present it given who you are and what you're trying to do.
\nWhen I was building the app store and integrations platforms at Xero, one of the constant headaches was that every third-party integration had its own UI patterns. Users had to learn a new interface for every app they connected. If the browser was generating the UI from a shared set of preferences, that problem just… goes away.
\nAccessibility is the big one though. Right now, accessibility is a feature that gets bolted on — and often badly. When the browser generates the UI, accessibility isn't a feature. It's the default. Your preferences — high contrast, keyboard-first navigation, screen reader optimisation, larger text — apply everywhere. Not because every developer remembered to implement them, but because they're baked into how the UI gets generated in the first place.
\nCustomisation becomes genuinely personal too. Not "pick from three themes the developer made" but "this is how I interact with software, full stop."
\nFrontend complexity drops dramatically, but the complexity doesn't disappear — it moves behind the API. And honestly, it probably increases.
\nAPI design becomes way more important. You can't just throw together some REST endpoints and call it a day. Your manifest needs to be semantic — describing what the data means, not just what shape it is. Data contracts between services matter more. Versioning matters more.
\ngraph LR\n A[Service] -->|Publishes manifest + APIs| B[Browser Agent]\n C[User Preferences] --> B\n D[Org Guardrails] --> B\n B -->|Generates| E[Bespoke UI]\nBut here's the thing — this trade-off pushes us somewhere genuinely interesting. If every service needs to describe itself semantically through APIs and manifests, those APIs become the actual product surface. Not the frontend. The APIs.
\nAnd once APIs are the product surface, sharing context between platforms becomes the interesting problem. Your project management tool knows what you're working on. Your email client knows who you're talking to. Your code editor knows what you're building. Right now, none of these talk to each other in any meaningful way because they're all locked behind their own UIs. In a manifest-driven world, that context flows through the APIs — and your browser can stitch it all together into something coherent.
\nI reckon we're about 3-5 years from this being mainstream. The pieces are all there — LLMs that can reason about UI, standardisation efforts around sending UI intent over APIs, and a growing expectation from users that software should adapt to them, not the other way around.
\nThe services that win in this world won't be the ones with the prettiest hand-crafted UI. They'll be the ones with the best APIs, the richest manifests, and the most useful data. The frontend becomes a generated output, not a hand-crafted input.
\nOrganisations will set preference guardrails — "our people can use dark or light mode, must have destructive action confirmations, these fields are always visible" — while individuals customise within those bounds. Your browser becomes your agent, not just a renderer.
\nI built the adaptive browser as a proof of concept to test this thinking — it uses Claude to generate UIs from a GitHub manifest and user preferences defined in YAML. It's rough, but the direction feels right.
\nThe frontend isn't dying. But what we think of as "frontend development" is about to change. The interesting work moves to API design, semantic data contracts, and building browsers smart enough to be genuine user agents.
\n","date_published":"Sun, 05 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/what-if-your-browser-built-the-ui-for-you.png"},{"id":"https://jonno.nz/posts/what-the-data-actually-shows/","url":"https://jonno.nz/posts/what-the-data-actually-shows/","title":"What the Data Actually Shows — Part 4: Exploratory Data Analysis","content_html":"You can't just shove a tensor into a neural network and hope for the best.
\nI mean, you can. People do it all the time. But you'll have no idea whether your model is learning something real or just memorising noise. Before we get anywhere near ConvLSTM or ST-ResNet, we need to properly understand what patterns actually exist in this data — and whether they're strong enough for a model to learn.
\nThis is the part that most ML blog posts skip. It's also the part that saves you weeks of debugging later.
\nThe monthly pattern across Auckland is surprisingly consistent year to year. Crime peaks in late spring and early summer — October through January — and dips in late summer through winter. February is reliably the quietest month at around 7,000–8,000 victimisations, while November and December regularly push past 9,000.
\nThis tracks with what criminology research has found globally — warmer months mean more people out and about, more opportunities for property crime, and more interpersonal conflict. It's a well-documented pattern called seasonal variation in crime, and it shows up clearly in the NZ data.
\nBut here's the interesting bit — the seasonal signal isn't uniform across crime types. Theft drives most of the swing. It surges in summer and drops in winter, accounting for nearly all the monthly variance. Assault has its own rhythm — it peaks around the holiday period (December–January) and shows a secondary bump in winter weekends, probably pub-related. Burglary is flatter, with a slight winter uptick when houses are dark earlier.
\n2023 was the peak year across the board, with a noticeable decline through 2024 and into early 2025. Whether that's a real trend or a reporting artefact, I genuinely don't know. But it means the model's training data includes both an upswing and a downswing, which is actually useful — it can't just learn "crime always goes up."
\nCrime in Auckland is not randomly distributed. That's obvious to anyone who lives here, but it's worth quantifying.
\nRunning a Moran's I test on our 500m grid confirms strong positive spatial autocorrelation — cells with high crime counts are surrounded by other high-crime cells. The Moran's I statistic comes out at 0.43 (p < 0.001), which means the clustering is highly significant. Crime begets more crime in adjacent cells.
\nThe hotspots are exactly where you'd expect. The CBD dominates — Queen Street, Karangahape Road, and the surrounding blocks consistently light up across all crime types. South Auckland corridors — Manukau, Ōtāhuhu, Papatoetoe — form a second cluster, particularly for assault and robbery. Henderson in the west shows up for burglary.
\nWhat's less obvious is how stable these hotspots are over time. The top 5% of cells (about 227 cells) account for over 60% of all recorded crime across the entire four-year period. These aren't random spikes — they're persistent. A cell that's hot in 2022 is almost certainly still hot in 2025. That temporal persistence is exactly what makes this data amenable to prediction. If hotspots moved randomly month to month, no model could learn them.
\nThe six channels in our tensor don't behave independently. Theft and burglary show moderate positive correlation (r ≈ 0.52) — cells with lots of theft tend to have more burglary too, which makes sense given similar opportunity structures (commercial areas, transport hubs).
\nAssault correlates weakly with everything else (r ≈ 0.15–0.25). It has its own spatial logic — nightlife areas, specific residential pockets — that doesn't align neatly with property crime.
\nRobbery, sexual offences, and harm are so sparse at the 500m monthly resolution that correlation analysis is basically meaningless. Most cells have zero counts for these types in any given month. That sparsity is going to be a real headache for the models.
\nWe flagged this in Part 3: 91.7% of the tensor is zeros. But the EDA makes the problem even clearer.
\nThe distribution of non-zero cell values is heavily right-skewed. The median non-zero value is 1. One crime, in one cell, in one month. The mean is about 2.3. A handful of cells — the CBD, Manukau — hit 30–50+ in peak months for theft. The model needs to learn the difference between "always zero" cells, "occasionally one" cells, and "consistently busy" cells.
\nIf you plot the crime count distribution across non-zero cells, it follows something close to a power law. A tiny number of cells carry an outsized share of the signal. This is textbook spatial concentration of crime — it's been documented in basically every city ever studied.
\nFor modelling, this means two things. First, aggregate metrics like RMSE will be dominated by how well the model predicts the high-count cells. Second, predicting "zero" for a sparse cell is almost always correct but completely uninformative. We'll need to think carefully about what "accuracy" actually means when we get to evaluation.
\nThe EDA tells us a few things that should directly shape how we build and evaluate the models:
\nThe seasonal signal is strong and consistent. A model that can't capture monthly seasonality is worse than useless — it's worse than a calendar.
\nSpatial structure is real and persistent. Hotspots don't move much. A model that learns static spatial patterns will get a lot of the way there, even without understanding temporal dynamics.
\nWe already know the CBD will have lots of theft next month. That's not what we're trying to predict. The real value is in the margins — the cells that go from quiet to active, or the months where a normally stable area spikes. That's where deep learning might actually add something over simple baselines.
\nSpeaking of which — we need baselines. Otherwise we won't know if ConvLSTM is actually clever or just expensive. That's next.
\n","date_published":"Thu, 02 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/what-the-data-actually-shows.png"},{"id":"https://jonno.nz/posts/built-an-sms-gateway-with-a-20-dollar-android-phone/","url":"https://jonno.nz/posts/built-an-sms-gateway-with-a-20-dollar-android-phone/","title":"How I Built an SMS Gateway with a $20 Android Phone","content_html":"Twilio charges around $0.05–0.06 per SMS round-trip. Doesn't sound like much until you're building an MVP that sends reminders, confirmations, and notifications — suddenly you're looking at $50/month for a thousand messages. For an app that's not making money yet, that's a dumb tax.
\nHere's what I did instead: grabbed a cheap Android phone, installed an open-source app called SMS Gateway for Android, and turned it into a full SMS gateway with a REST API. My SMS costs dropped to whatever my mobile plan charges — which on plenty of prepaid plans is zero. Unlimited texts.
\nThis post walks through exactly how to wire it into a Next.js app, from first install to receiving webhooks. The whole thing took an afternoon.
\nBy the end of this you'll have:
\nInstall SMS Gateway for Android from the Google Play Store or grab the APK from GitHub Releases
\nOpen the app and grant SMS permissions when prompted
\nYou'll see the main screen with toggles for Local Server and Cloud Server:
\n
The app supports two modes — local and cloud. Both work well, and I'll cover each.
\nLocal mode runs an HTTP server directly on the phone. Your backend talks to it over your local network. No cloud dependency, no third-party servers — the simplest setup.
\n![\"Local](\"https://jonno.nz/img/posts/sms-gateway/local-server.png\")
\nLocal server configuration
8080)192.168.1.50)Your phone is now running an HTTP server. Verify it:
\n# Health check\ncurl http://192.168.1.50:8080/health\n\n# Swagger docs\nopen http://192.168.1.50:8080/docs\ncurl -X POST http://192.168.1.50:8080/message \\\n -u "admin:yourpassword" \\\n -H "Content-Type: application/json" \\\n -d '{\n "textMessage": { "text": "Hello from my SMS gateway!" },\n "phoneNumbers": ["+15551234567"]\n }'\nThat's it. The phone sends the SMS from its own number, using your mobile plan's rates.
\nTo receive SMS messages as webhooks:
\ncurl -X POST http://192.168.1.50:8080/webhooks \\\n -u "admin:yourpassword" \\\n -H "Content-Type: application/json" \\\n -d '{\n "id": "my-webhook",\n "url": "http://192.168.1.100:4000/api/sms/webhook",\n "event": "sms:received"\n }'\nReplace 192.168.1.100 with your dev machine's local IP. Both devices need to be on the same WiFi network.
Cloud mode is easier to set up and works from anywhere — no local network required. The phone connects to SMS Gateway's cloud relay (api.sms-gate.app), and your backend talks to the same cloud API.
![\"Cloud](\"https://jonno.nz/img/posts/sms-gateway/cloud-server.png\")
\nCloud server configuration
The cloud uses a hybrid push architecture: Firebase Cloud Messaging as the primary channel, Server-Sent Events as fallback, and 15-minute polling as a last resort. It's well thought through.
\ncurl -X POST https://api.sms-gate.app/3rdparty/v1/messages \\\n -u "YOUR_USERNAME:YOUR_PASSWORD" \\\n -H "Content-Type: application/json" \\\n -d '{\n "textMessage": { "text": "Hello from the cloud!" },\n "phoneNumbers": ["+15551234567"]\n }'\nYour webhook URL must be HTTPS in cloud mode. For local development, use ngrok:
\n# Start ngrok tunnel to your dev server\nngrok http 4000\n# Output: https://abc123.ngrok.app\n\n# Register the webhook\ncurl -X POST https://api.sms-gate.app/3rdparty/v1/webhooks \\\n -u "YOUR_USERNAME:YOUR_PASSWORD" \\\n -H "Content-Type: application/json" \\\n -d '{\n "url": "https://abc123.ngrok.app/api/sms/webhook",\n "event": "sms:received"\n }'\n# List webhooks\ncurl -u "YOUR_USERNAME:YOUR_PASSWORD" \\\n https://api.sms-gate.app/3rdparty/v1/webhooks\n\n# Delete a webhook\ncurl -X DELETE -u "YOUR_USERNAME:YOUR_PASSWORD" \\\n https://api.sms-gate.app/3rdparty/v1/webhooks/WEBHOOK_ID\nHere's how I integrated SMS Gateway into a Next.js app with a clean provider abstraction. The idea is simple — swap providers without touching business logic.
\n// src/lib/sms/provider.ts\n\nexport interface InboundSms {\n from: string;\n body: string;\n receivedAt?: Date;\n}\n\nexport interface SmsProvider {\n send(to: string, body: string): Promise<string>;\n parseWebhook(req: Request): Promise<InboundSms | null>;\n webhookResponse(replyText?: string): Response;\n}\n\nexport async function getSmsProvider(): Promise<SmsProvider> {\n const provider = process.env.SMS_PROVIDER || "sms-gate";\n\n switch (provider) {\n case "sms-gate": {\n const { SmsGateProvider } = await import("./sms-gate");\n return new SmsGateProvider();\n }\n case "console": {\n const { ConsoleProvider } = await import("./console");\n return new ConsoleProvider();\n }\n default:\n throw new Error(`Unknown SMS provider: ${provider}`);\n }\n}\nThe provider handles both local and cloud API differences:
\n// src/lib/sms/sms-gate.ts\n\nimport type { SmsProvider, InboundSms } from "./provider";\n\nconst SMSGATE_URL = process.env.SMSGATE_URL || "http://localhost:8080";\nconst SMSGATE_USER = process.env.SMSGATE_USER || "";\nconst SMSGATE_PASSWORD = process.env.SMSGATE_PASSWORD || "";\n\nexport class SmsGateProvider implements SmsProvider {\n private headers(): Record<string, string> {\n const auth = Buffer.from(\n `${SMSGATE_USER}:${SMSGATE_PASSWORD}`\n ).toString("base64");\n return {\n "Content-Type": "application/json",\n Authorization: `Basic ${auth}`,\n };\n }\n\n async send(to: string, body: string): Promise<string> {\n const isCloud = SMSGATE_URL.includes("api.sms-gate.app");\n const endpoint = isCloud\n ? `${SMSGATE_URL}/3rdparty/v1/messages`\n : `${SMSGATE_URL}/api/3rdparty/v1/message`;\n const payload = isCloud\n ? { textMessage: { text: body }, phoneNumbers: [to] }\n : { phoneNumbers: [to], message: body };\n\n const res = await fetch(endpoint, {\n method: "POST",\n headers: this.headers(),\n body: JSON.stringify(payload),\n });\n\n if (!res.ok) {\n const err = await res.text();\n throw new Error(`SMS Gate send failed: ${res.status} ${err}`);\n }\n\n const data = await res.json();\n return data.id || "sent";\n }\n\n async parseWebhook(req: Request): Promise<InboundSms | null> {\n try {\n const body = await req.json();\n\n if (body.event !== "sms:received" || !body.payload) {\n return null;\n }\n\n const { phoneNumber, message, receivedAt } = body.payload;\n if (!phoneNumber || !message) return null;\n\n return {\n from: phoneNumber,\n body: message,\n receivedAt: receivedAt ? new Date(receivedAt) : new Date(),\n };\n } catch {\n return null;\n }\n }\n\n webhookResponse(): Response {\n return new Response(JSON.stringify({ ok: true }), {\n headers: { "Content-Type": "application/json" },\n });\n }\n}\nA basic webhook handler that receives inbound SMS and replies:
\n// src/app/api/sms/webhook/route.ts\n\nimport { NextRequest } from "next/server";\nimport { getSmsProvider } from "@/lib/sms/provider";\n\nexport async function POST(req: NextRequest) {\n const provider = await getSmsProvider();\n const sms = await provider.parseWebhook(req);\n\n if (!sms) {\n return new Response("Bad request", { status: 400 });\n }\n\n const { from, body } = sms;\n\n // Look up the sender — replace with your own user lookup\n const user = await findUserByPhone(from);\n\n if (!user) {\n await provider.send(from, "Hey! Text us back once you've signed up.");\n return provider.webhookResponse();\n }\n\n // Known user — do whatever your app needs\n console.log(`[SMS from ${from}]: ${body}`);\n await provider.send(from, "Got it — we're on it!");\n return provider.webhookResponse();\n}\nFor local development without a phone:
\n// src/lib/sms/console.ts\n\nimport type { SmsProvider, InboundSms } from "./provider";\n\nexport class ConsoleProvider implements SmsProvider {\n async send(to: string, body: string): Promise<string> {\n console.log(`[SMS -> ${to}] ${body}`);\n return `console-${Date.now()}`;\n }\n\n async parseWebhook(req: Request): Promise<InboundSms | null> {\n const data = await req.json();\n return {\n from: data.from || "+15550000000",\n body: data.body || "",\n receivedAt: new Date(),\n };\n }\n\n webhookResponse(): Response {\n return new Response(JSON.stringify({ ok: true }), {\n headers: { "Content-Type": "application/json" },\n });\n }\n}\n# .env\n\n# Provider: "sms-gate" | "console"\nSMS_PROVIDER=sms-gate\n\n# Local mode\nSMSGATE_URL=http://192.168.1.50:8080\nSMSGATE_USER=admin\nSMSGATE_PASSWORD=yourpassword\n\n# Cloud mode\n# SMSGATE_URL=https://api.sms-gate.app\n# SMSGATE_USER=auto-generated-username\n# SMSGATE_PASSWORD=auto-generated-password\nWhen someone texts your Android phone, SMS Gateway sends a POST to your webhook URL:
\n{\n "id": "Ey6ECgOkVVFjz3CL48B8C",\n "webhookId": "LreFUt-Z3sSq0JufY9uWB",\n "deviceId": "your-device-id",\n "event": "sms:received",\n "payload": {\n "messageId": "abc123",\n "message": "Hello!",\n "sender": "+15551234567",\n "recipient": "+15559876543",\n "simNumber": 1,\n "receivedAt": "2026-04-01T12:41:59.000+00:00"\n }\n}\n| Event | \nDescription | \n
|---|---|
sms:received | \nInbound SMS received | \n
sms:sent | \nOutbound SMS sent | \n
sms:delivered | \nOutbound SMS confirmed delivered | \n
sms:failed | \nOutbound SMS failed | \n
system:ping | \nHeartbeat — device still alive | \n
SMS Gateway signs webhook payloads with HMAC-SHA256. Two headers are included:
\nX-Signature — hex-encoded HMAC-SHA256 signatureX-Timestamp — Unix timestamp used in signingimport crypto from "crypto";\n\nfunction verifyWebhook(\n signingKey: string,\n payload: string,\n timestamp: string,\n signature: string\n): boolean {\n const expected = crypto\n .createHmac("sha256", signingKey)\n .update(payload + timestamp)\n .digest("hex");\n return crypto.timingSafeEqual(\n Buffer.from(expected, "hex"),\n Buffer.from(signature, "hex")\n );\n}\nIf your server doesn't respond 2xx within 30 seconds, SMS Gateway retries with exponential backoff — starting at 10 seconds, doubling each time, up to 14 attempts (~2 days). Solid default behaviour, you don't need to configure anything.
\nnpm run dev\n# Next.js running at http://localhost:4000\nngrok http 4000\n# https://abc123.ngrok.app -> http://localhost:4000\ncurl -X POST https://api.sms-gate.app/3rdparty/v1/webhooks \\\n -u "USERNAME:PASSWORD" \\\n -H "Content-Type: application/json" \\\n -d '{\n "url": "https://abc123.ngrok.app/api/sms/webhook",\n "event": "sms:received"\n }'\nText your Android phone from another phone. You should see:
\nThat moment when the reply lands on your phone — genuinely satisfying.
\n# Simulate an inbound SMS with the console provider\nSMS_PROVIDER=console npm run dev\n\ncurl -X POST http://localhost:4000/api/sms/webhook \\\n -H "Content-Type: application/json" \\\n -d '{"from": "+15551234567", "body": "Hello"}'\nsystem:ping webhook to alert if the device goes offline.| \n | Local | \nCloud | \n
|---|---|---|
| Latency | \nLower (direct) | \nSlightly higher (relay) | \n
| Network | \nSame network required | \nWorks from anywhere | \n
| Privacy | \nMessages never leave your network | \nMessages transit through SMS Gateway's servers | \n
| Reliability | \nDepends on your network | \nAdds FCM/SSE redundancy | \n
| Cost | \nFree | \nFree (community tier) | \n
I use cloud mode in production because my server's hosted on Railway and can't reach the phone's local network. For development on the same WiFi, local mode is simpler and faster.
\n| Provider | \nSMS Cost | \nMonthly (1,000 msgs) | \n
|---|---|---|
| Twilio | \n~$0.05/msg | \n~$50 | \n
| SMS Gateway + Prepaid SIM | \n$0/msg (unlimited plan) | \n~$8 (plan cost) | \n
That's an 80%+ saving, and it scales linearly — 10,000 messages a month is still just your plan cost.
\nIt's worth knowing this is a whole category now. httpSMS and textbee do similar things. I went with SMS Gateway for Android because the local mode is properly useful for development, the documentation is solid, and it's actively maintained — v1.56.0 dropped in March 2026.
\nFor an MVP, the maths is obvious. A $20 phone and an $8/month plan gets you a programmable SMS gateway that you fully control. No per-message fees, no carrier contracts, no vendor lock-in. If you outgrow it, swap the provider interface to Twilio and you're done — that's why the abstraction exists.
\nLinks:
\n\n","date_published":"Thu, 02 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/built-an-sms-gateway-with-a-20-dollar-android-phone.png"},{"id":"https://jonno.nz/posts/giving-crime-a-place-on-the-map/","url":"https://jonno.nz/posts/giving-crime-a-place-on-the-map/","title":"Giving Crime a Place on the Map — Part 2: Geographic Data Pipeline","content_html":"A crime record that says "Woodglen, meshblock 0284305" is useless for spatial modelling. It's a name and a number. You can't plot it, you can't measure distances from it, and you definitely can't feed it to a neural network that thinks in grid cells.
\nTo do anything spatial, every record needs actual coordinates — latitude, longitude, or ideally metres on a proper projection. That means downloading Stats NZ's geographic boundary files and joining them to our crime data.
\nNew Zealand has a neat nested system of geographic units maintained by Stats NZ:
\ngraph TD\n A["Region (16)"] --> B["Territorial Authority (67)"]\n B --> C["Area Unit / SA2 (~2,000)"]\n C --> D["Meshblock (~53,000)"]\nRegions are the big ones — Auckland, Canterbury, Wellington. Territorial authorities are your cities and districts. Area units are roughly suburb-sized. And meshblocks are the smallest unit — about 100 people each, roughly a city block. Our crime data uses area units and meshblocks, so those are the layers we need.
\nThere's a gotcha here. Stats NZ replaced "Area Units" with "Statistical Area 2" (SA2) in 2018 as part of a geographic classification overhaul. But the NZ Police crime data still uses the old area unit names. So we need the 2017 vintage boundary files, not the current ones. Use the wrong vintage and your join silently fails on hundreds of area units. Ask me how I know.
\nWe downloaded three layers from Stats NZ DataFinder via their WFS API:
\n| Layer | \nFeatures | \nSize | \n
|---|---|---|
| Area Unit 2017 (generalised) | \n2,004 | \n88 MB | \n
| Meshblock 2018 (generalised) | \n53,589 | \n213 MB | \n
| Territorial Authority 2023 | \n68 | \n34 MB | \n
All three come in EPSG:2193 — that's NZTM2000, New Zealand's official projected coordinate system. The units are metres, not degrees. This matters a lot later when we need to build a "500m grid" — you want that to be 500 actual metres, not some approximation based on latitude.
\nWe use generalised (simplified) versions rather than high-definition. The full-resolution meshblock layer is over a gigabyte. For centroid calculations and spatial joins, the generalised versions are more than accurate enough.
\nJoining crime records to area unit boundaries by name was almost perfect. 1,146,721 of 1,154,102 records matched — 99.4%.
\nOnly two area unit codes failed:
\n999999 — the official "unspecified" catch-all (7,331 records)-29 — a straight-up data entry error (50 records)That's a genuinely excellent result. The unmatched records aren't a bug in our pipeline — they're genuinely unlocatable crimes that the police couldn't assign to a specific area. Nothing we can do about those, and nothing we should try to do.
\nThe meshblock join came in lower at 81.2% — 937,604 records matched out of 1,154,102.
\nThis is expected and it's fine. Here's why: NZ meshblock boundaries get revised with every census. We're using 2018 boundaries, but our crime data runs through January 2026. Any crime from 2023 onwards might reference a 2023-vintage meshblock code that simply doesn't exist in the 2018 file. Some meshblocks get split, some get merged, some get renumbered entirely.
\n81.2% still gives us fine-grained coordinates for the vast majority of records. For the ~19% that miss, we fall back to the area unit centroid. It's less precise — suburb-level instead of block-level — but it's better than dropping the records entirely.
\nThis is one of those things that seems like a minor detail but will bite you hard if you get it wrong. We use two coordinate reference systems throughout the project:
\nNZTM2000 (EPSG:2193) for all spatial analysis. The units are metres, which makes grid construction trivial — a 500m cell is literally 500 units on each axis. Distance calculations are straightforward. No need to worry about the fact that a degree of longitude means different things at different latitudes.
\nWGS84 (EPSG:4326) for the frontend dashboard only. deck.gl and MapLibre expect coordinates in degrees (latitude/longitude), which is the standard for web mapping.
\nThe rule is simple: do everything in NZTM2000, convert to WGS84 at the very end when exporting for the dashboard. Mixing coordinate systems mid-pipeline is a recipe for bugs that are incredibly annoying to track down.
\nEach crime record now has up to 8 new geographic columns — area unit centroids, meshblock centroids, and areas in both coordinate systems. The enriched dataset saves as crimes_with_geo.parquet at 21.9 MB with 29 columns.
Quick sanity check: Auckland's mean crime centroid lands at lat -36.90, lon 174.78 — right in the middle of the urban area. If that number had come back as somewhere in the Waikato, we'd know something went wrong.
\nEvery crime record now has a place in physical space. But individual points aren't what the neural network needs — it needs a regular grid. In the next post, we'll overlay a 500m × 500m grid on Auckland, count crimes per cell per month, and build the 4D tensor that turns crime prediction into a video prediction problem.
\n","date_published":"Thu, 26 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/giving-crime-a-place-on-the-map.png"},{"id":"https://jonno.nz/posts/crime-as-video/","url":"https://jonno.nz/posts/crime-as-video/","title":"Crime as Video — Part 3: Spatiotemporal Grid Construction","content_html":"This is where the project gets properly fun.
\nWe've got 1.15 million clean crime records. Every one of them has coordinates — either precise meshblock centroids or area unit fallbacks from Part 2. But a bag of lat/lon points isn't what a neural network wants. ConvLSTM and ST-ResNet are fundamentally image-processing architectures. They expect regular 2D grids — rows and columns, like pixels in a photograph.
\nSo our job now is to convert the messy reality of crime locations into clean, regular "crime images" that a convolutional network can actually consume. And once you see it framed that way, crime prediction becomes video prediction. Each month is a frame. Each grid cell is a pixel. The brightness is the crime count.
\nThis is the single most consequential decision in the entire data pipeline. Get the grid resolution wrong and everything downstream suffers.
\nToo fine — say 100m cells — and the vast majority of cells are empty in any given month. The model sees an ocean of zeros with occasional spikes, which is incredibly hard to learn from. Too coarse — say 2km — and you've blurred away the spatial patterns you're trying to detect. "Auckland CBD" and "Ponsonby" become the same cell, which is useless.
\nWe computed Auckland's urban crime extent from the meshblock centroids (5th to 95th percentile to exclude outliers like Great Barrier Island):
\n| Metric | \nValue | \n
|---|---|
| Urban extent | \n27.7 km × 36.9 km | \n
| Grid resolution | \n500m × 500m | \n
| Grid dimensions | \n77 rows × 59 columns | \n
| Total cells | \n4,543 | \n
At 500m, each cell covers roughly a few city blocks. That's fine enough to distinguish a commercial strip from a residential street, but coarse enough that most cells accumulate at least some crime over the 48-month period. It's a sweet spot — and it's consistent with what recent crime forecasting research uses for similar models in US cities.
\nHere's the nice thing about working in NZTM2000 — the coordinate system we set up in Part 2 where units are metres. Assigning a crime to a grid cell is just floor division:
\ngrid_j = floor((x - xmin) / 500) # column index\ngrid_i = floor((y - ymin) / 500) # row index\nNo spatial joins, no polygon intersection, no geopandas overhead. Just arithmetic. It processes all 400k Auckland records in under a second.
\nFor the ~22% of Auckland records that didn't get meshblock coordinates in Part 2, we fall back to area unit centroids converted to NZTM2000. Those records land at the centre of their suburb rather than their exact location — less precise, but dropping them entirely would be worse.
\nThe result: 354,387 of 412,669 Auckland records (86.2%) fall within the grid. The remaining 14% are in Auckland's outer fringes — Great Barrier Island, rural Rodney, the edges of the Waitakere Ranges — beyond our urban bounding box. That's fine. We're modelling urban crime patterns, not rural ones.
\nWith every crime assigned to a cell, we aggregate by grid position, month, and crime type:
\n(grid_i, grid_j, month, crime_type) → sum(victimisations)\nThis gives us a 4D tensor:
\n| Dimension | \nSize | \nMeaning | \n
|---|---|---|
| T (time) | \n48 | \nMonths: Feb 2022 – Jan 2026 | \n
| H (height) | \n77 | \nGrid rows (south → north) | \n
| W (width) | \n59 | \nGrid columns (west → east) | \n
| C (channels) | \n6 | \nCrime types: theft, burglary, assault, robbery, sexual, harm | \n
Think of it as a 48-frame video with 6 colour channels. A regular video has 3 channels — red, green, blue. Ours has 6 — theft, burglary, assault, robbery, sexual offences, harm. Each pixel's brightness in a given channel tells you how many of that crime type happened in that 500m cell during that month.
\nI genuinely love this framing. It takes a complicated spatial-temporal prediction problem and maps it onto something that decades of computer vision research already knows how to handle.
\nThe tensor is overwhelmingly empty. 91.7% of all cells are zero.
\nThis makes complete sense if you think about it. Most 500m squares in Auckland don't have a single reported crime in any given month. Crime clusters — commercial corridors, transport hubs, specific residential pockets. The non-zero 8.3% is where all the signal lives.
\nThe sparsity does create a training challenge though. If the model just predicted zero everywhere, it'd be right 91.7% of the time. Useless, but technically accurate. That's why we'll use log1p normalisation during training — it compresses the range from [0, 50+] to [0, ~4], giving the model a more balanced gradient to learn from. And it's why the loss function needs to care more about the non-zero cells than the empty ones.
The upside of all those zeros is storage. The compressed numpy format handles sparse data beautifully — the full 4D tensor saves to just 0.2 MB. Compare that to the 21.9 MB Parquet from Part 2.
\nWe split the 48 months temporally — no shuffling, no random sampling:
\n| Set | \nMonths | \nRange | \n
|---|---|---|
| Train | \n36 | \nFeb 2022 – Jan 2025 | \n
| Validation | \n6 | \nFeb 2025 – Jul 2025 | \n
| Test | \n6 | \nAug 2025 – Jan 2026 | \n
The model trains on three years, tunes on six months, and gets evaluated on the most recent six months it's never seen. There's no spatial leakage either — we don't hold out specific grid cells. The model has to predict all locations for future months simultaneously.
\nThis is the only honest way to evaluate a time-series model. If you randomly shuffle months into train and test, the model can memorise seasonal patterns and look brilliant without actually learning anything useful about temporal dynamics.
\nEven at this aggregate level, clear patterns jump out.
\nFebruary tends to be the quietest month (~7–8k victimisations across Auckland), while October through January — spring and early summer — consistently peaks at 8.5–9.5k. 2023 was the peak year across the board, with a gradual decline through 2024 and into 2025.
\nTheft accounts for 72% of the tensor values (283k victimisations), burglary 17% (68k), and assault 9% (34k). That theft dominance from Part 1 — the 66% figure — gets even more pronounced when you focus on Auckland, because theft clusters harder in urban areas than other crime types do.
\nThe tensor is built. The model input is ready. But before throwing deep learning at anything, we need to properly understand what patterns actually exist in this data — when does crime peak, where does it cluster, and how do different crime types behave differently. Next post: exploratory data analysis.
\n","date_published":"Thu, 26 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/crime-as-video.png"},{"id":"https://jonno.nz/posts/wrangling-a-million-crime-records/","url":"https://jonno.nz/posts/wrangling-a-million-crime-records/","title":"Wrangling a Million Crime Records — Part 1: Data Acquisition","content_html":"The very first thing NZ Police's crime dataset teaches you is that government data is never straightforward.
\nYou download the CSV from policedata.nz, expecting to do a quick pd.read_csv() and start exploring. Instead you get a 503MB file encoded in UTF-16 Little Endian with tab delimiters. Not a regular CSV. Not even close. This is a legacy format from old Excel exports and most tools just silently corrupt it if you try to read it as UTF-8.
df = pd.read_csv("data.csv", encoding="utf-16-le", sep="\\t")\nThat one line took longer to figure out than I'd like to admit.
\nOnce you get past the encoding, there's a lot to work with. 1,154,102 rows covering every reported victimisation in New Zealand from February 2022 through January 2026. Each row tells you the crime type (ANZSOC Division), where it happened (down to meshblock level), when it happened (month, day of week, hour of day), and sometimes what weapon was involved.
\nThere are 20 columns, but five of them are useless — three are just duplicates of "Year Month" and two are constants that add zero information. Every area name and territorial authority has a trailing period stuck on the end: "Auckland.", "Woodglen.", "Christchurch City.". A quirk of the export that'll break any geographic join if you don't strip them.
\nAnd meshblock IDs? Some are 6 digits, some are 7. Stats NZ boundary files use 7-digit codes consistently, so shorter ones need zero-padding. The kind of thing that's invisible until your join silently drops 19% of your records and you spend an afternoon figuring out why.
\nHere's the bit that actually made me stop and think. 32.2% of records have the hour of day recorded as 99 — unknown. Another 23.2% have the day of week as "UNKNOWN".
\nAt first this looks like a data quality problem. But it's not — it's actually telling you something about the nature of the crime. If someone breaks into your house while you're at work, you come home to find your stuff gone. Was it 9am or 2pm? You've got no idea, and neither do the police.
\nProperty crimes — theft, burglary — make up the bulk of these unknowns. Assault, by contrast, almost always has a precise time because there's a victim present when it happens. The absence of data is itself a signal about what kind of crime you're looking at.
\n78.6% of location type values are just "." — effectively missing. That column is sparsely populated but still useful for the roughly one in five records that have it.
\nWe built a modular pipeline where each cleaning step is its own function. Nothing fancy, just practical:
\ndef ingest() -> pd.DataFrame:\n df = load_raw_csv(RAW_CSV) # UTF-16 LE, tab-delimited\n df = drop_redundant_columns(df) # Remove 5 useless columns\n df = rename_columns(df) # snake_case everything\n df = parse_dates(df) # "July 2022" → datetime\n df = clean_strings(df) # Strip trailing periods\n df = clean_meshblocks(df) # Zero-pad to 7 digits\n df = encode_unknowns(df) # 99 → NaN, "UNKNOWN" → NaN\n df = map_crime_types(df) # ANZSOC Division → short enum\n return df\nEach function does one thing. If something breaks, you know exactly where. If someone wants to understand the pipeline, they can read it top to bottom in about thirty seconds. I've been bitten enough times by monolithic data scripts that I'm allergic to them now.
\nThe crime type mapping turns six ANZSOC Division values into short enums:
\n| Crime Type | \nCount | \nShare | \n
|---|---|---|
| Theft | \n761,977 | \n66.0% | \n
| Burglary | \n247,034 | \n21.4% | \n
| Assault | \n115,383 | \n10.0% | \n
| Robbery | \n14,860 | \n1.3% | \n
| Sexual | \n13,943 | \n1.2% | \n
| Harm | \n905 | \n0.1% | \n
That 66% theft number is going to haunt us when we get to model training. Any loss function you throw at this data will overwhelmingly optimise for predicting theft, because that's two-thirds of everything. The class imbalance is real and it matters.
\nThe cleaned output goes to Apache Parquet with snappy compression. The result?
\nThat's not a typo. Parquet's columnar storage is dramatically more efficient than row-oriented CSV, especially when you've got columns full of repeated values like crime types and territorial authorities. The file loads in under a second compared to 3+ seconds for the CSV. When you're iterating on analysis and loading this data hundreds of times, that adds up fast.
\nThe 21 output columns include the original 16 we kept plus five derived ones: a proper datetime, year, month, day-of-week as an integer, and the short crime type enum.
\nBefore calling the data clean, we verify everything that matters:
\nYou want these checks automated and running every time you regenerate the data. Future you will thank past you when something upstream changes and a check catches it.
\nWe've got clean, compressed crime data — but the records only have meshblock IDs and area unit names. No coordinates. No shapes on a map. In the next post, we'll download Stats NZ geographic boundary files and join them to our crime records, giving every victimisation a place in physical space.
\n","date_published":"Thu, 26 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/wrangling-a-million-crime-records.png"},{"id":"https://jonno.nz/posts/predicting-crime-in-aotearoa/","url":"https://jonno.nz/posts/predicting-crime-in-aotearoa/","title":"Predicting Crime in Aotearoa — A Hobby Project with 1.15 Million Records","content_html":"NZ Police publish every recorded victimisation in the country — over a million records — and most people have no idea.
\nI stumbled across policedata.nz a while back and was surprised by how much is there. Every reported theft, assault, burglary, robbery — broken down by location, time of day, day of week, and month. All the way down to meshblock level, which is roughly a city block. Updated monthly. Creative Commons licensed. You can just... use it.
\nSo naturally I started wondering — what happens if you point deep learning at this?
\nThe dataset I pulled covers February 2022 through January 2026. Four years, 1,154,102 records across the whole country. The breakdown is roughly what you'd expect: theft dominates at 66%, followed by burglary at 21% and assault at 10%. The remaining sliver covers robbery, sexual offences, and harm/endangerment.
\nWhat makes it interesting for modelling is the spatial granularity. Each record maps to one of 42,778 meshblocks — tiny geographic units defined by Stats NZ. That's detailed enough to see patterns at a neighbourhood level, not just "Auckland has more crime than Tauranga" (which, yeah, obviously).
\nAuckland alone accounts for about 36% of all recorded crime. Then there's a long tail — Wellington, Christchurch, Hamilton, and then it drops off fast. NZ's urban geography is weird like that. One mega-city and a bunch of mid-size towns.
\nThe core question is pretty simple: given the crime patterns of the last few months, can we predict what the next month looks like?
\nThis isn't Minority Report. Nobody's getting arrested for crimes they haven't committed. It's pattern recognition on publicly available statistics — the same kind of modelling people do with weather data or traffic flows.
\nThe neat trick is how you frame it. If you overlay a grid on a city — say 500m by 500m cells — and count crimes per cell per month, you get something that looks a lot like a video. Each month is a frame. Each cell is a pixel. The brightness is the crime count.
\nPredicting next month's crime becomes a video prediction problem. And there are some really cool deep learning architectures built exactly for that.
\nThe two models I'm building are ConvLSTM and ST-ResNet. Don't worry if those sound like gibberish — the short version is they're neural networks designed to learn patterns that are both spatial (where things cluster) and temporal (how those clusters change over time).
\nConvLSTM is the primary model. A standard LSTM network is great at learning sequences — it's the architecture behind a lot of language and time-series models. ConvLSTM swaps out the matrix multiplications for convolutions, which means it can process grid-structured data. Feed it the last six months of crime grids and it learns both the shape of hotspots and how they evolve. Recent research has shown these work well for crime forecasting across multiple US cities.
\nST-ResNet takes a different angle. Instead of one sequential view, it captures three temporal perspectives — what happened recently, what happened at the same time last year, and what's the long-term trend. Each gets its own branch of residual convolutional networks, and a learned fusion layer combines them. The original paper was for crowd flow prediction in Beijing, but the architecture translates well to crime data.
\nAlmost all published crime prediction research uses US data. Chicago, Los Angeles, New York. A systematic review of spatial crime forecasting makes this pretty clear. The models are well-studied, but they're trained on American cities with American urban patterns.
\nNew Zealand doesn't look like that. Our cities are smaller, more spread out, and the distribution is completely different. Auckland dominates in a way that no single US city does relative to the rest of the country. The spatial patterns here are their own thing, and I couldn't find anyone who'd applied these deep learning approaches to NZ data.
\nThat's what got me keen. Not because I think I'll beat the published benchmarks — those researchers have GPUs and PhD students and I have a Ryzen 5 desktop with no graphics card. But applying known techniques to new geography is useful work, and nobody else seems to have done it.
\nAll of this runs on my desktop — an AMD Ryzen 5 5600GT with 12 threads and 30GB of RAM. No GPU at all. That sounds limiting, but the Auckland 500m grid works out to about 60 by 80 cells. The ConvLSTM model ends up around 5 million parameters, which trains in under an hour on CPU. You don't always need a beefy rig.
\nIt does mean being smart about model sizing and not going crazy with hyperparameter searches. But for a hobby project, it's more than enough.
\nThis is the first post in a ten-part series covering the whole project end to end.
\nPart 1: Data Acquisition and Exploration — We start with a 503MB CSV file from NZ Police that's UTF-16 encoded (because of course it is), has trailing periods on area names, and 32% of records with unknown hour-of-day. We'll wrangle it into a clean, typed Parquet file and get our first look at what's actually in there.
\nPart 2: Geographic Data Pipeline — Crime records come with meshblock IDs, but no coordinates. We'll join them to Stats NZ geographic boundary files using geopandas, giving every record a place on the map.
\nPart 3: Spatiotemporal Grid Construction — This is where it gets fun. We overlay a 500m by 500m grid on Auckland, count crimes per cell per month, and build the 4D tensors that feed the neural networks. Crime prediction becomes video prediction.
\nPart 4: Exploratory Data Analysis — Before throwing deep learning at anything, we need to understand what patterns actually exist. When does crime peak? Where does it cluster? How do different crime types behave differently?
\nPart 5: Baseline Models — Simple benchmarks — historical averages, naive persistence — so we know whether the deep learning is actually adding value or just being fancy for the sake of it.
\nPart 6: ConvLSTM Architecture — Building and training the primary model. Three ConvLSTM layers, six-month lookback window, learning spatial hotspots and temporal dynamics simultaneously.
\nPart 7: ST-ResNet Architecture — The three-branch alternative that captures closeness, periodicity, and long-term trend separately, then fuses them with learned weights.
\nPart 8: Model Evaluation and Comparison — Which model wins? By how much? And more importantly — where do they fail?
\nPart 9: Building the Dashboard — A 3D interactive map built with deck.gl where you can watch crime patterns evolve over time. Dark theme, extruded columns, time-lapse playback.
\nPart 10: Deployment and Reflections — Shipping to Vercel, what worked, what didn't, and what I'd do differently next time.
\nEvery post will include code and real results. The whole codebase will be open source. And I'll be upfront about the stuff that didn't work — which, trust me, there's plenty of.
\nThis is a hobby project. It's not a policing tool, it's not a product, and it's definitely not claiming to solve crime. It's just me being curious about what's sitting in a publicly available dataset and seeing how far you can push it with some Python and a bit of patience.
\n","date_published":"Tue, 24 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/predicting-crime-in-aotearoa.png"},{"id":"https://jonno.nz/posts/nanoclaw-architecture-masterclass-in-doing-less/","url":"https://jonno.nz/posts/nanoclaw-architecture-masterclass-in-doing-less/","title":"NanoClaw's Architecture is a Masterclass in Doing Less","content_html":"Most codebases grow by adding things. More abstractions, more dependencies, more config files. NanoClaw does the opposite — it replaces a 500,000-line AI assistant framework with roughly 8,000 lines of TypeScript and six production dependencies.
\nThat's not a flex about line count. It's the result of six architectural bets that are genuinely interesting, and honestly, patterns I wish I'd seen more teams adopt over the years.
\nI pulled the entire codebase apart to understand how it works. Here's what I found — and why these patterns matter way beyond a personal AI assistant.
\nThis is the one that properly impressed me.
\nNanoClaw runs AI agents inside Linux containers. Those agents need API keys to talk to Anthropic. The obvious approach is to pass the key as an environment variable. That's what most of us do, right? Stick it in an env var, maybe pull it from a secrets manager at startup, move on.
\nNanoClaw doesn't do that. Instead, every container gets a placeholder API key and a base URL pointing at a localhost proxy on port 3001. The proxy sits on the host, intercepts every outbound API request, strips the placeholder, and injects the real credential before forwarding upstream.
\nsequenceDiagram\n participant Agent as Agent (Container)\n participant Proxy as Credential Proxy (Host :3001)\n participant API as Anthropic API\n\n Agent->>Proxy: POST /v1/messages<br/>x-api-key: "placeholder"\n Proxy->>Proxy: Strip placeholder<br/>Inject real API key\n Proxy->>API: POST /v1/messages<br/>x-api-key: "sk-ant-..."\n API-->>Proxy: Response\n Proxy-->>Agent: Response\nThe agent literally cannot leak the real key — it never has it. Even if a prompt injection attack tricks the agent into dumping its environment variables, all you get is ANTHROPIC_API_KEY=placeholder. There's nothing to exfiltrate.
This pattern now has a proper name — the Phantom Token Pattern. It's being adopted as a sidecar proxy in Kubernetes for production AI agent deployments. NanoClaw arrived at the same design independently, which tells you something about how natural this solution is once you frame the problem correctly.
\nThe proxy also handles two auth modes (API key and OAuth) and binds differently per platform — 127.0.0.1 on macOS/WSL2, the docker0 bridge IP on Linux. Secrets are loaded into a plain object, never into process.env, so they can't leak to child processes.
At Vend and Xero I spent a lot of time thinking about authorization. Role-based access, permission checks, middleware that decides what each user can do. It works, but it's a constant source of bugs — one missed check and you've got an escalation vulnerability.
\nNanoClaw takes a completely different approach. Instead of checking what an agent is allowed to do, it controls what the agent can see.
\ngraph TB\n subgraph "Non-main group container"\n A["/workspace/group/ — Writable"]\n B["/workspace/global/ — Read-only"]\n C["/workspace/ipc/ — Writable"]\n end\n\n subgraph "Main group container"\n D["/workspace/project/ — Read-only"]\n E["/workspace/project/.env — Shadowed to /dev/null"]\n F["/workspace/group/ — Writable"]\n G["/workspace/ipc/ — Writable"]\n end\n\n subgraph "Host filesystem"\n H["Project root"]\n I[".env (real secrets)"]\n J["Group folders"]\n K["IPC directories"]\n end\n\n H --> D\n I -.->|blocked| E\n J --> A\n J --> F\n K --> C\n K --> G\nEach container gets a specific set of mounts. A non-main group container can only see its own folder — it physically cannot access the project root, other groups' data, or host files. The main group gets read-only access to the project, but .env is shadow-mounted to /dev/null. Even with the full project mounted, secrets are invisible.
The agent inside the container runs with bypassPermissions — it can use Bash, write files, do whatever it wants. But "whatever it wants" is constrained by what the OS lets it see. No application-level permission checks needed.
Additional mounts are validated against a blocklist (.ssh, .gnupg, .aws, credentials, etc.) that lives outside the project root, making it tamper-proof from inside any container. Symlink resolution prevents path traversal attacks like creating /tmp/innocent -> ~/.ssh.
The security model is the filesystem topology itself.
\nMessage processing in NanoClaw uses two independent cursors — and the interaction between them is the cleverest bit of the whole system.
\nCursor 1 is a global watermark. The main polling loop reads new messages from SQLite every 2 seconds. When it sees messages, it advances the watermark immediately and persists it. This prevents the same batch from being processed twice if the loop runs again before the agent finishes.
\nCursor 2 is per-group. When a group's messages are about to be processed, the per-group cursor advances optimistically before the agent starts. If the agent fails:
\nflowchart TD\n A[New messages arrive] --> B[Cursor 1: Advance global watermark]\n B --> C[Persist to SQLite]\n C --> D[Cursor 2: Advance per-group cursor optimistically]\n D --> E[Run agent in container]\n E --> F{Agent succeeded?}\n F -->|Yes| G[Keep cursor position]\n F -->|No| H{Output already sent to user?}\n H -->|Yes| I[Keep cursor — avoid duplicates]\n H -->|No| J[Roll back cursor — safe to retry]\nThis gives you at-most-once delivery to the user and at-least-once processing for the agent. That's the right tradeoff for a messaging system — users should never see duplicate messages, but retrying agent work is fine.
\nI've built billing platforms where we had to think about exactly these kinds of delivery guarantees. Getting this wrong in a payments context means double-charging customers. NanoClaw's approach is clean — two cursors, one rule: once you've spoken to the user, you can't unsay it.
\nNo Redis. No RabbitMQ. No gRPC. NanoClaw's inter-process communication is JSON files on the filesystem.
\nContainers write outbound messages to /workspace/ipc/messages/. The host writes follow-up messages to /workspace/ipc/input/. Both sides use the same pattern — write to a .tmp file, then rename it into place. rename is atomic on POSIX filesystems. The file either exists with complete content or doesn't exist at all.
graph LR\n subgraph Container\n A[Agent writes response] --> B["Write to .tmp file"]\n B --> C["Atomic rename to .json"]\n end\n\n subgraph Host\n D["IPC Watcher 1s poll"] --> E["Read .json files"]\n E --> F{Source group?}\n F -->|Main group| G["Send to any target"]\n F -->|Other group| H["Send only to self"]\n end\n\n C --> D\nAuthorization is enforced by directory identity. Each group has its own IPC directory (/data/ipc/{group}/). The host knows which group wrote a file based on which directory it appeared in. A container can't spoof its identity because its mount configuration fixes which directories it can write to.
The main group can send messages to any other group. Non-main groups can only send to themselves. This isn't enforced by application logic checking tokens — it's enforced by the host reading from a directory that only one container can write to.
\nThis is the same atomic write pattern used in crash-safe database implementations. The key constraint — temp file and target must be on the same filesystem — is guaranteed because both live inside the same container mount.
\nThe main loop polls SQLite every 2 seconds. The IPC watcher polls the filesystem every 1 second. The task scheduler polls every 60 seconds.
\nIn a system designed for one user, this eliminates entire categories of race conditions. No WebSocket connection management, no event ordering guarantees to maintain, no callback hell. Just: check for new stuff, process it, sleep, repeat.
\nI've been on teams that reached for event-driven architectures way too early. At Xero we shipped multiple times a day — but the internal tooling that supported that? Half of it would've been simpler with a poll loop. When you know your scale ceiling, polling is a feature, not a limitation.
\nEach container recompiles TypeScript on startup. The agent-runner source is mounted from a per-group directory, so each group can have customised agent behaviour. The compiled output goes to /tmp/dist which is then made read-only — the agent can't modify its own runner.
No plugin registry. No abstraction layer. No dependency injection. You want different behaviour per group? Change the source files. The container picks it up on next startup.
\nThis is slower than a plugin system, sure. Container startup pays a compilation tax. But it eliminates an entire layer of indirection — and that layer is usually where the bugs live.
\nThese aren't random choices. They're all expressions of the same principle: know your constraints, and use them to delete complexity.
\nNanoClaw is a single-user system. It knows this. So it polls instead of pushing, uses the filesystem instead of a message queue, and isolates with containers instead of writing authorization middleware.
\nThe interesting question isn't whether these patterns work for NanoClaw — they obviously do. The question is: where do these same constraints exist in your stack? Because they're more common than you think.
\nThat's what Part 2 is about.
\n","date_published":"Mon, 23 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/nanoclaw-architecture-masterclass-in-doing-less.png"},{"id":"https://jonno.nz/posts/careers-in-the-self-driving-codebase-era/","url":"https://jonno.nz/posts/careers-in-the-self-driving-codebase-era/","title":"Careers in the Self-Driving Codebase Era","content_html":"The engineering career ladder made perfect sense when code was expensive to produce. A junior learned syntax and patterns. A mid-level learned how to build features end-to-end. A senior learned architecture and trade-offs. A staff engineer learned strategy and influence. Each level was gated by coding ability — your value was measured by how much complexity you could wrangle into working software.
\nThen Cursor published research showing their agents producing 1,000 commits per hour across 10 million tool calls. Not toy commits on a demo project. Real changes, on a real codebase, with minimal human intervention.
\nCode is now essentially free. Not literally free — you're still paying for Cursor subscriptions and inference budgets — but compared to what a team of engineers used to cost to produce the same output? It's not even close. What does the career ladder measure when anyone can ship code?
\nThe junior → mid → senior → staff progression assumed three things: coding ability is the scarce resource, learning takes years of hands-on practice, and each level unlocks access to more complex work.
\nIf you wanted complex software built in 2015, you needed people who'd spent years developing the muscle memory. Understanding a large codebase took months. Writing clean, maintainable code took practice. Debugging production issues at 2am took experience.
\nAll of that is still true. But the bottleneck has shifted. The hard part isn't writing the code anymore — it's knowing what code to write, securing what gets built, and operating it at scale once it's running.
\nNick Durkin, Field CTO at Harness, put it bluntly: "By 2026, every engineer effectively becomes an engineering manager. Not of people, but of AI agents."
\nI've spent the last few years moving between roles — Head of Engineering at Cotiss, now Principal Engineer at Prosaic. And the thing I've noticed is that my value has shifted dramatically away from writing code.
\nWhen code production is commoditised, value moves to everything around the code:
\nSecuring it. Agent-generated code ships fast. Who's checking it for vulnerabilities? Who understands the attack surface? Security isn't a nice-to-have anymore — it's the difference between shipping confidently and shipping scared.
\nArchitecting it. Agents can implement whatever you specify. But someone still needs to understand the business requirements deeply enough to know what to specify. What are the trade-offs? What will scale? What won't? That judgement doesn't come from prompts.
\nOperating it. The code ships. Now what? Who's on-call? Who understands the failure modes? Who can debug a production incident when the agent that wrote the code is long gone?
\nOrchestrating it. This is the new skill. Understanding business context, product requirements, and technical constraints well enough to specify clearly what agents should build — and then validating they built the right thing.
\nCursor's research called this "taste, judgement, and direction." I'd call it something simpler: understanding the business deeply enough to give good instructions.
\nHere's my take on where this goes. The future isn't junior → senior. It's hybrid roles that span disciplines.
\nProduct-engineer. Someone who understands user outcomes and technical constraints. They don't just build what's in the ticket — they understand why it's in the ticket and whether it's the right thing to build.
\nSecurity-architect. Someone who can secure agent-generated code at scale. Not just running a scanner — actually understanding the threat model and building secure systems.
\nBusiness-technologist. Someone who translates strategy into specifications. They sit between the CEO's vision and the agent's implementation, making sure nothing gets lost.
\nThese aren't new roles invented from scratch. They're the natural evolution of what senior engineers have always done — but with the coding part increasingly handled by agents.
\nThe key insight: you need to understand more of the business deeply to stay valuable. Security. Org structure. Go-to-market. Operations. The more context you hold, the better your specifications, the better your agent-driven outcomes.
\nWhat happens to junior engineers? Stanford's research is sobering — early-career workers aged 22-25 in AI-exposed jobs saw a 16% employment decline, while workers aged 35-49 grew by 8%.
\nBut I don't think entry-level disappears. It transforms.
\nThe baseline shifts from "can you code?" to "can you specify, verify, and operate?" Entry-level becomes prompt engineer plus systems thinker. IEEE Spectrum's reporting quotes a hiring manager saying you need to "slot in at a higher level almost from day one."
\nThat's brutal if you're expecting the old training path — start with simple tickets, learn the codebase over six months, gradually take on harder work. That path assumed coding reps were the training ground.
\nBut it's also an opportunity. If you can think in systems, understand business context, and validate outcomes — you can contribute faster than any previous generation of engineers. The barrier to producing working software has never been lower. The barrier to producing the right working software is higher than ever.
\nHere's what's been rattling around my head: software engineers used to be the bottleneck.
\nWant a new feature? Wait for engineering capacity. Want to test a hypothesis? Wait for engineering capacity. Want to pivot the product? Wait for engineering capacity.
\nNow? Agents can ship fast. The bottleneck moves elsewhere.
\nThe question isn't "how fast can we code this?" anymore. It's "how fast can the organisation decide what to build and validate it works?"
\nEngineers who understand business context — who can move between product, operations, security, and strategy — can now capitalise on that agility instead of being constrained by it. The organisations that win will be the ones where engineers aren't waiting for briefs. They're helping shape them.
\nEverything I've said applies to the world I know — traditional SaaS, product engineering, building applications. The stuff most of us do day to day.
\nIf you're doing deep tech — building compilers, writing ML frameworks, working on kernel internals, pushing the boundaries of computer science — the calculus is different. That work still requires deep, specialised knowledge that agents can't replace. The science matters.
\nBut here's the thing. Most of us aren't doing that. Most of us are standing on the shoulders of giants — using frameworks, libraries, and platforms that brilliant people built — and assembling them into products that solve business problems. That's not a knock. That's the whole point of good abstraction. It means there's a clear path even in this era: the scientists keep pushing the frontier, and the rest of us get radically better tools to build on top of it.
\nThe engineers who understand that distinction — who know when they're doing science and when they're doing integration — will navigate this shift much better than the ones who think writing CRUD endpoints is a craft that can't be automated.
\nI started my career in retail at Spark NZ. Moved into support at Vend. Learned to code on the job. Became an engineer, then a lead, then a manager, then a Head of Engineering, then a founder, then to principal engineer hands on with AI. That path made sense because each step built on coding ability.
\nThe next generation's path looks different. It's less about climbing a ladder and more about expanding across disciplines. Less about depth in code and more about breadth in context.
\nThe ladder isn't dead. But the rungs have changed. And if you're still climbing the old one, you might be wondering why the top doesn't look like what you expected.
\nThe good news? This is an opportunity for engineers who want to expand beyond code. The people who've been frustrated that "just write the code" never seemed to capture the full value they could bring — this is your moment. The organisations that figure out how to deploy these people effectively will move faster than anyone thought possible.
\nThe ones that keep hiring for the old ladder? They'll keep being confused about why their engineering investment isn't translating into outcomes.
\n","date_published":"Sat, 21 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/careers-in-the-self-driving-codebase-era.png"},{"id":"https://jonno.nz/posts/why-llms-waste-half-their-brain/","url":"https://jonno.nz/posts/why-llms-waste-half-their-brain/","title":"Why LLMs waste half their brain","content_html":"You know the pattern. You give Claude Code a task — "add pagination to the invoices endpoint" — and before it writes a single line of code, it does this:
\nGlob for *invoice*. 47 results. Read 5 files to understand the structure. Grep for fetchInvoices. 12 results. Read 4 more. Grep for existing pagination patterns. 8 results. Read 3 more. Then, finally, it starts coding.
That's 12+ files read across 10+ tool calls, burning 60-100k tokens on exploration alone. And that's the good outcome — sometimes it misses a file entirely and heads off in a direction that makes zero sense.
\nI've been using Claude Code daily on production codebases at Prosaic and this pattern drives me nuts. The agent is genuinely good at writing code. It's just spending way too much of its context window figuring out where things are.
\nI saw jeremychone's approach on Hacker News and it immediately clicked. The idea is dead simple: code map with a cheap model, auto-context with a cheap model, then code with the big model.
\nThe key bit — you index every file in your repo with a one-line summary using something cheap and fast like Haiku. That's your code map. Then when you have a task, you send those summaries (not the source code — just the summaries) to the cheap model and ask it to pick the files that matter. It returns 5-10 file paths. You feed the full source of those files to your expensive model.
\n381 candidate files compressed down to 5. 1.62 MB down to 27 KB. That's a 98% reduction in context — and the selection is intelligent, not keyword matching.
\nHigher precision on the input leads to higher precision on the output.
\ngraph LR\n A["Your repo<br/>2688 files"] -->|codemap build| B["Per-file index<br/>summary, types,<br/>functions, imports"]\n B -->|codemap select| C["Cheap model picks<br/>381 → 5 files"]\n C --> D["Agent gets<br/>focused context<br/>30-80k tokens"]\nCodemap is a Go CLI that implements this pipeline. Two commands do most of the work.
\ncodemap build indexes your repo. For each file it generates a structured entry:
summary — one-sentence description (from the LLM)when_to_use — when a developer would need this file (from the LLM)public_types and public_functions — exported symbols (from the Go AST parser)imports — dependency list (from the parser)keywords — domain terms (from the LLM)Deterministic facts come from static analysis. Semantic fields come from the cheap model. The index is cached as JSON and keyed on mtime + BLAKE3 hash — so subsequent builds only re-index files that actually changed. First run on a 2700-file repo takes a few minutes. After that, it's seconds.
\nCost for a full index? About $2-3 with Haiku across 2700 files. Pennies for incremental rebuilds.
\ncodemap select is where the magic happens. Given a task description, it loads the code map (summaries only — small), sends them to the cheap model with your task, and the LLM picks the 5-10 files that are actually relevant. Then it reads the full source of those files and hands everything back.
This isn't keyword overlap or TF-IDF scoring. The LLM reads all the summaries, understands what "add pagination to invoices" actually requires, and returns the files you need — the handler, the repository, the existing pagination helper, the relevant tests. One call, done.
\nCodemap runs as an MCP server over stdio. You register it once:
\nclaude mcp add codemap -- codemap mcp\nClaude Code gets three tools:
\ncodemap_select — the main one. Claude calls this with the task description, gets back full source of selected files, starts coding immediately.codemap_status — quick check on whether the index is fresh or stale.codemap_build — triggers an incremental rebuild if needed.The workflow becomes: Claude gets a task, calls codemap_select, receives focused context, writes code. No glob. No grep. No wrong turns.
I'm not keen on hand-wavy claims about "tokens saved" or "X% faster." You can't measure a counterfactual. What you can measure is whether the file selection was actually right.
\nCodemap tracks real metrics from observed data:
\nSelection accuracy — after a session, compare the files codemap selected against the files actually modified via git diff --name-only. That gives you precision (how many selected files were actually needed) and recall (how many changed files were pre-selected).
Exploration overhead — a PostToolUse hook logs every Read, Glob, and Grep call Claude makes after receiving codemap context. If Claude needed to go exploring beyond what codemap gave it, that shows up as overhead. Trending toward zero means the selection is doing its job.
\nContext compression — candidates vs selected, measured in bytes. Both numbers are real.
\nHere's what a typical stats output looks like:
\nSelection Accuracy (last 10 sessions)\n Avg hit rate: 82%\n Avg precision: 65%\n Avg compression: 97%\n\nExploration Overhead (last 10 sessions)\n Avg extra Read calls: 1.8\n Avg total Read calls: 6.2\n Overhead ratio: 29%\nNo estimates. No counterfactuals. Just: did codemap pick the right files, and did Claude need to look elsewhere?
\nThe pattern here is simple but powerful — use cheap, fast models for the boring structural work so the expensive model can focus its entire context window on actually solving the problem. Haiku is bloody good at reading 2700 one-line summaries and picking the 5 that matter. That's not a task that needs Opus.
\nCodemap is open source, written in Go, and supports Anthropic, OpenAI, and Google as LLM providers. If you're using Claude Code on anything bigger than a toy project, give it a go.
\n","date_published":"Wed, 18 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/why-llms-waste-half-their-brain.png"},{"id":"https://jonno.nz/posts/what-if-a-worm-could-make-ai-agents-smarter/","url":"https://jonno.nz/posts/what-if-a-worm-could-make-ai-agents-smarter/","title":"What if a Worm Could Make AI Agents Smarter?","content_html":"AI coding agents are genuinely impressive right now. You give Claude or GPT a task, it reads your code, writes a fix, runs the tests. Awesome. But here's the thing that's been bugging me — most practical agents still rely on largely fixed control policies. Same temperature, same approach, same level of caution whether they just broke the build or nailed it first try. They're locally reactive, not deeply adaptive. It's like having a developer who responds to each step but never changes their underlying strategy based on what just happened.
\nThat felt like a problem worth poking at. And the answer I landed on came from a pretty unexpected place — a roundworm with 302 neurons.
\nIf you've used AI coding agents for any real work, you've probably noticed this. Yes, modern agents can maintain state, use memory, and even reflect on previous attempts — but their behavioural policy for how they react usually doesn't change unless a human rewrites the prompt or the harness. The agent doesn't get more cautious after breaking something. It doesn't get more exploratory when it's stuck. It just keeps doing the same thing with the same settings, tick after tick.
\nI've spent years managing engineering teams — at Vend, at Xero, at Cotiss — and the best engineers constantly adjust their approach. They slow down when things are fragile. They get creative when they're blocked. They know when to stop. Current AI agents don't do any of that.
\nSo the question became: what if you could build a control layer that sits outside the AI and adjusts its behaviour in real time based on how things are going?
\nc302 is a research project I've been building. The name comes from the c302 model in the OpenWorm project — an open-source computational model of the Caenorhabditis elegans roundworm's nervous system.
\nC. elegans is a fascinating little creature. It's got exactly 302 neurons and roughly 7,000 synaptic connections, and it's the only organism where we've mapped the entire nervous system. Every neuron, every connection. That's it — that's the whole brain. And with those 302 neurons, it navigates its environment, finds food, avoids danger, and adapts its behaviour based on what's working and what isn't.
\nMy project uses those neural dynamics as a behavioural controller for an LLM coding agent. The worm doesn't write code — it doesn't see code, prompts, or any LLM output at all. It sees five simple signals about what just happened (did tests pass? did the build break? how big was the change?) and emits seven parameters that constrain how the AI behaves on the next step — things like mode (diagnose, search, edit, test), temperature, token budget, and how aggressive the edits should be.
\nIt's a closed loop. The AI acts, the outcomes get observed, a reward signal feeds back into the controller, and the controller's internal state shifts. Then the next set of behavioural parameters reflects that changed state.
\nThis sounds ridiculous, I know. But there's a serious idea underneath it.
\nC. elegans has had roughly a billion years of evolution to solve what's fundamentally a control problem — how do you steer behaviour adaptively with minimal hardware? Its nervous system doesn't have the luxury of scale. It can't throw more neurons at the problem. Instead, it's evolved incredibly efficient circuits for things like balancing exploration and exploitation, persisting on a strategy when it's working, and backing off when it's not.
\nThose are exactly the problems a coding agent faces. When should it keep editing? When should it stop and run tests? When should it try a completely different approach? When should it just stop?
\nThe bet is that the control architecture biology evolved for navigating a physical environment might generalise to navigating a software engineering task. Not because worms and code have anything in common — but because the control problem is structurally similar.
\nThere's actually a growing body of research connecting C. elegans neuroscience to artificial intelligence, and I want to be upfront about where my work sits relative to it — because the approach is quite different.
\nMost existing work uses the connectome to build AI. The Elegans-AI project used the connectome's topology to design neural network architectures for image classification. BAAIWorm, published in Nature Computational Science in 2024, built an incredible closed-loop simulation of the worm's brain, body, and physical environment — the worm navigating through a 3D fluid simulation. A recent Frontiers paper on translating C. elegans circuits into AI reviews the whole movement, and their framing captures it well: extracting functional principles from the connectome to design better neural network architectures.
\nAll of that work asks: can the worm's brain make a better AI model?
\nMy project asks something different: can the worm's brain control an existing AI model?
\nThe LLM stays completely untouched. Claude Sonnet does all the reasoning, all the code generation, all the problem-solving. The connectome-derived controller sits outside it and modulates how it behaves — not what it knows. It's a control layer, not a model architecture.
\nBAAIWorm is probably the closest conceptual parallel. They've got the same closed-loop structure — brain modulates behaviour, environment provides feedback. But their environment is physics (fluid dynamics, muscle actuation, chemotaxis). Mine is a git repository with failing tests.
\nI should be really clear about something: I'm not a neuroscientist. I'm not a research scientist of any kind. I'm a software engineer who's spent the last fifteen years building products and leading engineering teams in the NZ tech scene.
\nThis is hobbyist research. Citizen science, if you want a fancier term for it. I had a question that genuinely fascinated me, I had access to open-source tools like the OpenWorm simulation models, and I had evenings and weekends. The FlyWire connectome project showed that amateur contributors can make real contributions to neuroscience — they credited volunteer researchers as authors on peer-reviewed papers. That gave me confidence that you don't need a PhD to ask interesting questions.
\nI'm going to share my findings honestly — including every limitation, every thing I got wrong, and every place where the data doesn't support the conclusion I wanted. I've run 167 experiments across three difficulty levels. The experimental pipeline is solid. But the sample sizes are small, and most individual comparisons aren't statistically significant at p<0.05. I'll be upfront about all of that.
\nThis post is the first in a series where I'll walk through the entire c302 research project — what I built, what I found, and what it might mean.
\nThe series will cover the experimental results across three difficulty levels — from a trivial single-function task where every controller succeeds, through multi-file coordination where differences start appearing, to regression recovery where the adaptive controller's error detection actually matters. I'll share the actual data, the traces, the cost breakdowns, and the honest limitations.
\nAfter that, the really interesting bit — Phase 2, where the hand-tuned synthetic controller gets replaced with actual connectome-derived neural dynamics from the c302 simulation. That's where the neuroscience question gets answered: does biological provenance actually add something that hand-tuning can't replicate?
\nThe tools are all open source. The question — whether a billion years of evolved neural architecture can improve how we control AI systems — is genuinely one of the most interesting things I've worked on.
\n","date_published":"Wed, 18 Mar 2026 00:00:00 GMT","image":"https://jonno.nz/og/what-if-a-worm-could-make-ai-agents-smarter.png"}]}