![\"Two](\"https://jonno.nz/img/posts/ukraines-drone-advantage-is-an-engineering-loop-flight-profile.svg\")
Ukraine has turned drone warfare into an engineering feedback loop.
\nA crew flies a system until Russian electronic warfare finds a weakness. Operators report the failure. Engineers change the radio, navigation or software, then send a new batch back to the front.
\nI spent years building teams that shipped software several times a day. The mechanics feel familiar: release something small, inspect the result and fix what broke.
\nThe consequences in Ukraine sit on another scale. A failed software release gives you an incident channel and a rough morning. A failed drone may expose its operator or leave a unit without observation.
\nThe engineering impresses me. The reason it exists is bloody grim.
\nIn May 2026, KettleTech Labs released footage of a fixed-wing Hornet drone hanging beneath a helium balloon. The balloon climbed to about 8,250 metres, released the aircraft and let it stabilise into a glide.
\nReports claimed the Hornet finished with 95% battery charge and travelled 42 kilometres. That sounds amazing, until you compare the reports.
\nDefence Blog says the balloon carried the Hornet 42 kilometres before release. Defense Express says the drone landed 42 kilometres from its launch point after gliding.
\nThose descriptions cover different parts of the flight.
\n
A 42 kilometre glide from 8.25 kilometres up would require a glide ratio a little above 5:1. A fixed-wing aircraft can manage that. Wind, release position and the missing telemetry still matter.
\nThe same reports put the Hornet’s normal range between 150 and 200 kilometres, then estimate a balloon-assisted range between 190 and 300 kilometres. The manufacturer has not published those numbers.
\nThe footage supports one successful release test. It does not prove that Ukrainian crews have launched Hornets from free balloons over Russian targets.
\nNews reports keep using “balloon”, “aerostat” and “drone carrier” for three different systems.
\nUkraine has used tethered aerostats as radio relays and sensor platforms for years. A cable holds the balloon above friendly territory while supplying power to the equipment underneath it.
\nAerobavovna CEO Iurii Vysoven told IEEE Spectrum that his company had deployed dozens of these systems by April 2025. He said a radio repeater raised 500 metres could cover a radius of around 80 kilometres. That figure comes from the company, though the benefit follows basic radio geometry: lifting an antenna extends its line of sight.
\nThese aerostats let crews place the ground station farther from the front. They can also carry cameras and radio-direction equipment.
\n![\"Three](\"https://jonno.nz/img/posts/ukraines-drone-advantage-is-an-engineering-loop-aerostat.jpg\")
Ukrainian Special Operations Forces raising an Aerobavovna ARB12 aerostat, August 2024. Photo by Vysoven, CC BY-SA 4.0. Worth noting what you are looking at: the photographer is the manufacturer's own founder, which is the same source the deployment numbers come from.
\nA second design turns the tethered aerostat into an interceptor tower. Photos published in March 2025 showed a thermal camera and a fixed-wing interceptor mounted under an Aerobavovna balloon. Militarnyi reported that an operator could release the interceptor after the camera detected an incoming Shahed.
\nVysoven told IEEE that engineers had only started those trials. Public photos proved that the prototype existed. They did not prove a working air-defence network.
\nThe third system cuts the tether and lets the wind carry the balloon east. It may carry a decoy, radio relay or another aircraft.
\nEuromaidan Press reported that Ukrainian forces had sent more than 1,000 free balloons into Russia. A retired Ukrainian colonel supported the account, alongside operators who withheld their names. Russian monitoring channels also reported balloons during a large drone raid in September 2025.
\nUkraine has not published an official count. I would treat the 1,000 figure as a credible report rather than a confirmed total.
\nA fourth idea sits in development. In June 2026, a Ukrainian company presented DART, a small balloon-launched rocket designed to continue on a fixed course after switching off its navigation receiver. The company said that would deny radio jammers a signal to corrupt during the last part of flight.
\nMilitarnyi published developer renders and specifications. The developer also said DART still needed Ukrainian military codification. It belongs in the prototype column for now.
\nThe airframe gets most of the photos. The communications and navigation stack decides whether it reaches useful airspace.
\nAn FPV pilot needs a low-latency command link and a video feed. A fixed-wing strike drone may combine satellite navigation with inertial sensors, terrain matching or visual odometry. An onboard computer can track the selected object once the radio link drops.
\nRussian electronic warfare attacks the command link, video return and satellite navigation. Russian units also use radio emissions to locate drone crews. Ukrainian jammers can disrupt friendly aircraft if units fail to coordinate their spectrum use.
\nRUSI’s February 2025 field research found that 60–80% of Ukrainian FPV drones failed to reach their targets in the sectors its researchers examined. Operator skill, weather and electronic warfare changed the rate.
\nThe same report estimated that tactical drones caused 60–70% of damaged and destroyed Russian systems. Ukrainian officers still told the researchers that they needed artillery. Drones could find or immobilise a vehicle, while artillery delivered a heavier effect in poor weather and under dense jamming.
\n![\"Two](\"https://jonno.nz/img/posts/ukraines-drone-advantage-is-an-engineering-loop-attrition.svg\")
Fibre-optic FPVs solve the radio-link problem with a physical strand of glass that unwinds behind the aircraft. A jammer cannot corrupt commands or video travelling through that cable.
\nThe cable brings its own problems. A Swedish Defence Research Agency study found that the spool adds weight, reduces endurance and can snag on terrain. The fibre carries data rather than electrical power, so the drone still depends on its battery.
\n![\"A](\"https://jonno.nz/img/posts/ukraines-drone-advantage-is-an-engineering-loop-fibre-fpv.webp\")
A fibre-optic FPV under test, February 2025. The spool canister in the operator's palm is the endurance cost the FOI study describes: it is nearly the size of the airframe carrying it. Photo by ArmyInform, CC BY 4.0.
\nEngineers have also pushed more work onto the aircraft.
\nReuters reported in October 2024 that Ukraine had deployed dozens of domestic automation systems. NORDA Dynamics said it had sold more than 15,000 copies of software that lets a pilot select an object through the camera, then hands the final approach to computer vision.
\nCall that terminal guidance. A human chooses the target before the software tracks it.
\nUkraine’s Defence Ministry described a more advanced interceptor in June 2026. The ministry said the system automates 95% of an interception cycle. An operator watches the air picture, selects a target and authorises engagement. The interceptor handles guidance, identification and tracking after that command.
\n“AI drone” covers a huge range of capability, from keeping a truck centred in the camera to coordinating several aircraft. Treating all of it as autonomous target selection makes the technology sound more mature than the evidence supports.
\nUkraine connects these aircraft to a wider software system.
\nNATO describes DELTA as a cloud-based integration platform and national data lake. It combines reports from drones, radars, satellites and ground units into a shared battlefield view.
\nUkraine added Vezha for drone-video streaming and Mission Control for flight planning. Mission Control also helps units avoid sending several FPVs through the same patch of spectrum.
\nThe result looks less like a fleet of remote-control aircraft and more like a distributed application. Sensors create tracks. Commanders assign work. Drone crews execute missions, then report what happened.
\nUkraine has wired those results into procurement.
\nA 2025 CSIS study based on more than 50 interviews describes a commercial-first system. Private companies fund working prototypes. Military units test them, buy useful models and send feedback to engineers without waiting for a multiyear programme.
\nBy January 2026, Brave1 Market gave participating manufacturers a dashboard showing confirmed hits, target types, operating distance and product rankings. ArmyInform documented the dashboard and the data available to suppliers.
\nIn June, Ukraine’s Defence Ministry said military units had ordered more than 500,000 drones through Brave1 Market. Ordered does not mean produced or delivered, though it shows the scale of the purchasing system.
\nI started my engineering career in support at Vend. The person sitting closest to the failure often had the best product signal. You lose that signal when it passes through five teams and a quarterly planning process.
\nUkraine has shortened that route from operator to engineer.
\n![\"The](\"https://jonno.nz/img/posts/ukraines-drone-advantage-is-an-engineering-loop-loop.svg\")
Brave1 appears twice because it does two jobs: it carries combat results back to suppliers as data, and it is where units order what works. The same platform closes the loop in both directions.
\nSpeed creates mess as well.
\nAnother CSIS study found more than 550 unmanned systems on one government-supported marketplace. Units gained choice, while maintainers inherited incompatible parts, firmware and training requirements.
\nCentral procurement can take months and distort feedback before engineers receive it. Unit-level purchasing moves faster, though it weakens standardisation and long-term planning. Ukraine now uses digital marketplaces and combat data to keep the speed while reducing some of that fragmentation.
\nThe metrics need scrutiny too. A confirmed strike makes a clean dashboard event. A drone lost to jamming may produce little data. Units can favour targets that generate more purchasing points. Manufacturers will optimise around whatever the system measures.
\nThe balloon test fits this engineering culture. It combines cheap lift, an existing fixed-wing drone, automatic release and onboard stabilisation. Engineers can test each part without waiting for a new aircraft programme.
\nWind still controls the free balloon’s route. Weather can cancel a launch window. The drone needs navigation and, in many missions, a communications path after release. A balloon can save battery and add altitude, though it cannot remove those constraints.
\nThe Hornet footage leaves one basic detail unresolved: did the balloon drift 42 kilometres before release, or did the drone glide that distance afterwards?
\nThe outlets disagree. KettleTech Labs has the telemetry. The public has a video, several contradictory captions and no confirmed combat release. For now, that is where the evidence stops.
\n![\"The](\"https://jonno.nz/img/posts/ukraines-drone-advantage-is-an-engineering-loop-evidence.svg\")
Keith Miller got two parking fines from a camera in Miramar. He got them\ncancelled by proving his own innocence.
\nMiller shopped at New World Miramar in December, then visited again in January.\nSmart Compliance Management runs the number plate cameras in the car park. Its\nsystem missed one departure and joined the entry from one trip to the exit from\nanother. It billed him for the hours between them.
\nHe told Stuff\nthe system had "critical flaws" and caught too many innocent people. His appeal\nworked because he could show his car parked outside his house between the two\nvisits.
\nI spent six years working on billing platforms at Vend. Once software writes a\nnumber onto an invoice, support treats it as fact. The angry customer reaches\nthem, while the logs and assumptions sit somewhere else.
\nSmart Compliance held the camera data and gave Miller the homework.
\n![\"An](\"https://jonno.nz/img/posts/prove-the-machine-wrong-anpr-camera.jpg\")
ANPR camera on a parking services truck. Photo by\nMbrickn,\nCC BY 4.0, via Wikimedia\nCommons.
\nSmart Compliance's setup does two jobs. A camera model reads the plate, then an\nordinary billing rule subtracts the entry time from the exit time.
\nPlate recognition has an error rate because another car can block the view or\ndirt can hide a character. Drivers in Belmont, County Durham hit the same\nfailure in 2022, at a car park run by the same company. The BBC reported\nhundreds of £60 charges because\nthe camera "thinks the car was there and it definitely wasn't".
\nThe billing rule still returns a number when the event log is missing a\ndeparture. The team building that rule has to decide what a gap means. This one\ntreated the log as complete and sent a breach notice.
\n![\"Two](\"https://jonno.nz/img/posts/prove-the-machine-wrong-parking-log.svg\")
Drivers can appeal, although the process costs time they may not have. Older\ndrivers in Belmont told the BBC they paid because arguing cost more than the\nfine.
\nSection 137 of our\nEvidence Act 2006\ncovers evidence produced by a machine, device or technical process. If that kind\nof system ordinarily does what a party claims, a court presumes it did so on\nthis occasion unless someone supplies evidence to the contrary.
\nMiller's parking appeal never reached a court, so section 137 did not decide his\nfine. Smart Compliance followed the same default: accept the output, then ask\nthe accused person to find the contrary evidence.
\nThat presumption suits a speedometer or a breathalyser with a known calibration\nprocess. Software can produce evidence by applying a rule to incomplete data. A\nmodel can also return a score that no physical instrument measured.
\nEngland and Wales use a similar common-law presumption. The Post Office relied\non data from its Horizon accounting system to prosecute postmasters for losses\nthat did not exist. Bugs in Horizon showed phantom shortfalls, and people who\ncould not inspect the system pleaded guilty, paid the money or went to prison.
\nThe\nHorizon inquiry found\nthat Post Office staff knew the system could make errors while the organisation\nmaintained the fiction that its data was accurate. Courts convicted many\nhundreds using Horizon evidence, and the Post Office held thousands liable for\nlosses that never happened.
\nThe inquiry also heard about 13 people whose families attributed their deaths by\nsuicide to Horizon. Sir Wyn Williams said he could not make a definitive causal\nfinding, but he would not rule it out.
\nAustralia's Robodebt scheme used arithmetic too. The government divided annual\nincome by 26 fortnights and treated the result as a debt. Its Royal Commission\ncalled the scheme\n"a crude and cruel mechanism".
\nAuditors could inspect the rules behind both systems. The people accused by them\nstill lacked the access and money to do it.
\nFacial recognition can run as designed and return the wrong person.
\nDetroit police ran grainy shop security footage through facial recognition,\nselected Robert Williams, then arrested him outside his house in front of his\nfamily. The city\nsettled his case\nand changed its policy. Police now need independent evidence before they can\nturn a face match into an arrest.
\nPorcha Woodruff was eight months pregnant when Detroit police arrested her over\na carjacking. She spent ten hours in custody and had contractions after her\nrelease. Prosecutors dropped the charges.
\nThe\ncourt order in her civil case\nrecords the chain. A facial search returned 73 candidates. An analyst chose\nWoodruff as the lead, and two colleagues approved the choice. The carjacking\nvictim then picked her from a photo lineup. Police got a warrant.
\nThe judge called the arrest troubling, then dismissed Woodruff's claims at\nsummary judgment because her lawyer had not shown that the officer lacked\nprobable cause under current law. Woodruff appealed, and\nthat case remains pending.
\nSeveral people turned one of 73 candidates into probable cause. A malfunction\ntest would miss the blurry source image and everything police did with the\ncandidate list.
\n![\"A](\"https://jonno.nz/img/posts/prove-the-machine-wrong-checkout-camera.jpg\")
Camera and live screen at a supermarket self-checkout. Photo by\nFolkestonesurvey,\nCC BY-SA 4.0, via Wikimedia\nCommons. Cropped.
\nFoodstuffs North Island scanned 225,972,004 faces across 25 supermarkets during\nits six-month trial. The system produced 1,742 alerts, and staff confirmed 1,208\nmatches.
\nThe system falsely matched Te Ani Solomon, a Māori woman shopping at New World\nWestend in Rotorua on her 47th birthday. She\noffered staff three forms of ID.\nThey still made her leave. Foodstuffs apologised and called it human error.
\nFoodstuffs blamed human error. It chose the model and threshold, while store\nstaff built the watchlist and acted on alerts.
\nThe trial started with a 90% match threshold. After two harmful\nmisidentifications, Foodstuffs raised the minimum for staff action to 92.5% and\ntightened its process. The Privacy Commissioner found no similar harmful\nincident after those changes.
\n![\"Foodstuffs](\"https://jonno.nz/img/posts/prove-the-machine-wrong-threshold.svg\")
The\nCommissioner's inquiry\nfound that the trial complied with the Privacy Act. It estimated a 16% reduction\nin serious harmful behaviour, and warned readers not to apply that figure beyond\nthe trial. Two trained staff had to verify an alert before anyone acted.
\nRetail workers get assaulted, and the trial suggests the system helped. It also\nput innocent customers in front of staff who thought a computer had already\nidentified them.
\nFoodstuffs still decides how many false matches it will tolerate, and a customer\npays for each one.
\nThe UK Ministry of Justice opened a call for evidence in 2025 after Horizon. It\nproposed separating material a device captures from evidence software generates.\nA photograph would sit on one side. An accounting balance or automated fraud\nscore would sit on the other. The call has closed, and the government has not\npublished a response.
\nOur\nLaw Commission has started preparatory work on automated government decisions.\nIt says New Zealand has no single legal framework for agencies using these\nsystems.
\nSection 137 belongs in that work. Anyone who wants to use a generated score\nagainst a person should show where it came from and what they did to check it.
\nKeith Miller had a photo of his car at home, so he got his $85 back. I'd rather\nSmart Compliance proved the stay before it sent the letter.
\n","date_published":"Tue, 14 Jul 2026 00:00:00 GMT","image":"https://jonno.nz/og/prove-the-machine-wrong.png"},{"id":"https://jonno.nz/posts/i-parsed-the-nz-statute-book/","url":"https://jonno.nz/posts/i-parsed-the-nz-statute-book/","title":"I Parsed Every Law New Zealand Has Ever Passed","content_html":"The research notes said New Zealand's legislation XML records its amendment history in machine-readable attributes. I built my first parser against those attributes. They do not exist.
\nNot "exist but renamed". Not "exist in some files". Zero occurrences, in any of 38,064 files, in either version of the official schema. The real history lives in little <history-note> blocks of nearly plain English: dates written out like "2 July 2001", the amending act named by title only, no identifier of any kind, like a Parliament that never expected anyone to check. Day one of the build, and the map I'd been handed described a country that wasn't there.
Some scope before we go on. New Zealand publishes its whole statute book as open data, free of copyright: every public act and every regulation made under one, 15,306 works in all. Strictly, that's every law the official archive still publishes rather than every law ever passed, so the title is doing what titles do, and now you know. Parsed out, those works yield 241,456 amendment events: every recorded edit to every act and regulation, what it did, which act did it, and when. The oldest is dated 5 October 1872. The newest landed in June 2026. Nobody had turned any of this into a churn metric before, which is how a weekend curiosity became the project.
\nFindings later. Caveats first, because on this dataset the caveats are half the findings.
\nOne event in my graph is one provision-level operation: a single section, subsection, heading or defined term inserted, repealed, substituted or amended. That sounds like a clean unit. Three things ruin it.
\nBig numbers are usually one act, not many decisions. The busiest day in the statute book's history is 28 October 2021, with 4,619 recorded changes, and 4,283 of them came from a single statute, the Secondary Legislation Act 2021, a mass administrative reclassification. The Income Tax Act's worst year (1,544 changes in 2009) was about 79% one omnibus tax bill. Whenever you see "amended X times", read it as "X operations, mostly from a handful of acts", never "X separate choices".
\nChanges arrive on a timetable. Since 2008, a quarter of every change to New Zealand law took effect on just four days of the year: 1 January, 1 April, 1 July or 1 October. 1 July alone carries 15,864. Commencement dates are a drafting convention, not evidence of haste, but it means any "three edits every two days" cadence you compute is an average over a process that actually moves in quarterly bursts.
\nEven "amended N times" depends on a convention you have to pick. Is a repealed subsection an amendment? By the convention my tracker publishes (insertions, substitutions and textual amendments), the Income Tax Act 2007 has 11,577 recorded amendments, the most in the country. Count every operation including the provisions repealed or revoked out of it and you get 14,294. Both numbers are defensible. Neither is wrong. You just have to pick one, say so, and never mix them, and most public claims about "how often law changes" do not tell you which one they picked.
\nThat last one bit me in miniature. The Water Services Entities Act was amended 832 times in August 2023 by its own authors. Or 820 times, if you exclude the twelve provisions that were repealed rather than rewritten. The tracker now says "recorded changes" instead of "amendments" specifically to stop the two conventions colliding in one sentence.
\nThe bulk XML archive lives on the old legislation website, the one that got replaced in March and now carries a polite notice that it will be switched off "when the new website is performing well". The new site has no bulk archive. Reading that sentence is what turned this from a weekend idea into a now-or-never job: I mirrored the lot, 38,064 files, 16 gigabytes, at a deliberately polite request rate spread over a couple of days. The site's firewall has opinions about impolite scripts, and I had no intention of being the reason the archive went away early.
\nMy first run spent an hour dutifully downloading regulations about walnut export licensing, because I'd built the work queue last-in-first-out without thinking about it, which is the most me bug imaginable.
\nA history note reads roughly like this: Section 5(1): amended, on 2 July 2001, by section 149 of the Something Something Act 2001. A date spelled out in words. An operation verb. A citation by title, no ID, to an act that might be anywhere in 154 years of legislation. The parser's job is to turn tens of thousands of those into graph edges: this act amended that one, on this date, in this way.
\nTwo things about that went better than anyone deserves. Every one of the 15,306 works parsed without a single XML error, which says something lovely about the Parliamentary Counsel Office's data discipline, whatever the rest of this series implies about everyone upstream of them. And 93.7% of the history notes resolved cleanly into the graph. The stragglers are mostly old acts cited by title in eras of creative spelling, and they sit in a review queue rather than in the numbers.
\nBefore publishing anything, the graph had to reproduce facts already on the public record: the Resource Management Act's long saga, the bright-line test's ping-pong, the Three Waters repeal. It did. Then I let it talk.
\nThe dataset holds 49,639 provision-repeal events: individual sections struck out of living acts. Treat each one as a death, take the age of the parent act at that moment, and the median is fourteen years.
\nBe careful with that number, because the loose version reads better and I've used it myself: "a law is typically fourteen years old when parts of it get struck out." The precise version is event-weighted: heavily hacked-about acts contribute thousands of deaths each, so the median tells you the age of the typical act at the typical amputation, not how long a law survives before its first repeal. The per-act survival curve (time to first strike-out, censoring the untouched) is the proper follow-up and it's on the list.
\nEven the honest version earns its keep, though. New Zealand makes thirty-year infrastructure commitments, governs them on a three-year electoral clock, and writes them into laws whose typical strike-out happens at age fourteen. Those three numbers do not fit together, and the misfit is what the rest of the series is about.
\nAmendment events to acts per completed parliamentary term since 2008: John Key's three terms ran 13,426, then 15,144, then 14,584. Jacinda Ardern's two ran 17,538 and 16,818. The current term sits at 12,710 with months still on the clock. Different parties, different decades, different crises, same band. Whoever you came to convict, the chart declines to cooperate: the churn isn't red or blue, it's the machine.
\nThe counter-fact cuts the same way. New Zealand has a reputation as the west's fastest repealer, but by share of edits that delete law, the current government is the lowest since 2008 at 13.8%, and Key's second and third terms were the highest, both above 18%. The reputation comes from a handful of flagship reversals done at speed and under urgency, not from bulk deletion. About one in five operations across the whole dataset removes law rather than adding it; Parliament runs a permanent demolition crew alongside the builders.
\nIf you want the politics proper, that's Part 1 (what the cancelled projects cost) and Part 2 (why the machine is built for whiplash), and a version of the story ran in The Spinoff. This post is the appendix that wouldn't fit: the pipeline those pieces stand on.
\nThe data keeps coughing up side quests too. The oldest act still in force dates to 1865, and the current government has amended a clutch of statutes written in 1908. The Ombudsmen Act 1975 has been touched by 311 different other acts, the most cross-referenced law in the country, because every new public body gets bolted onto its schedule. And there's a whole register of provisions Parliament passed that no government ever switched on, including the internet-disconnection penalty from 2011's "Skynet" copyright law, fully drafted and dormant for fifteen years. That one's its own post.
\nEverything above is live at whiplash.jonno.nz: the per-term chart, the most-amended leaderboard, a lane-by-lane view of the statute book, and a map of thirty cancelled projects with a scrubbable timeline. The counting rules are published next to every number, because after the 820-versus-832 business I trust a figure exactly as far as I can see its convention.
\nThe pipeline is deliberately boring: a mirror script, the parser, a SQLite graph, static JSON aggregates the site serves. No framework survived contact with the problem. All of it, mirror to graph to aggregates, is at github.com/jonnonz1/nz-statute-book, and the source archive it reads from is public and copyright-free, so you can check every number in this post against the same primary source I used.
\nGo on.
\n","date_published":"Sun, 05 Jul 2026 00:00:00 GMT","image":"https://jonno.nz/og/i-parsed-the-nz-statute-book.png"},{"id":"https://jonno.nz/posts/your-show-hn-dies-in-7-hours/","url":"https://jonno.nz/posts/your-show-hn-dies-in-7-hours/","title":"Your Show HN dies in 7 hours","content_html":"At 1pm UTC on a Friday last June, an airline pilot posted a Show HN:\ninteractive graphs and globes built from years of his own flight logs. It went\nhuge. 1,539 points, the third biggest Show HN of the entire year. By dinner he\nhad 123 comments.
\nOn day three the thread got 3 comments. In week two it got zero. The third\nbest launch out of more than forty thousand, and the conversation was over\nbefore the weekend ended.
\nI wanted to know whether that shape is the exception or the rule, so I scraped\nevery Show HN from the last 12 months using the\nAlgolia HN API: 41,301 posts, plus the full\ncomment tree of every launch that got at least ten comments. About 100,000\ncomment timestamps. The scraper, the analysis, and the data are all in\none repo if you want to\ncheck my working.
\nThe pilot's flatline is the rule. The only unusual thing about his launch is\nthat it had a peak.
\nI went in to measure decay speed. The distribution of outcomes stopped me\nbefore I got there.
\nThe median Show HN in my 12 months of data earned 2 points and 0 comments.\n61.7% of launches got no comments at all, and 78.9% got one or none. A\nsingle upvote from a stranger puts you in the top third.
\n![\"Histogram](\"https://jonno.nz/img/posts/hn-attention-outcomes.svg\")
The distribution is a power law with a brutal knee. The 90th percentile is 8\npoints. Fewer than 2% of launches clear 100. Picture your launch day and you\npicture the front page. Picture two points and silence instead: that's the\nmedian experience, by a wide margin.
\nI've launched products before (Shopim in 2014, Spotrisk in 2020) and I still\nfound these numbers confronting. Every founder I know treats the launch as\nthe milestone. The milestone, statistically, is a shrug.
\nHN doesn't publish vote timestamps, so I'm using comment timing as the proxy\nfor attention. That's a real limitation and I'll come back to it, but\ncomments are the visible half of engagement, and they're what founders\nrefresh the page for.
\nFor the 2,066 launches with at least ten comments, I built each launch's\ncumulative comment curve: what share of its lifetime comments had arrived by\neach hour. The median curve crosses 50% at 7.2 hours.
\n![\"Median](\"https://jonno.nz/img/posts/hn-attention-hero.svg\")
Half of everything anyone will ever say about your launch is said before the\nfirst workday ends. 90% is done by hour 26. Even the slow quartile of\nlaunches crosses halfway by hour 18.
\nThe mechanism is no mystery. HN's ranking formula divides a story's points by\nits age raised to the power 1.8, which Ken Shirriff documented years\nago.\nTime sits in the denominator with a bigger exponent than votes get in the\nnumerator, so gravity wins no matter how good your day is going. The front\npage is a conveyor belt into a furnace, by design. It's why HN stays\ninteresting, and it's why your launch can't stay visible.
\nI sanity-checked the half-life two ways (median of per-launch crossing times,\nand the crossing of the median curve) and they agree within 20 minutes.\nExcluding founders answering their own threads, 19% of all comments, moves\nthe number by four minutes. The 7-hour figure is not an artefact of chatty\nfounders.
\nMy first guess was that big launches would decay slower. A front-page hit\nkeeps earning impressions, so surely the conversation stretches out.
\nIt doesn't. The top decile of measurable launches (268 points or more, the\nyear's genuine hits) has a median half-life of 7.6 hours. Everything below\nthat decile: 7.1 hours. The biggest launches of the year run on the same\nclock as a launch that scraped together ten comments.
\n![\"Small](\"https://jonno.nz/img/posts/hn-attention-top12.svg\")
Look at the top 12 launches of the year, the ones every founder dreams about.\nHomebrew 6.0.0: half done in 8 hours. The 3,346-point monster at number one:\nhalf done in 6.3. Two of the twelve flatlined at launch and only took off a\nday or more later, which is HN's\nsecond-chance pool\ndoing its thing, where moderators re-launch overlooked stories with a fresh\ntimestamp. The rescue mechanism exists because without it, nothing gets a\nsecond look.
\nSuccess multiplies how many people show up. It does nothing to change when\nthey leave.
\nFor the median launch, 4.2% of lifetime comments arrive after hour 48. Pool\nevery comment in the dataset together and the number rises to 17%, because\nthe giant launches have longer conversations in absolute terms. Either way\nyou cut it, the second-day cliff is real: 71% of launches are more than 90%\nfinished by hour 48.
\n![\"4.2%](\"https://jonno.nz/img/posts/hn-attention-tail.svg\")
And comments are the durable end of attention. Traffic dies faster.\nHarrison Broadbent's front-page traffic\ndata\nshows over half the visitor spike gone within 8 hours of submission. The\ncomment thread is the long tail. The clicks are gone by tea time.
\nThe takeaway I keep landing on: the launch spike is real, and it's worth\nhaving, and it cannot be your distribution plan. It's 48 hours. You can't\nbuild a company on 48 hours of attention.
\nWhat worked for the products I've been involved with was never the spike. It\nwas the boring compounding stuff: showing up in the places your users\nalready are, week after week, shipping visibly, and giving people a reason to\ncome back after the thread dies. The launch is the starting gun, and most of\nus have been treating it as the race.
\nFull disclosure: this analysis had a motive. Staring at forty thousand\nlaunches that got a median of zero comments is a big part of why I'm\nbuilding Shipyard, a feed where you post what\nyou've built and it keeps collecting honest reviews long after launch day,\ninstead of vanishing down page 40 of /newest.
\nIf the numbers above made you wince, Shipyard is my answer to them. The data\nstands on its own either way, and if you only take one thing from this post,\ntake the 7 hours, and plan your next launch knowing the clock is already\nrunning.
\nEverything is reproducible from the\nrepo with make reproduce:\nevery number above traces to a named function in analyze.py, and the\nscraped data ships in the repo. The corpus is every story tagged show_hn on\nthe Algolia HN API, posted 18 June 2025 to 18 June 2026, so every story has\nat least 14 days of comment history. "Lifetime comments" means live comments\nwithin 14 days of posting.
Caveats, stated plainly: comments are a proxy, and comments are not votes and\nnot traffic. The decay curves only describe the 5% of launches with ten or\nmore comments, since the median launch has too few comments to have a curve\nat all. The API excludes flagged and dead posts, which makes the medians\nkinder than reality. And HN's second-chance pool re-timestamps a small number\nof stories; 99 comments that predate their re-stamped story were dropped and\nare counted in the repo's sanity checks.
\n","date_published":"Wed, 01 Jul 2026 12:00:00 GMT","image":"https://jonno.nz/img/posts/hn-attention-hero.png"},{"id":"https://jonno.nz/posts/fastest-repealers-in-the-west/","url":"https://jonno.nz/posts/fastest-repealers-in-the-west/","title":"The Fastest Repealers in the West","content_html":"In 1979 a law professor named Geoffrey Palmer wrote that New Zealand had the fastest lawmakers in the West. In 2024, he updated the diagnosis: "We've gone from being the fastest lawmakers in the west to the fastest repealers in the west."
\nPalmer would know. He went on to be Prime Minister, and the machine he described in Unbridled Power? is the one we still run: one chamber of Parliament, no upper house, no written constitution, and almost nothing a government with a one-vote majority can't do before lunch. Most democracies have speed bumps. We bought the racing package.
\nPart 1 of this series counted the bill: well over a billion dollars in directly sunk and cancellation costs from a single change of government, plus billions more spent redoing and replacing. This part is about why it keeps happening, because the answer isn't that we elect unusually flighty people. The answer is the company structure.
\nStay with the picture from Part 1: New Zealand as a company whose entire exec team faces replacement every three years. Now look at the governance around that team.
\nMost companies of consequence have a board that long-horizon decisions must clear, a constitution that takes more than a staff vote to change, and shareholders who can force a special resolution. NZ Inc has none of that. Parliament is one chamber, its decisions need 61 votes out of 120, and the few protected rules we do have (six electoral provisions, entrenched since 1956) don't cover a single spending commitment, infrastructure plan, or health strategy. A hospital programme and a tweak to dog registration fees enjoy exactly the same legal durability: none.
\nThe three-year term turns that freedom into a metronome. Section 17 of the Constitution Act gives a government roughly 36 months, and anyone who's run a delivery team can sketch the rhythm from there. Year one, ship something visible. Year two, panic about the things that aren't visible yet. Year three, campaign. A 2024 study in Public Choice tracked 22 democracies over two decades and found exactly this shape: tax reforms cluster right after elections and evaporate as the next one approaches. Every democracy has the cycle. Ours just spins faster, with fewer brakes, and the 100-day plan has hardened it into ritual: each new exec team now publishes a list of the previous team's projects it will kill, and gets graded on killing them quickly.
\nSpeed shows up in the record as something with a technical name: urgency. It's the parliamentary setting that compresses or skips the normal stages of making law, including select committee, which is the one stage where the public, experts, and officials get to find the bugs.
\nEvery engineer reading this knows what shipping without review does to quality, and you don't have to be an engineer to follow the numbers. In 2025 the House sat 644 hours, the most in decades, and spent 32% of those hours under urgency, also a record (the long-run average sitting load is around 508 hours, per analysis by David Farrar). By Newsroom's count this April, more than half of the government's legislation has had at least one stage under urgency, and around 30 bills have gone through with no select committee scrutiny at all. There's a community-built tracker keeping score in real time: as I write this, it shows 21 separate urgency occasions this term, touching 57% of all bills before the House — 125 of 219.
\nI want to be fair about what those numbers mean. Urgency is sometimes legitimate, and every government uses it. But a third of the legislative year in skip-review mode isn't an exception regime. It's the workflow. And law made at that speed is exactly the law most likely to need repealing, which feeds the cycle we counted in Part 1.
\nHere's my favourite piece of evidence that the problem is structural, because you couldn't script it better.
\nThe obvious patch is a longer term: four years instead of three, more runway between campaigns. It's one of the rare ideas with support across the aisle, and this Parliament actually had a bill for it, the Term of Parliament (Enabling 4-year Term) Legislation Amendment Bill. Voters had said no twice before, emphatically (68.1% against in 1967, 69% in 1990), so the plan was to do it properly: select committee, a binding referendum, the works.
\nThe select committee stripped out the bill's novel design. The referendum got shelved on time grounds. And in February this year the bill formally stalled, unfinished, as the parliamentary clock ran down toward the election.
\nThe fix for the three-year term ran out of time in a three-year term.
\nYou might reasonably ask: can't anything be made to stick? Two case studies, and they're the two edges of the same blade.
\nThe Zero Carbon Act passed in 2019 with 119 of 120 votes, about as close to corporate consensus as this country produces. It survived, technically. But in October 2025 the government cut the 2050 methane target so far that the top of the new range is the bottom of the old one, despite the Climate Change Commission advising movement in the opposite direction. Climate policy consultant Dr Christina Hood put it plainly: she was not aware of any government, anywhere, that had weakened an existing legislated domestic climate target. Near-unanimity bought the framework six years of life before the dial got turned anyway.
\nThe other case is quieter and costs more. The NZ Super Fund exists to pre-pay the retirement of people who are currently in school: contributions go in now, compound for decades, and pay out when today's eight-year-olds retire. It's the single most generational financial commitment on the country's books. In 2009 a new government suspended contributions, and they stayed suspended for eight years. The fund survived; the suspension still happened. The Guardians' own estimate of what it cost, in missed contributions and the returns they would have earned by the time payments resumed in 2017, is around $24.5 billion.
\nThat's the number I'd put on a billboard, because it makes the stakes concrete in a way potholes never will. One pause, made inside one three-year window under fiscal pressure, quietly compounding into a $24.5 billion hole in a fund for people who couldn't vote on it. The light rail fiasco cost $228 million and got years of headlines. The Super Fund pause cost a hundred times more and most people couldn't date it within five years. The most expensive churn is the kind nobody films.
\nBefore anyone fits this series for a constitutional reform t-shirt, the other side of the ledger deserves its say, because it's not weak.
\nIn a country with one chamber and no written constitution, the three-year election is close to the only real check we have. Shorten the leash because governments misbehave, runs the argument, and don't be surprised when a bad government uses a four-year leash to entrench worse. Hipkins supports a four-year term; so does Seymour, eventually; the voters, twice asked, have preferred to keep their grip.
\nLocking things in has its own pathologies. Supermajority requirements hand a veto to whoever can muster 31% of the House, which is how minority blocking works everywhere it exists. And when Parliament did once try to entrench actual policy (an anti-privatisation clause in the Three Waters legislation, 2022, passed under urgency at 60%), constitutional lawyers across the spectrum called it a dangerous precedent and it was unwound within weeks, with the then Prime Minister conceding the mistake. Entrenchment, it turns out, is a weapon both teams can fire.
\nAll of which leaves a genuinely uncomfortable shape: the accountability mechanism and the churn engine are the same machine. You can't simply slow it down without asking who benefits from the slack.
\nSo if term length alone won't fix it, and entrenchment cuts both ways, what's left? My answer is unglamorous: you start by measuring it. No one in New Zealand currently publishes a churn metric — how much of each Parliament's lawmaking is spent unpicking the last Parliament's work, which sectors get whiplashed hardest, how long a law actually lives. You can't manage what you don't measure, and right now nobody's even measuring.
\nSo I measured it. I downloaded the entire statute book, all 38,064 XML files of it — every act and regulation, reprints and all — and parsed every amendment and repeal back through 2008. That's Part 3, and the numbers are better than I hoped and worse than you'd think.
\n","date_published":"Fri, 19 Jun 2026 00:00:00 GMT","image":"https://jonno.nz/og/fastest-repealers-in-the-west.png"},{"id":"https://jonno.nz/posts/zero-metres-of-track/","url":"https://jonno.nz/posts/zero-metres-of-track/","title":"Six Years, $228 Million, Zero Metres of Track","content_html":"Auckland Light Rail ran for six years, spent $228 million, and laid zero metres of track.
\nAt its peak the project was paying about $920,000 a week to two engineering firms. Not to build anything. To plan, re-plan, and re-plan again, through three different versions of the route. In January 2024 a new government cancelled it as part of a 100-day plan, and the public got nothing back for a quarter of a billion dollars except some very expensive PDFs.
\nI want to be upfront about what this series is, because the material is political and the timing is an election year. This isn't a political hit job. It's pattern recognition on the public record, and the pattern has both parties' fingerprints all over it.
\nI've spent a little bit of time working with exec teams, at startups and at big companies, and I've seen my share of strategy rewrites. Even one rewrite, done inside one company, with everyone trying their best, costs you about a year. Roadmaps get binned. Half-finished work gets written off. Your best people quietly update their CVs. The new strategy is usually about 70% the old strategy with new diagrams.
\nNew Zealand runs like a company that's contractually required to put its entire exec team up for replacement every three years. Each incoming team arrives with a mandate to show movement in a hundred days, and the fastest way to show movement is to bin whatever the last team was building. The reorg is the announcement. The announcement is the work.
\nAny one of these execs might be competent on their own. The dysfunction is the team, and the team is permanent: it spans parties, decades and ideologies, and it cannot leave a predecessor's decision alone. Meanwhile the shareholders of NZ Inc can't sell their shares. A decent chunk of them are still at primary school.
\nThat's the frame. Now the receipts.
\nThe Cook Strait ferries are the cleanest one. In 2021 KiwiRail signed a fixed-price contract for two new rail-capable ferries, with port upgrades to match. By December 2023 the cost had escalated badly and the incoming government cancelled the lot. By then $507.3 million had already been spent, and the bill kept climbing as it wound down: the final cost came to $671 million, including $222 million to settle the shipbuilding contract with Hyundai. So: $671 million, no ferries. Then we ordered different ferries anyway, for $1.86 billion, due 2029. The old rail-enabled Aratere got retired in the meantime, which severed the Cook Strait rail link for roughly five years.
\nWe paid $222 million to not get ships, and then bought ships.
\nThree Waters took seven years from the Havelock North outbreak to a full legislative framework, then got repealed under urgency in an afternoon in February 2024. You can think the reform was wrong and still notice the maths: the $120 to $185 billion of ageing pipes that justified it didn't get repealed with it.
\nThe Resource Management Act replacement is my favourite, in the way a slow-motion replay of a faceplant is someone's favourite. Parliament spent years building the RMA's successor, passed it in August 2023, and the next government repealed it 122 days later. The replacement's replacement arrived in late 2025, and The Spinoff noted its principles "all but mirror" the laws that got repealed. Thirty-plus years of everyone agreeing the RMA must go, and the RMA is still here, having outlived its own successor.
\nTe Pūkenga merged sixteen polytechnics into one national institute in 2020. On 1 January 2026 ten of them stood back up as independent polytechnics, with the institute itself due to be wound up by the end of the year. Between those two restructures: 855 staff gone, $9.5 million in redundancy payouts, and $325 million allocated to stand up the new polytechs that look a lot like the old polytechs. If you've ever survived a corporate restructure followed by a de-restructure, you know exactly what those six years felt like from inside.
\nThe Smokefree generation law passed in December 2022 as a world first, got studied by half the planet, and was repealed before a single clause took effect.
\nAnd if you want the purest specimen of the whole genre, it's the bright-line test. National invented it in 2015 at two years. Labour stretched it to five, then ten. National snapped it back to two in 2024. Four settings in nine years, on a tax rule that decides what happens when ordinary people sell a house. Both teams, same dial.
\nWorth noting who started and stopped each of these. Labour built ALR, iReX, Three Waters and Te Pūkenga; National stopped them. National invented the bright-line test; Labour extended it; National reverted it. And Labour announced a $785 million harbour cycle bridge in June 2021, then cancelled it itself by October, which proves you don't even need to change the government to get the U-turn. The cycle doesn't care who's driving.
\nTime to add it up, and this is where I need to be careful, because the temptation with a topic like this is to quote the scariest number available.
\nPoliticians on every side do exactly that. When light rail was cancelled, ministers cited builds costing "$15 billion, rising to $29.2 billion". Those are projections of money we now won't spend. Counting avoided future costs as waste is fantasy accounting, and the moment you do it, anyone with a calculator can dismiss your whole argument.
\nSo the rules for this series are boring on purpose. Count money that actually left the public account on things that were then cancelled or reversed: sunk planning, design, contracts, land, plus the penalties paid to walk away. Never count "would have cost" figures. Attribute anything contested to whoever claims it, like Labour's Tangi Utikere putting the full iReX cancellation at $1.16 billion once you include ongoing maintenance, a figure that bundles in things I won't count.
\nOn those rules: light rail's $228 million (the cancellation figure ministers cited; the Cabinet paper itself documents $178.5m, the other $49.5m unexplained), iReX's $671 million all up, the taxpayer share of Let's Get Wellington Moving ($109.7 million of the $180.7 million it spent over nine years, mostly on consultants; Wellington's ratepayers carried the rest), Te Pūkenga's redundancy bill, and the $80 million-plus in public service redundancy payouts across 24 agencies as the workforce swung up by 13,000 and back down again.
\nThat's well over a billion dollars in directly sunk and cancellation costs from a single change of government, counted conservatively. A billion dollars is roughly half a new Dunedin Hospital, a project which has itself been rescoped so many times that 35,000 people marched down George Street about it.
\nI lived on the North Shore through the announcement years, and the ritual became familiar: the render, the press conference at the empty site, the revised render, the quiet line in a later Budget. SkyPath, then the standalone cycle bridge, then neither. Light rail to the airport in three different flavours. Somewhere around 2021 I stopped believing artists' impressions the way I'd stopped believing crypto whitepapers.
\nHere's the backdrop that turns this from annoying into expensive. Te Waihanga's 2022 stocktake found that from 2010 to 2019 New Zealand was the biggest infrastructure investor in the OECD as a share of GDP, while sitting near the bottom 10% of high-income countries for how much infrastructure each dollar buys. We're not under-spending. We're spending like a rich country and delivering like a country that re-litigates its decisions every electoral cycle, into an infrastructure deficit Te Waihanga and Sense Partners size at somewhere between $100 and $210 billion over 30 years.
\nI grew up in Christchurch, and the rebuild taught me what both versions of this look like on the ground. The bits that got locked in and left alone got built; the city got a genuinely world-class convention centre and a repaired arts centre. The bits that kept getting re-litigated dragged on so long they became civic jokes. The stadium took fifteen years of arguments and only opened this year. Same city, same decade, same money. The difference was whether each new set of decision-makers honoured the last set's call.
\nA fair pushback: sometimes cancelling a project is the competent move, and an exec team that can't kill anything is its own kind of disaster.
\nTrue, and the record backs it in places. Treasury papers showed about 80% of the iReX cost escalation was seismic strengthening at the ports, work that's needed no matter whose ferries dock there. Pulling the pin on a runaway project can be governance working, and I'd rather have a government willing to stop a bad bet than one that rides it down out of pride.
\nThe target of this series is narrower: the re-litigation of settled, long-horizon decisions. Ferries wear out on a schedule that doesn't care about coalition agreements. Pipes corrode on chemistry's timetable, not the electoral one. When the underlying problem has a 30-year horizon and the decision-making has a 3-year one, reversal isn't prudence. It's the exec team marking its territory, and the bill lands on shareholders who can't vote yet.
\nSo that's Part 1: the cost, counted conservatively, with the fantasy numbers left out.
\nPart 2 asks why New Zealand specifically does this more than nearly anyone, because it turns out we're rigged for it in ways most democracies aren't, and the man who wrote the book on it in 1979 has updated his diagnosis.
\nPart 3 is where I stop reading the receipts and start pulling them. The entire statute book is published as open data: every act, every amendment, every repeal. I've started parsing all of it, back to 2008, to measure the churn properly. It's a personal project and a few evenings of code, not a royal commission. But nobody else has built it, most of NZ Inc's shareholders haven't been born yet, and somebody should be keeping the receipts.
\n","date_published":"Fri, 12 Jun 2026 00:00:00 GMT","image":"https://jonno.nz/og/zero-metres-of-track.png"},{"id":"https://jonno.nz/posts/what-happens-when-a-worm-drives-claude/","url":"https://jonno.nz/posts/what-happens-when-a-worm-drives-claude/","title":"What Happens When a Worm Drives Claude?","content_html":"A few weeks ago I was on the couch with my eight-year-old, and she was going on\nabout worms. Kids ask the kind of questions we forget to ask as adults, the ones\nthat drop off once we get all mature and sensible. That conversation is the\nreason a worm ended up driving Claude.
\nRight now everyone builds LLM agents the same way. Take a model, bolt more tools\nonto it, hand it a bigger toolbox. I wanted to try the opposite. Leave the model\nalone, and put a brain inside the loop to do the steering.
\nI'll say this up front: it's a fun project, not a serious one. But the thing it\ndoes is genuinely strange, so it's worth a watch.
\n(Can't see the embed? Watch it on YouTube.) All\nthe code is on GitHub if you'd rather pull\nit apart yourself.
\nThink of it as a car. Claude (Sonnet 4) is the engine. A big engine with nobody\nat the wheel. It has five tools: read, grep, write, bash, and run the tests.\nThat's the lot.
\nThe driver is a small controller program. Every tick it looks at what Claude\njust did and decides what Claude does next. It never writes a line of code\nitself. It just shapes the behaviour, the way you'd drive a car without ever\ntouching the pistons.
\nAnd the driver doesn't read the code either. It reads the dashboard. Five\nnumbers, every tick, and only these five: how many tests are failing, the share\npassing, how many files Claude has touched, how many ticks have gone by, and the\nlast tool it used. That's the whole view of the world.
\nOut the other side there are seven knobs. The big one is the gear: diagnose,\nedit, test, or stop. Then a handful more, like how much risk to take, how long\nto think, how widely to read, how hard to commit, and how done it reckons it is.\nFive numbers in, seven knobs out.
\nThe worm.
\nIt's C. elegans, a roundworm about a millimetre long. It has 302 neurons, and\nscientists mapped every single connection between them back in 1986 (the year I\nwas born, which I'm choosing not to read anything into). It's one of the only\nnervous systems we understand all the way down.
\nI took 14 of those neurons and ran them live in a simulation. Four of them do\nthe heavy lifting. One is a salt sensor, and to a worm salt means food, so I\nwired it to reward. Its opposite I wired to bad results. One drives the worm\nforward, so I wired it to how much work is left. One throws it into reverse, so\nI wired it to errors.
\nI didn't make any of that wiring up. It's the published connectome. All I did\nwas connect the worm's senses to the agent's situation and let it run.
\n(If you want the longer argument for why a worm of all things, I made the case\nwhen I\nfirst started this.)
\nDoes it crash, or does it do something useful?
\nIt starts at baseline with one failing test. Claude opens a few files, runs a\nsearch. The tests are failing, so the worm leans on the accelerator. I never\nwrote a rule that says "press the accelerator when there's work to do". It falls\nstraight out of the wiring.
\nThen Claude runs the tests and gets a real failure. The error neuron lights up,\nthe worm changes gear, and Claude makes its first proper edit. Risk drops, it\nreads less, it commits harder. Again, no rule for that combination. The error\nsignal and the work-left signal crossed a threshold together, and the worm\nturned that into "stop wandering, make a change". It found a scent.
\nA test goes green. Then another. The worm is cooking. If the run ended there I'd\nhave gone home happy.
\nIt didn't. The second edit was sloppy and broke something else. The pass rate\ndrops, the errors jump, and the punish neuron (my favourite, for the record)\nlights up hot.
\nThis is the moment I cared about. The obvious move is to panic, drop back to\nsquare one, and start over. The worm doesn't. It stays in gear, eases off, gets\ncareful, reads before it edits. Two ticks later the careful edit lands and the\npass rate climbs back higher than it was before the break.
\nIt recovered without restarting, which is exactly what a good pair would do.\nLook at the diff, don't burn the house down and start fresh. And nothing in the\nwiring connects a regression to a change of gear. The punish signal pulls one\nknob down. It doesn't yank the worm out of edit mode, because that's a different\nknob entirely.
\nBy tick 14 the last test goes green, ten out of ten, and the worm stops and\nparks the car. Not because I told it to stop at ten, but because there was\nnothing left pulling it forward.
\nSo I ran it properly. About 200 times. The live worm averaged a 0.96 pass rate.
\nThen I ran the exact same connectome, same wiring, same neurons, but\npre-recorded, like playing a tape of the worm's brain instead of letting it\nreact. That version averaged 0.87, and the live worm beat it every single time.\nSame brain. The only difference is one of them was alive and getting feedback,\nand the other was just replaying.
\nNow the part I have to be honest about. I ran a colder version where Claude\nhadn't indexed the repo first, and plain Claude with no worm and no driver beat\nevery controller I built, the live worm included. The worm is great at following\na gradient once the ground is mapped. It cannot plan its way around a codebase\nit has never seen. So this isn't "worm beats Claude". It's "feedback beats no\nfeedback", which is a smaller and far more useful claim. (The full methodology\nand numbers are\nin the paper.)
\nGive your agent a way to know when it's done. The baseline that couldn't tell\nkept running long after the job was finished, burning money for nothing.
\nDon't restart on a setback. The worm that held its nerve through the regression\ndid most of the real work.
\nAnd feedback beats wiring. Two identical brains, and the live one won purely\nbecause it was in the loop. The data you feed an agent and the loop you close\naround it matter more than how clever the thing in the middle is.
\nI built this in about three weeks, a couple of evenings here and there, on\nroughly $50 of API credits. I used Claude Code as my research assistant, which\nmeans my brain was steering Claude to build a thing that lets a worm's brain\nsteer Claude.
\nA few years ago a question this daft would have been a research project. Now\nit's a weekend and a coffee budget. The cost of chasing a strange idea has\nfallen through the floor.
\nSo chase the strange ideas. The code's\non GitHub. Go on.
\n","date_published":"Sun, 31 May 2026 00:00:00 GMT","image":"https://jonno.nz/og/what-happens-when-a-worm-drives-claude.png"},{"id":"https://jonno.nz/posts/the-holes-that-kill-you-are-the-ones-you-never-tested/","url":"https://jonno.nz/posts/the-holes-that-kill-you-are-the-ones-you-never-tested/","title":"The holes that kill you are the ones you never tested","content_html":"Every time something goes down, the first instinct in the room is to add a\nlayer. Another replica. A second region. One more health check in front of the\nthing that broke. It feels like progress, and the Swiss cheese model hands that\ninstinct a lovely picture to point at.
\nYou know the diagram even if you've never heard the name. Stacked slices of\ncheese, each slice a layer of defence, every slice riddled with holes. An\naccident only makes it through when the holes in all the slices happen to line\nup. James Reason built it to\nexplain how hospitals and aircraft fail, and it's still the best tool we have\nfor explaining why a system with five safety nets can still face-plant.
\nThe picture has a side effect though. It teaches you to count slices. And\ncounting slices is mostly the wrong job.
\nTake redundancy, since that's where slice-counting does the most damage. The\nmodel says two of everything beats one. Two servers, two regions. That holds\nright up until both copies share a single reason to die at the same instant.
\nOn 19 July 2024 CrowdStrike\nshipped a content update\nto its Falcon sensor and bricked around 8.5 million Windows machines, by\nMicrosoft's estimate, inside a few hours. Every one of those hosts was\n"redundant" in somebody's architecture diagram. Made no difference. They ran the\nsame agent and swallowed the same bad file at the same moment, so they all\ndropped together. When the failure is perfectly correlated like that, redundancy\nbuys you nothing. NASA's reliability folks put it bluntly: if one fault can take\nout the backup too, two subsystems fail twice as often as one.
\n![\"A](\"https://jonno.nz/img/posts/the-holes-that-kill-you-are-the-ones-you-never-tested-fig-1.png\")
There's a quieter version of the same trap hiding in your SLOs. String together\na dozen services that are each up 99.9% of the time and your ceiling is about\n98.8% before you've written a line of your own code, because every dependency is\none more slice with its own holes. You can't promise more reliability than the\nflakiest thing you lean on, and each extra nine costs more than the last.
\nThe slices you can draw on a whiteboard are the safe ones. The holes that get\nyou are the ones nobody can see: the failover that's never been run, the\nassumption that stopped being true six months ago when no one was looking, the\ndead code still sitting in production behind a flag.
\nKnight Capital is the one I'd tattoo on a junior engineer. On 1 August 2012 they\nswitched on new trading code and pushed it to seven of their eight servers. On\nthe eighth, a reused flag woke a dead function called Power Peg that should have\nbeen ripped out years earlier. For about 45 minutes it hurled orders into the\nmarket with nothing counting the fills:\nmore than four million executions and 397 million shares.\nKnight's own books put the loss at roughly $440 million, and the firm didn't\nsurvive the week.
\nPull it apart and every hole was survivable on its own: dead code left in the\nbuild, a flag doing double duty, a deploy one person ran with nobody reviewing\nit, 97 warning emails before the open that everyone read as noise. None of those\nsinks you alone. Line them up on a single Tuesday morning and the company is\ngone.
\nThat's Reason's real point, and it's a good one. The model is right. It's just\ncoarse. Richard Cook said it better in\nHow Complex Systems Fail: complex systems\nrun in a degraded state the whole time, stuffed with small faults, staying up\nbecause people quietly hold them together. Catastrophe needs a few of those\nfaults to meet. A sixth slice does nothing about the holes already living in the\nfive you've got.
\nYour architecture diagram and your runbook describe the system you imagine you\nhave. The real system is whatever your on-call engineer does at 3am to keep it\nlimping along. Erik Hollnagel calls that gap\nwork-as-imagined versus work-as-done,\nand the holes love living in it.
\nThe useful work is dragging those invisible holes into daylight while you still\nget to pick the timing. Adrian Cockcroft has the perfect name for skipping it.\nHe calls an untested failover\n"availability theatre":\nyou've got the runbook, you've got the standby, you feel great, and you have no\nclue whether any of it works because you've never once pulled the plug to watch.
\n![\"A](\"https://jonno.nz/img/posts/the-holes-that-kill-you-are-the-ones-you-never-tested-fig-2.png\")
This is why the teams who are good at this spend their hours on stuff that looks\nunglamorous. They run game days and break things in production on purpose, the\nway Netflix set Chaos Monkey loose to kill its own servers at random, just to\nprove the system could take it. They write\nblameless postmortems,\nbecause the day people get punished for an outage is the day they stop telling\nyou where the holes are. They treat reliability as a budget they spend, not a\nfeeling they chase.
\nMost of that is a people problem wearing a technology costume. The\nhighest-leverage slice in your whole stack is usually the on-call engineer at\n3am, and whether your culture lets them say "yeah, I broke it, here's how"\nwithout flinching. No cloud provider sells that one.
\nI've built billing and payments platforms where downtime means somebody doesn't\nget paid, and shipped to production many times a day. The urge to bolt on\nanother layer never goes away. It just gets more expensive, and more comforting.
\nBy all means keep your redundancy. Keep the regions and the replicas. Just don't\nkid yourself that a standby you've never failed over to is a second slice of\ncheese. It's a hole with a comforting label, and you'll find out which one it\nreally is on the worst possible morning.
\n","date_published":"Sun, 31 May 2026 00:00:00 GMT","image":"https://jonno.nz/og/the-holes-that-kill-you-are-the-ones-you-never-tested.png"},{"id":"https://jonno.nz/posts/the-18-laws-of-human-nature/","url":"https://jonno.nz/posts/the-18-laws-of-human-nature/","title":"The Laws of Human Nature","content_html":"\nGreene's order: master yourself, then decode others, then handle the social dynamics. Builds the vocabulary you need for the later laws.
\nThe five that change the most about how you read a room. Irrationality, role-playing, envy, defensiveness, aimlessness.
\nGreene at his most surgical. Repression, grandiosity, envy, death denial. Read these slowly and with someone who'll tell you the truth.
\nI recently finished Robert Greene's The Laws of Human Nature and it wouldn't\nleave me alone. Eighteen laws, each one a separate pattern in how people\nactually behave (not how we like to think we behave). I kept catching myself\nwatching the patterns play out in real life: in meetings, in news cycles, in my\nown head.
\nSo I built the thing above. Eighteen cards, one per law. Tap any of them to read\nmy full take, with two real-world examples and a short list of behavioural\nthings you can do this week. About a thousand words a law, around twenty\nthousand total. Your read-progress sticks between visits.
\nIf a card grabs you, that's the one to start with. If not, the canonical order\nat the top is a fine path. Either way, the actual book is much richer than this\nmap. Robert Greene wrote it; if you want the deep version,\ngrab a copy on Amazon{target="_blank"\nrel="noopener"}.
\nA note on attribution. The names, the structure and the underlying observations\nare all Greene's (The Laws of Human Nature, Profile Books, 2018). The writing\nis mine, the modern examples are mine, and any wrong reading of his ideas is\nmine.
\n\n\n\n\n\n\n\n","date_published":"Tue, 26 May 2026 12:00:00 GMT","image":"https://jonno.nz/og/the-18-laws-of-human-nature.png"},{"id":"https://jonno.nz/posts/conscious-minimalism/","url":"https://jonno.nz/posts/conscious-minimalism/","title":"Conscious Minimalism","content_html":"I build with Conscious Minimalism.
\nConscious Minimalism means every decision, every feature, every commitment is a\nchoice. Nothing ships by default. The shape grows with the customer, not the\nroadmap.
\nI obsess over the interface, not the internals. The boundary is what you live\nwith, and what you refactor and scale.
\nI optimise for speed to de-validation. The faster I kill a bad idea, the less\nsunk cost owns me.
\nI fix one narrow painpoint, not a broad category or a platform play. One thing,\ndone properly.
\nI aim to be the best at that one feature, not one of the good ones in the list.
\nI chase niche over crowded. Niche means the idea is more unique, with a better\noutcome than the legacy approach.
\nCrowded is a signal of competition. Without a 10x better solution, you probably\nwill not make it.
\nI bet on AI-native platforms and APIs. Anything that does not use AI as a\nprimitive is already legacy.
\n","date_published":"Thu, 14 May 2026 12:00:00 GMT","image":"https://jonno.nz/og/conscious-minimalism.png"},{"id":"https://jonno.nz/posts/the-dent-and-the-crater/","url":"https://jonno.nz/posts/the-dent-and-the-crater/","title":"The dent and the crater","content_html":"\n\n"The world breaks every one and afterward many are strong at the broken\nplaces. But those that will not break it kills."
\n— Ernest Hemingway, A Farewell to Arms (1929)
\n
Hemingway wasn't writing about leadership but he might as well have been. Some\nof the senior leaders I've worked with have taken serious dents over their\ncareers. The board that turns. The launch that lands flat. The cofounder who\nwalks. The round that doesn't close. The dents come with the job. The question\nis what's there a year later: a place you went back to and got strong at, or a\ncrater you've been quietly walking around since.
\nThe crater is the part that doesn't make the leadership playbooks. The bad year\ndoesn't get you on its own. The silent processing of the experience afterwards\ndoes, the quiet work of making sure that bad year can't happen again. You start\nshowing up to meetings already half-armoured. You stop trusting the kind of\ndecision that hurt you the last time. You add a layer of process around the work\nbecause process is what you wish you'd had then. Most of it doesn't land as a\nwound on the day. By the time it sets in, you've already started telling\nyourself a different story about it: you've learned, you've matured, you're\noperating at a higher level now.
\nThat's the bit that makes it nasty. Hardening reads as wisdom from the inside.\nYou flinch at the next pitch and call it prudence. The new hire brings an idea\nyou don't like, so you tell yourself you've seen this movie before. You shut\nyour door and call it focus. The mind narrates the armour as growth more often\nthan not, and the people around you go along with it because senior leaders\naren't expected to second-guess themselves out loud.
\nThe cost shows up sideways. You don't notice the day you stopped being\npersuadable by a junior engineer. You notice five years later, when the people\nworking for you have stopped bringing you the rough version of an idea because\nthey know what you'll do with it. The day you got bored of customer calls is the\nsame. You feel it a quarter later, when the deck you wrote turns out to be three\ncalls behind reality. The dents you didn't tend become the things you stop being\nable to see. Walls have that habit. They keep the threat out and the signal out\nat the same rate.
\nThe leaders who stay good at this over time do something specific about it. They\ndidn't get there by accident. Some have a coach they actually use, not the one\nHR signed them up with. A few run a peer group of two or three other operators\nwhere the deal is you say the real thing about the quarter, including the bit\nyou're embarrassed about. Others lean on a partner or a mate outside the\nindustry who couldn't care less what your title is and wouldn't be impressed if\nyou told them. The best ones I've watched have a practice that takes them\noff-stage. Riding, surfing, building, training. Doesn't matter what. The point\nis having a part of life where you're not on stage.
\nThe shape underneath these is the same. They keep at least one room in their\nlife where the armour comes off, and they go in there often enough that the dent\ndoesn't get to set. That's the work. It looks soft from outside. It isn't. It's\nmost of the reason these people are still doing the job at fifty in a way that\nresembles how they did it at thirty.
\nPeople who skip this are the senior leaders you've been managed by at some point\nin your career, the ones you probably promised yourself you wouldn't become.\nThey've stopped reading the room. Most new ideas look like traps. Their\ncalendars are locked down to keep surprises out. They're not bad people. They're\npeople whose dents won, and the orgs around them are downstream of that win in\nways few people have the standing to call out.
\nThe team picks it up. That's the part founders and senior people miss most. You\ndon't get to decide which of your behaviours your reports model and which they\nignore. They copy the closed-off ones at the same rate as the rest, because\nyou're the senior person and that's the working definition of culture in\npractice. Your defensiveness teaches them caution. Your shortened patience\nteaches them to close things down faster than they should. The day you refused\nto say "I don't know" is the day they stopped saying it too. The crater spreads\noutward into the org and stops being something you can fix in private.
\nTending the dent is leadership work, the same line item as strategy, hiring, and\nboard management. Skip it for long enough and the dent becomes a crater, the\ncrater becomes the shape of the org, and the people who used to bring you their\nbest ideas start bringing them to someone else.
\n","date_published":"Wed, 06 May 2026 12:00:00 GMT","image":"https://jonno.nz/og/the-dent-and-the-crater.png"},{"id":"https://jonno.nz/posts/built-a-read-later-chrome-extension-because-pocket-died/","url":"https://jonno.nz/posts/built-a-read-later-chrome-extension-because-pocket-died/","title":"I Built a Read-Later Chrome Extension Because Pocket Died","content_html":"I open about thirty tabs a day. I read maybe three of them. The rest are "oh\nthat looks interesting, I'll come back to that," and then they sit there until\nmy browser starts choking and I close everything in a fit of guilt.
\nBookmarks aren't the answer. Bookmarks go into a folder I never open. Pocket was\nthe answer, except\nMozilla shut Pocket down in July 2025,\nwhich I found out the way most people did: by going to save something and\ndiscovering the service was gone.
\nSo I built\nRead Later.\nIt's a Chrome extension. It saves the page you're on. That's the whole pitch.
\nYou hit Cmd+Shift+L and the current tab gets saved with its title, URL, and\nfavicon. Add a tag if you want. Done. There's a popup if you'd rather click a\nbutton, and a context menu if you'd rather right-click a link without opening it\nfirst.
There's also a full-tab "shelf" view at Cmd+Shift+K where all your saved\narticles live. Search, filter by tag, mark as read, archive. The aesthetic is\nwarm parchment and moss green because I got tired of every productivity tool\nlooking like a Linear screenshot.
That's it. No AI summaries, no recommendations, no "people who saved this also\nsaved...", no newsletter, no account.
\nI tried. Bookmarks are designed for things you'll come back to many times. A\nread-later list is the opposite, you read each thing once and then it's done.\nThe lifecycle is different. Stuffing them into the same UI is why my bookmarks\nbar has been a graveyard for ten years.
\nThe other read-later apps that survived Pocket all want an account, a sync\nserver, and usually a subscription. For something whose whole job is "remember\nthis URL until I read it," that's a lot of infrastructure. I wanted local\nstorage and nothing else.
\nEverything lives in chrome.storage.local. Nothing leaves your browser. There's\nno server because there's nothing for a server to do. If you want to back up\nyour list, there's an Export button that gives you JSON. If you want to move it\nto another machine, Import takes the JSON back. If you want to share your shelf\nwith someone, "Copy as Markdown" gives you a clean list you can paste into Slack\nor an email.
This was a deliberate call. Sync is the feature that turns a small tool into a\nservice, and a service needs accounts, and accounts need a backend, and a\nbackend needs my time and money forever. JSON in, JSON out is the version of\n"sync" that costs me nothing and gives the user complete control. Want it on two\nmachines? Export on one, Import on the other. Good enough.
\nThe real experiment was the launch. I've shipped plenty of things over the years\nbut never to the Chrome Web Store, and I wanted to see what that pipeline felt\nlike end to end. Pretty smooth, no drama. You pay the developer fee, fill in the\nlisting, upload a zipped manifest, wait for review. Mine went through first\ntime.
\nThe work was in the listing copy and the screenshots. You're suddenly writing\nfor a discovery page where people decide in three seconds whether to click\ninstall. That's a different muscle from writing a README. It made me think\nharder about what the extension actually does for someone who isn't me.
\nI've got a folder on my laptop called "side projects" with about a dozen things\nin it, each solving some specific bit of friction in my own life. Most of them\nstay there. This one made it out because the friction was real, the build took\nan afternoon, and putting something on the Chrome Web Store turned out to be a\nsatisfying little exercise.
\nIf you've got tabs piling up and don't want to hand your reading list to a\nstartup, it's\nthere.\nSource on GitHub, MIT licensed. Pin\nthe leaf icon and have a go.
\n","date_published":"Tue, 05 May 2026 12:00:00 GMT","image":"https://jonno.nz/og/built-a-read-later-chrome-extension-because-pocket-died.png"},{"id":"https://jonno.nz/posts/product-market-fit-is-a-gauntlet/","url":"https://jonno.nz/posts/product-market-fit-is-a-gauntlet/","title":"Product market fit isn't a stage, it's a gauntlet","content_html":"Product market fit gets sold as a milestone. Find it and you're off to the\nraces. That's the bit nobody who's been through it actually believes.
\nPMF is a gauntlet. It eats teams, it bends founders, and it quietly poisons the\ntechnical decisions you're proud of at the time. Most of the damage I've watched\ndone to good companies wasn't from missing PMF. It was from how they behaved\nwhile they were looking for it.
\n![\"The](\"https://jonno.nz/img/posts/pmf-gauntlet/gauntlet-loop.svg\")
There's a particular kind of person who does well in the pre-PMF phase. High\ntolerance for ambiguity, low need for closure. The deck never feels finished,\nthe metric you're chasing changes every six weeks, and the answer to "what are\nwe doing in three months" is "depends."
\nPlenty of really good operators just cannot function in that environment. That's\nnot a character flaw — it's a stage mismatch. Some people thrive at zero to one.\nSome thrive at one to ten. Almost no one thrives at both, and the industry\npretending otherwise has cost a lot of careers and a lot of sanity.
\nNaming this honestly so people can self-select is one of the kindest things a\nfounder can do. You're not letting someone down by saying "this stage probably\nisn't for you, but the next one will be." You're saving them eighteen months of\nfeeling broken.
\nTiming, market, economy, what your one big regulator decides on a Tuesday — none\nof that is yours. You can have a sharp thesis and a great team and ship\nsomething nobody buys, because something three layers above you shifted while\nyou were heads-down.
\nThe only protection I've found against this is a vision the team is genuinely\nbought into. Not the slide. Not the wall poster. The actual reason you all got\nout of bed this morning. When the macro turns and the metric you were proud of\nlast quarter goes sideways, that vision is what stops the org from devouring\nitself.
\nI've watched startups where the thesis was right but the timing was a year early\nlose half their team in three months because nobody could explain why they were\nstill doing what they were doing. It wasn't a strategy problem. It was an\nalignment problem dressed up as a strategy problem.
\nThis is also where founders take the most damage personally. You can do\neverything well and still get hit by something nobody could have predicted. If\nyour sense of self is tied to PMF being a verdict on you, that breaks people.\nThe ones I've seen come through it healthy treated PMF like weather they were\nnavigating, not a test they were passing.
\nYour moat isn't the product. It isn't the tech. It definitely isn't the brand.\nYour moat is how fast the org can spot a shift in TAM or target market and\ntranslate it into a product move.
\nDays, ideally. Weeks if you have to. Not quarters.
\nThis is where the technical decisions made in the name of "scaling" quietly\ncripple you. The microservices you split out before you needed to. The custom\ninfrastructure someone stood up because their last job had it. The platform\nabstractions that mean a small UI change touches four repos. Each of those felt\ndisciplined at the time. Each is now a tax on the only thing you actually have —\nspeed.
\nAndreessen wrote the\noriginal PMF essay almost\ntwenty years ago, and the line that's aged best is the bit about doing whatever\nit takes — changing people, rewriting the product, moving markets. That's not a\nlicense to be chaotic. It's a reminder that the org needs to be physically\ncapable of those moves. If your architecture, process, or contracts make\nrewriting the product a six-month project, you've already lost the gauntlet\nwhether you know it yet or not.
\nI've got a strong opinion on this one: when in doubt, build it boring. Boring is\nfast to change.
\nThe customers who signed up first kept you alive. They also signed up for a\nslightly different company than the one you're now trying to become. That gap is\nwhere a lot of startups quietly die.
\nKeep them too happy and you slow your evolution. Push too hard toward the new\nvision and you churn the cohort that's funding your runway. The actual job is to\ndo both at once, which is why I sometimes call it internal schizophrenia. You're\na different company to them than you are to yourselves, and that's not a bug —\nthat's the mode you're operating in.
\nThe skill is being honest with the early cohort about where you're going without\nselling them something they didn't buy. The art is using their feedback to\nsharpen the bigger vision rather than letting yourself be pulled back into being\ntheir bespoke vendor. The dance is doing both of those without your team\nthinking you've gone off-piste, because the gap between "what we're shipping\ntoday" and "where we're going" looks weird from the inside.
\nThree patterns I keep seeing.
\n![\"Discipline](\"https://jonno.nz/img/posts/pmf-gauntlet/discipline-vs-fragility.svg\")
Engineering over-scales the architecture. The team builds for the company they\nwant to be in two years instead of the company they need to be this quarter. By\nthe time PMF actually shows up, the org can't move. Worse, the engineers feel\nbusy and capable the whole time it's happening, which is why it's so hard to\nstop. Nobody is asking to slow down — everyone is shipping.
\nProduct holds the roadmap too tightly. The roadmap is the experiment at this\nstage. Treating it like a commitment is a category error. The product teams I've\nseen do this well treat the roadmap like a hypothesis with version numbers —\nlast month's was wrong, this month's is less wrong, and that's how it's supposed\nto feel. The ones who don't end up defending decisions they made when they knew\nless.
\nFounder comprehension debt builds up faster than anyone notices. The founder is\nheads-down on signal — every customer call, every dropped deal, every weird\npattern in the data lands in their head and gets metabolised on the spot. The\nteam is two beats behind, working from last week's mental model. Each individual\ndelay feels minor. The cumulative gap is the thing that kills decisions.
\nEach of these looks like discipline from the inside. Each of these is fragility\nwearing discipline's clothes.
\nMoats in the AI space are shifting quarter by quarter right now. Feature moats\nhave basically collapsed — anything you can describe in a screenshot can be\ncloned in a weekend with the current generation of tools. What's\nactually defensible has moved\ntoward proprietary data, deeply embedded workflows, distribution, trust, and\nregulatory positioning.
\nFor a founder in the PMF gauntlet that means the playbook is unreliable in a way\nit wasn't five years ago. You can't just lift what worked for the last cohort of\nSaaS winners and run it. You have to reason from first principles about where\nyour actual edge is going to come from over the next eighteen months, and place\nchips accordingly.
\nThe gauntlet itself hasn't changed. The chips you're placing have. That's harder\nthan it sounds, because most of us were trained in an era when the moat\nconversation was settled.
\nThe version of PMF that gets written up in case studies is always cleaner than\nthe thing itself. There's a chart, a moment, a story arc. From the inside it\nnever looks like that.
\nIt looks like a year of conflicting signals. Two customers who love it, four who\nchurned, one who would buy if you built a feature you're not sure fits the\nvision. A board update where you're trying to make a noisy graph sound coherent.\nAn engineer asking a perfectly reasonable question about the roadmap that you\ncan't answer without lying a little.
\nThe companies that come through it don't seem, in retrospect, to have had better\ninformation than the ones that didn't. They had roughly the same fog. They just\nkept reasoning out loud, kept revising in public, and didn't pretend the chart\nwas already drawn.
\nThe case studies leave the fog out. That's most of it.
\n","date_published":"Fri, 01 May 2026 00:00:00 GMT","image":"https://jonno.nz/og/product-market-fit-is-a-gauntlet.png"},{"id":"https://jonno.nz/posts/change-management/","url":"https://jonno.nz/posts/change-management/","title":"Change management","content_html":"There's a whole business discipline called change management. Frameworks,\ncertifications, consultancies, the lot. Every big company has someone running it\nduring a restructure or a tech migration. Nobody runs it for you when your life\nturns over.
\nWhich is strange, because the personal version is the harder problem — and right\nnow, more people are facing it than at any point in recent memory.
\nMore than\n92,000 tech workers have been laid off in 2026 alone,\nbringing the total close to 900,000 since 2020. Meta cut 8,000 jobs last week.\nMicrosoft offered buyouts to 7% of its US workforce — the first time in its\n51-year history. Oracle has started cuts that could reach 30,000 by year end.\nCloser to home, Xero, Sharesies, Spark, One NZ and Eroad have all run their own\nrounds. AI is the headline reason, but the impact lands the same regardless of\nthe cause: hundreds of thousands of people closing a laptop and discovering\ntheir working identity has just been deleted.
\nThat's a lot of people being handed a forced version of personal change\nmanagement without ever signing up for the course.
\nThe business framing has the right insight buried in it.\nWilliam Bridges made a\ndistinction in the 90s that most people miss: change is external, transition is\ninternal. Change is the new org chart, the redundancy email, the merger.\nTransition is what happens inside people's heads while all that is going on.\nChange can happen overnight. Transition takes as long as it takes.
\nPersonal change management is just transition without the org chart.
\nI've been through a few years of it now. Not one big event — more like a slow\nstack of endings, some chosen, some not. Companies, relationships, versions of\nmyself I'd been building for a decade. The kind of stretch where you don't\nreally notice you're changing until you look up one day and the old you is gone.
\nThat's the part nobody warns you about. Real change isn't transformation. It's a\ncontrolled demolition followed by a slow rebuild, with a long, weird middle bit\nwhere neither the old you nor the new you is really there.
\nThe thing that goes is usually the organising self. Whatever the old you was\narranged around — a fear, a need for approval, a story about who you had to be,\nan ambition that was really a wound. When that goes, the structure it was\nholding up collapses. That's the death. It's real.
\nWhat survives is everything that wasn't load-bearing on the old arrangement.\nYour humour, your curiosity, the way you actually see people, the things you\ngenuinely care about. Those don't die because they weren't propping anything up.\nThey were just you, underneath.
\nThe disorienting part is feeling like a stranger to yourself and entirely\ncontinuous, at the same time. Both are true. The continuous parts are\ncontinuous. The organising self is gone. You're in between.
\nBridges calls this the neutral zone. The old reality has gone, the new one isn't\nthere yet. He says it's the hardest phase to manage, and most organisations rush\nthrough it because it looks unproductive. People do the same thing to\nthemselves.
\nThe temptation is to build a new identity fast, because the empty space is\nuncomfortable. Don't. Whatever you grab in a hurry will be made of whatever was\nlying around — which usually means the old patterns sneak back in wearing new\nclothes. Workaholism becomes "building my legacy". Approval-seeking becomes\n"being of service". Avoidance becomes "protecting my peace". Same machine, new\npaint.
\nThe test is always: is this coming from fear or from truth? You'll know. The\nbody knows before the mind does. Pay attention to the part of you that goes\nquiet around certain people, certain projects, certain decisions. That's the\nsignal.
\nYou don't get to fearless by trying. You get there by going through enough\nendings that the bluff stops working.
\nFear runs on a specific con: if this thing happens, you won't survive it. Not\nliterally die — but the you that exists now won't continue. You'll be broken,\nfinished, unrecognisable. The con works as long as it's untested. Then the thing\nhappens, and you go through it, and on the other side you notice you're still\nhere. Different, scarred, but continuous. The fear was lying about its hand.
\nAfter that, fear can still show up — it doesn't leave — but it can't run the\nsame con. You've seen the card it was holding. Next time it says you won't\nsurvive this, some quiet part of you knows: I already did.
\nThat's not the absence of fear. It's knowing you can act from what's true even\nwith the fear in the room.
\nHere's the bit that surprised me. Once the demolition is done and the rebuild\nstarts, what comes back isn't impressive. It's just real. Less reactive. Less\nnoise. Less performance. You stop needing to be seen a particular way, partly\nbecause you've watched a few of those selves die and you don't trust the next\none enough to stake everything on it.
\nThe goal of change management — the personal kind — isn't to become someone\nadmirable. It's to become someone who's the same alone as in public. Someone who\ndoes the next true thing without announcing it. Most of the depth of this stuff\nlives in the texture of regular days. How you handle a boring Tuesday. Whether\nyou rest when you're tired or push through to prove something to nobody.
\nBusiness change management has all this in it, and most people read it as a\nproject manager's manual. It's also a personal one. Endings, neutral zone, new\nbeginnings. Same shape, different blast radius.
\nThe seeds that grow through the demolition are the ones worth tending. The rest\nsorts itself out.
\n","date_published":"Sat, 25 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/change-management.png"},{"id":"https://jonno.nz/posts/three-ways-to-look-at-time/","url":"https://jonno.nz/posts/three-ways-to-look-at-time/","title":"Three Ways to Look at Time","content_html":"ST-ResNet's core insight is that not all history is created equal.
\nWhen you're predicting crime in Auckland next month, three different kinds of\npast information matter. What happened in the last couple of months: the recent\ntrend. What happened at the same time last year: the seasonal pattern. And\nwhat's been happening over the longer term: whether crime is generally rising or\nfalling in an area.
\nConvLSTM treats all of this as one continuous sequence and hopes the network\nfigures out which parts matter. ST-ResNet\ntakes a more opinionated approach. It separates these three temporal scales\nexplicitly and gives each one its own dedicated neural network branch.
\nThe original paper by Zhang et al. was about predicting crowd flows in Beijing.\nPeople move through cities in patterns that look a lot like crime patterns:\ndaily rhythms, weekly cycles, long-term trends. The architecture\ntranslates well to crime data,\nwith some modifications.
\nThe three branches each look at different slices of history:
\nCloseness captures what's been happening recently. For our monthly data,\nthis means the last 3 months. If South Auckland has been trending upward over\nthe last quarter, the closeness branch sees that momentum.
\nPeriod captures seasonal patterns. It looks at the same month in previous\nyears. So to predict January 2026, it pulls in January 2025 and January 2024.\nThe assumption is that crime has an annual rhythm, and the same month tends to\nlook similar year to year.
\nTrend captures longer-term shifts. It uses quarterly averages from further\nback: broad strokes of whether an area is seeing more or less crime over time.\nThis is the slowest-moving signal.
\nEach branch independently processes its temporal slice through a stack of\nresidual convolutional blocks, then a learned fusion layer combines the three\noutputs:
\n![Vysoven](\"https://commons.wikimedia.org/wiki/File:Aerobavovna_ARB12_aerostat_in_use_by_Ukrainian_SoF.jpg\"){kind=link}
![ArmyInform](\"https://commons.wikimedia.org/wiki/File:UA_fiber-optic_FPV_drone_01.webp\"){kind=link}
![Mbrickn](\"https://commons.wikimedia.org/wiki/File:ANPR_Camera_Front.jpg\"){kind=link}
![Folkestonesurvey](\"https://commons.wikimedia.org/wiki/File:Camera_and_video_screen_at_Sainsbury%27s_self_checkout_2022.jpg\"){kind=link}
prediction = W_c · closeness + W_p · period + W_t · trend + bias\nWhere W_c, W_p, and W_t are learned weights that vary by grid cell. This\nis a nice touch. It means the model can decide that the CBD's crime is mostly\ndriven by recent trends (closeness), while a residential suburb might be more\nseasonal (period). Different areas get different temporal recipes.
Each branch uses residual convolutional units, the building blocks that made\nResNet so successful in image recognition.
\nThe key idea: instead of learning the full output at each layer, the network\nlearns the residual, the difference between input and output. The identity\nshortcut connection means gradients flow cleanly through the network during\ntraining, which lets you stack more layers without the signal degrading.
\nResUnit(X) = ReLU(Conv(ReLU(Conv(X))) + X)\nThat + X at the end is the skip connection. If the layer has nothing useful to\nadd, it can learn weights near zero and just pass the input through. This makes\ndeeper networks stable, which matters when you're trying to learn spatial\nfeatures at multiple scales.
For our grid, I use 4 residual units per branch. Each unit has two 3×3\nconvolutional layers with 32 filters. That's deep enough to capture spatial\nrelationships across several kilometres without being so deep that the model\noverfits on 36 months of training data.
\nHere's where theory meets reality, and it gets a bit awkward.
\nST-ResNet was designed for dense, high-frequency data. The Beijing crowd flow\npaper used 30-minute intervals over months of data: thousands of timesteps. The\ncrime papers that report strong results typically use daily data over several\nyears.
\nWe have 48 monthly timesteps. Total. The period branch (which looks at the same\nmonth in previous years) has at most 3 data points per month (2022, 2023, 2024\nto predict 2025/2026). The trend branch is working with quarterly averages from\na four-year window. It's not a lot of temporal data for an architecture that's\nspecifically designed to decompose temporal patterns.
\nI had a feeling this would be the bottleneck, and it was.
\nCloseness branch:\n Input: last 3 months (3 × 6 channels = 18 input channels)\n → 4 ResUnits (32 filters, 3×3 kernels)\n → Output: 32 channels\n\nPeriod branch:\n Input: same month from 2 prior years (2 × 6 = 12 input channels)\n → 4 ResUnits (32 filters, 3×3 kernels)\n → Output: 32 channels\n\nTrend branch:\n Input: 2 quarterly averages (2 × 6 = 12 input channels)\n → 4 ResUnits (32 filters, 3×3 kernels)\n → Output: 32 channels\n\nFusion:\n → Learned weighted sum across branches\n → Conv2d(32, 6, 1×1) → 6 crime type predictions\nTotal parameters: roughly 180k. Slightly smaller than the ConvLSTM, which is\nfine. ST-ResNet's power is supposed to come from the temporal decomposition, not\nfrom model size.
\nTraining uses the same setup as ConvLSTM: Adam optimiser, learning rate 1e-4,\nMSE loss on log1p-transformed values, early stopping with patience of 15\nepochs. On CPU, each run takes about 35 minutes, a bit faster than ConvLSTM\nsince there's no sequential recurrence to deal with.
| Crime Type | \nHist. Avg MAE | \nConvLSTM MAE | \nST-ResNet MAE | \n
|---|---|---|---|
| Theft | \n1.28 | \n1.14 | \n1.18 | \n
| Burglary | \n0.35 | \n0.32 | \n0.33 | \n
| Assault | \n0.20 | \n0.19 | \n0.19 | \n
| Robbery | \n0.04 | \n0.04 | \n0.04 | \n
| Sexual | \n0.03 | \n0.03 | \n0.03 | \n
| Harm | \n0.01 | \n0.01 | \n0.01 | \n
| All types | \n0.39 | \n0.35 | \n0.36 | \n
ST-ResNet beats the historical average but doesn't quite match ConvLSTM. The\naggregate MAE of 0.36 is a 7.7% improvement over the baseline, compared to\nConvLSTM's 10.3%.
\nThat's not a terrible result, but it's not what I was hoping for.
\nWhen I dug into the learned fusion weights, the story became clear. The\ncloseness branch dominates. It gets 60–70% of the weight across most grid cells.\nThe period branch gets 20–25%, and the trend branch barely contributes at\n10–15%.
\nThe model is basically saying: "Recent months matter most, seasonal patterns\nhelp a bit, and long-term trends are mostly noise." That's not a failure of the\narchitecture. It's a fair assessment of what's in the data.
\nWith only 2–3 examples of each calendar month, the period branch can't reliably\nlearn seasonal patterns. It's overfitting to individual years rather than\nextracting a stable seasonal signal. ConvLSTM handles this better because it\nprocesses the full sequence and implicitly learns seasonality from the\ncontinuous flow of months, without needing to explicitly align calendar periods.
\nThe trend branch suffers even more. Quarterly averages over a four-year window\ndon't give it much to work with. In the original crowd flow papers with years of\nhalf-hourly data, the trend branch captures genuine long-term shifts in\npopulation movement. Here, it's essentially learning a constant.
\nDespite losing on aggregate, ST-ResNet has one clear advantage: it's better at\npredicting seasonal transitions.
\nThe months where crime shifts gears (the spring uptick in September/October and\nthe February dip) ST-ResNet handles more gracefully than ConvLSTM. The period\nbranch, sparse as its data is, does capture enough of the annual rhythm to\nanticipate these transitions a bit earlier.
\nConvLSTM tends to lag these transitions by about a month. It needs to "see" the\nuptick starting before it predicts continuation. ST-ResNet, by explicitly\nlooking at last year's same month, can anticipate the shift before it fully\nmaterialises in the recent sequence.
\nFor an operational forecasting tool, that one-month lead time on seasonal\ntransitions could be valuable. But in our test set metrics, it's a small\nadvantage that doesn't overcome ST-ResNet's overall weaker performance on\nmonth-to-month dynamics.
\n| Metric | \nHistorical Avg | \nConvLSTM | \nST-ResNet | \n
|---|---|---|---|
| Overall MAE | \n0.39 | \n0.35 | \n0.36 | \n
| Theft MAE | \n1.28 | \n1.14 | \n1.18 | \n
| Training time (CPU) | \nN/A | \n~40 min | \n~35 min | \n
| Parameters | \n0 | \n~200k | \n~180k | \n
| Seasonal transitions | \nPoor | \nLagging | \nBetter | \n
| Spatial dynamics | \nNone | \nGood | \nGood | \n
ConvLSTM is the better model for this specific dataset. Not by a lot. We're\ntalking about small differences on already-small error values. But consistently\nbetter on the main crime types that have enough signal to matter.
\nNeither model is a revelation. A 7–10% improvement over "just use the historical\naverage" is real but modest. Deep learning's strengths (learning complex\nnonlinear dynamics from huge datasets) are somewhat wasted on 48 monthly\ntimesteps over a relatively low-crime city.
\nIf I had daily data instead of monthly, or ten years instead of four, I'd expect\nST-ResNet to close the gap or pull ahead. Its architecture is fundamentally\nsound. The temporal decomposition is a genuinely good idea. It's just starved of\nthe data it needs to shine.
\nBoth models meaningfully beat the baselines. Both learn spatial patterns that\nsimple averages can't capture. And both are honest about the sparse crime types:\nthey predict near-zero and move on, which is the right call.
\nNext up: we'll take these predictions and build something you can actually look\nat. A 3D interactive dashboard where you can watch crime patterns evolve across\nAuckland over time. The modelling was the hard bit. Making it visual is the fun\nbit.
\n","date_published":"Thu, 23 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/three-ways-to-look-at-time.png"},{"id":"https://jonno.nz/posts/what-an-hour-of-your-attention-is-worth/","url":"https://jonno.nz/posts/what-an-hour-of-your-attention-is-worth/","title":"What an hour of your attention is worth","content_html":"I stood up a working social network for eight mates last weekend. Profile pages,\na shared feed, a photo wall, a jukebox bolted onto a spare domain. It took me a\nSaturday, about forty bucks in Claude credits, and exactly zero\nproduct-market-fit meetings.
\nThe same weekend, Meta earned about six bucks off me. Google made ten. LinkedIn,\nYouTube, TikTok, X — all quietly billing in the background, none of them sending\na receipt. If you add them all up for the average American, the annual total is\nnorth of $1,000. You just never see it, because no money changes hands and no\ninvoice arrives.
\nThe clever thing about "free" on the internet isn't that the trade doesn't\nexist. It's that it's been designed so you can't see it. No money moves. No\ninvoice lands. No app shows you the meter ticking as you scroll. The exchange is\nreal — your attention and your data in, Instagram and Google and LinkedIn out —\nbut by the time the numbers get tallied, they live in a quarterly earnings\nreport you'll never read. So the trade feels weightless.
\nIt isn't. You just can't see the price tag.
\nThe strange thing is the price tag has been public the whole time. Every\nplatform listed on a stock exchange tells you, four times a year, exactly what\nyou're worth to them. You've just never been shown how to read it — and until\nrecently, the only practical alternative to reading it was "live in a cabin."\nThat part has changed, and it's the part almost nobody is talking about.
\nThe invisibility isn't an accident either. If Meta had to send you a cheque\nevery month for the money they made off you, you'd treat the relationship very\ndifferently. You'd notice when the amount went up. You'd notice that the\nteenager version of the payment looks nothing like the adult version. You'd\nwonder why the Auckland cheque was ten times the Jakarta one for the exact same\nhour of scrolling. The whole edifice of "free" rests on keeping the accounting\none-sided — they measure you in basis points to three decimal places, you\nexperience the trade as a vague sense of having lost your afternoon.
\nThe number you want is called ARPU — average revenue per user. Every public\nplatform reports it, because investors demand it. The maths is blunt: take the\ncompany's annual revenue, divide by monthly active users. What comes out is what\nthe platform earns off the average human who shows up, per year.
\nFor Meta last year the global figure was about $52 per user. For YouTube's\nad-supported side, around $24. For\nLinkedIn it's $15 averaged across all 1.2B members,\nbut much higher once you strip out the dormant accounts.
\nThese aren't guesses from a watchdog group. They're from the companies\nthemselves, in the part of the earnings release where the whole purpose is to\nconvince shareholders each user is worth more than last quarter. The incentive\nis to talk the number up, not down.
\nWhatever ARPU says, the reality on the ground probably isn't lower. If anything,\nit's a floor.
\nRough figures, from the companies' own filings:
\nThe geographic skew is the part most people miss. Meta's figure in the US is\nroughly ten times what it is in Asia-Pacific. Europe sits in the middle at about\n$92. Same product, same features, same algorithm — different rate card, because\nad buyers pay more to reach wealthier audiences. You are literally worth more in\nAuckland than you are in Jakarta, and your feed is tuned accordingly.
\n![\"Meta](\"https://jonno.nz/img/posts/arpu-meta-by-region.svg\")
The same skew shows up across every ad-funded platform. The US rate card is the\none the rest of the world gets compared to:
\n![\"US](\"https://jonno.nz/img/posts/arpu-us-vs-global.svg\")
Marketplaces don't fit ARPU cleanly, but the extraction is still there if you\nlook for it. Uber and Lyft take around 20% of each fare. Airbnb combines host\nand guest fees for about 14–16%. DoorDash and Uber Eats take closer to 25%.\nShopify's card take is 2.9% plus 30 cents per transaction. Different mechanism,\nsame game — a percentage of every transaction, quietly skimmed, never itemised.
\nARPU is annual. Attention isn't spent in years though — it's spent in hours, in\nthe little windows between other things. So the honest conversion is to divide.
\nThe average US Meta user burns about 200 hours a year across Facebook and\nInstagram. $320 ÷ 200 = roughly $1.60 per hour of your attention. YouTube works\nout to about $0.27/hour. TikTok $0.22. Snapchat cheaper still. Do the same sum\non global averages and Meta drops to around 26 cents an hour, YouTube to 8.
\nThose rates are only what the platform earns this year, mind. They aren't what\nyour data is ultimately worth. Everything you click and hover and pause on\nfeeds ad targeting across the wider web, plus — now — AI training corpora. ARPU\nis the rent. The equity is bigger, and the equity compounds.
\nThe AI-training bit is genuinely new and worth pausing on. For fifteen years the\ndata you generated on these platforms powered one thing: better ad targeting on\nthose same platforms. It was a closed loop. You scrolled, they learned, they\nsold the targeting back to advertisers, the advertisers bought your attention\nagain. Bounded. Weird, but bounded.
\nThat loop isn't bounded anymore. Your posts and comments and DMs are now\ntraining data for models that will be sold, resold, and embedded into every\npiece of software you touch for the next decade. The $320 Meta earned off you in\nthe US last year is a rounding error next to what the underlying corpus is worth\nto the next generation of AI products. ARPU doesn't capture any of that. It's\nliterally last quarter's ad rent, with none of the capital gains on the asset.
\nEven the rent, laid out per hour, makes one thing obvious: you can see exactly\nwhy every platform is obsessed with "time spent" as a north-star metric. If one\nextra hour a week on Facebook is worth ~$83 a year per US user, multiplied\nacross three billion users, the maths for why the feed never stops scrolling is\nnot mysterious. The feed is a meter. Keeping it running is the business. Every\n"new feature" that shows up in your settings — reels, shorts, a nudge to open\nthe app on your commute — is a hand on that meter.
\nOnce you see it that way, a lot of product decisions stop looking like product\ndecisions.
\nThe point of making the numbers this concrete is that you can plug in your own\nusage and see what you personally throw into the machine each year. Drag the\nsliders for how much time goes into each platform and watch the ledger tally up.\nRates are global averages.
\nARPU is rent, not equity. What a platform earns this year isn't what the underlying data is worth across the wider web and AI training corpora.
Averages hide heavy users. Freemium smears free and paying users into one figure. If you're all-in, you're worth more than average.
Multi-product companies cheat the top line. Google's per-user number isn't all Search — it's Search plus Android plus YouTube plus Cloud.
The rates come from the earnings-report maths above — global ARPU divided by\naverage annual hours on the platform.
\nOnce the number has somewhere to sit, it's much harder to ignore.
\nMost people look at a total over $1,000/yr and go quiet for a second. Not\nbecause any one platform is egregious — on a per-hour basis they really aren't —\nbut because the aggregate is real, and it's been invisible until now. That's the\nfirst useful thing the exercise does. It makes a choice possible.
\nThe obvious next move is to look at alternatives. Signal instead of WhatsApp.\nKagi or Brave Search instead of Google. Paid Spotify instead of ad-supported\nSpotify. Bluesky or Mastodon instead of X. Fastmail instead of Gmail. None are\nperfect, and some cost actual money — but once you can price what you're\ncurrently "not paying", the paid alternative often looks less expensive than it\ndid five minutes ago. Fastmail at\n$5/month stops being a luxury when the honest comparison is "$60/yr vs being the\nproduct for an ad network that paid $500 for me last year."
\nThat's the defensive move. It's the one everyone talks about, every time one of\nthese pieces gets written. You switch to the more honest vendor, you feel\nslightly better, and the fundamental shape of the market doesn't move.
\nThe more interesting move is what's happened on the build side, and it's the\npart almost nobody has internalised yet.
\nStanding up a social app used to take a small team months. You needed a backend\nengineer, a frontend engineer, a designer, probably a DevOps person, and a spare\nthree months. That was the real moat — not the network effects, not the\nalgorithm, but the sheer human-hours required to put a working thing on the\ninternet. That's why the only viable answer for twenty years was to build\nsomething big enough to run ads against. Small social didn't exist because small\nsocial couldn't pay the salaries.
\nWith Claude Code, Cursor, v0, and Lovable, that equation has quietly inverted. A\nprofile page, a shared feed, a wall for photos, maybe a jukebox, a chat wall — a\nMySpace-sized thing for you and a dozen friends, on a domain you own, with none\nof it feeding anyone's ad platform — is a weekend. I know because I just did it.\nNot as some Silicon Valley startup trying to replace Facebook. As a Saturday\nproject for eight mates, on a domain that cost twelve bucks, running on a box\nthat costs ten a month.
\nThe bill of materials is embarrassingly short. A boring Postgres. A boring\nNext.js app. Auth via magic link. Storage for photos. An LLM for the fiddly bits\nnobody wants to write from scratch. All of it plumbed together in an afternoon\nof prompting, an evening of cleanup, and a Sunday of adding the jukebox because\nmy mate Hamish wouldn't stop asking.
\nIt is not good software. It is good enough software for eight humans who know\neach other.
\nThat qualifier is the whole thing. Facebook has to be good software at planet\nscale because Facebook is selling ad impressions at planet scale. A group of\neight doesn't need p99 latency and a content moderation policy. A group of eight\nneeds a place to put photos from the weekend where the photos don't end up\ntraining someone's image model in twelve months' time. Those are very different\nengineering problems, and the second one is much, much easier than the first.
\nA lot of things genuinely don't work on the weekend version. There's no\nrecommendation algorithm. There's no real search. The feed is\nreverse-chronological and that's it. When someone posts something at 3am nobody\nsees it until the morning. There's no cleverness about which photos get surfaced\nor which memories get resurrected. If you go on holiday for two weeks, you come\nback to a feed that's exactly what your eight mates posted, in the order they\nposted it.
\nThat sounds like a limitation until you notice the thing it is not doing is\noptimising for your engagement. Reverse-chronological across eight friends is\nnot a meter. It's a wall. You check it, you see what's there, you leave. There's\nno reason for the software to try to keep you around because there's nobody\npaying the software to keep you around. That inversion — from meter to wall — is\nthe entire point.
\nThe thing that would have been a VC round in 2015 is now a side quest you finish\nbefore the roast is in the oven. The tools genuinely got that much better in the\nlast eighteen months. We just haven't updated our intuitions yet about what that\nmeans.
\nWhat it means, specifically, is that the ad-supported social network is no\nlonger the only technically viable answer. For twenty years it was. That was the\nconstraint the whole "free web" was built around. The constraint is gone, and\nnobody has sent the memo.
\nThe cheapest social network in 2026 is the one you and six mates build on a\nSaturday afternoon. It doesn't scale. It doesn't need to. It costs less than a\nmonth of Netflix, produces no ad revenue for anyone, and feeds no one's training\nset. You own the domain. You own the data. You own the product decisions — which\nin practice means there are no product decisions, because nobody is trying to\nsqueeze another hour out of anyone's week.
\nNone of this replaces the platforms, to be clear. You still need Gmail for the\nrecruiter, LinkedIn for the job hunt, YouTube for the tutorial, WhatsApp for the\ngroup chat your family refuses to leave. The ad-supported internet isn't going\nanywhere and I'm not pretending it is. What's changed is that it's no longer the\nonly game in town. For the circle of people you actually care about — the eight\nmates, the cousins, the old uni flat — you don't have to hand them over to the\nad machine anymore. You can build them a room of their own, and the tools to\nbuild that room have become trivial in a way we haven't fully absorbed yet.
\nThe meter's been running your whole life. You just got the tools to turn it off.
\n","date_published":"Tue, 21 Apr 2026 12:00:00 GMT","image":"https://jonno.nz/og/what-an-hour-of-your-attention-is-worth.png"},{"id":"https://jonno.nz/posts/teaching-a-neural-network-to-watch-crime-like-video/","url":"https://jonno.nz/posts/teaching-a-neural-network-to-watch-crime-like-video/","title":"Teaching a Neural Network to Watch Crime Like Video","content_html":"ConvLSTM was invented to predict rainstorms.
\nSpecifically,\nShi et al. at HKUST, working with the Hong Kong Observatory,\nneeded to forecast radar echo maps: 2D grids of rainfall intensity that evolve\nover time. They had sequences of spatial images and wanted to predict the next\nframes. Sound familiar?
\nThat's exactly what we built in Part 3. Crime on a 500m grid, one frame per\nmonth, six channels for crime types. The Auckland crime tensor is structurally\nidentical to a weather radar sequence. Same dimensionality, same prediction\ntask, just a very different domain.
\nStandard LSTM networks are fantastic at learning sequences. They're the backbone\nof a lot of time-series forecasting. But they have a fundamental problem with\nspatial data: they need flat vectors as input.
\nTo feed our 77×59 grid into a regular LSTM, we'd have to flatten it into a\nvector of 4,543 values per crime type. That's 27,258 values per timestep across\nall six channels. The network would process this as a sequence of big flat\nvectors, with no concept that cell (10, 5) is next to cell (10, 6).
\nAll the spatial structure (the fact that crime clusters, that hotspots have\nneighbourhoods, that the CBD is a contiguous area) gets thrown away. The model\nwould have to rediscover spatial relationships from scratch, purely from\ncorrelations in the flattened vector. With only 36 training months, that's not\nhappening.
\nConvLSTM's insight is elegant. Take the standard LSTM equations (the input gate,\nforget gate, output gate, cell state update) and replace every matrix\nmultiplication with a convolution operation.
\nIn a regular LSTM:
\ninput_gate = sigmoid(W_xi * x_t + W_hi * h_{t-1} + b_i)\nIn ConvLSTM:
\ninput_gate = sigmoid(W_xi ∗ X_t + W_hi ∗ H_{t-1} + b_i)\nThat ∗ is a convolution instead of a matrix multiply. X_t is the full 2D\ngrid at time t, and H_{t-1} is the previous hidden state, also a 2D grid.\nThe convolution kernel slides across the spatial dimensions, so each cell's gate\nvalues depend on its local neighbourhood.
This means the network naturally learns that a spike in cell (10, 5) might\naffect predictions for cell (10, 6). Spatial proximity is baked into the\narchitecture. It doesn't need to learn it from data.
\nThe kernel size controls how much spatial context each cell sees. A 3×3 kernel\nmeans each cell looks at its immediate 8 neighbours. Stack multiple ConvLSTM\nlayers and the effective receptive field grows. Deeper layers can capture\nrelationships between cells that are several kilometres apart.
\nHere's what I settled on after a fair bit of experimentation (which on CPU means\n"a lot of patient waiting"):
\nInput: (batch, 6, 6, 77, 59), 6 months, 6 crime types, 77×59 grid\n ↓\nConvLSTM2d(in=6, hidden=32, kernel=3×3, padding=1)\n ↓\nBatchNorm2d\n ↓\nConvLSTM2d(in=32, hidden=32, kernel=3×3, padding=1)\n ↓\nBatchNorm2d\n ↓\nConv2d(in=32, out=6, kernel=1×1), project to 6 crime type channels\n ↓\nOutput: (batch, 6, 77, 59), next month prediction\nTwo ConvLSTM layers with 32 hidden channels each. The 3×3 kernel gives each cell\na neighbourhood view, and stacking two layers means the effective receptive\nfield covers about 1–1.5 km. Enough to capture the spatial extent of most crime\nhotspots.
\nWhy only 32 hidden channels? This is where the CPU constraint actually helps. A\nbigger model would be tempting with a GPU, but on a Ryzen 5 we need to keep it\ntight. 32 channels gives us about 200k trainable parameters: small enough to\ntrain in under an hour, large enough to learn meaningful spatial-temporal\npatterns.
\nThe 1×1 convolution at the end is a channel projection. It maps the 32 learned\nfeatures back to 6 crime type predictions.
\nThe lookback window is six months. The model sees January through June and\npredicts July. Then February through July to predict August. And so on.
\nSix months captures one half of the seasonal cycle, which turned out to be the\nsweet spot. Shorter sequences (3 months) missed seasonal context. Longer\nsequences (12 months) didn't improve results, likely because the model doesn't\nhave enough data to learn year-long dependencies with only 36 training months\ntotal.
\nThe training set gives us 30 sequences (months 1–6 predict 7, months 2–7 predict\n8, all the way to months 30–35 predict 36). That's not a lot. Every sequence\ncounts.
\noptimiser = Adam(lr=1e-4)\nloss = MSE # on log1p-transformed values\nbatch_size = 4 # small because sequences are large\nepochs = 150 with early stopping (patience=15)\nThe log1p transformation from Part 3 is critical here. Raw crime counts range\nfrom 0 to 50+. After log1p, the range compresses to 0–4. Without this, the\nloss function would be dominated by the handful of high-count CBD cells, and the\nmodel would essentially ignore the rest of the grid.
Training on CPU takes about 40 minutes per run. Not fast, but manageable. I\ncould typically fit in 3–4 experimental runs per evening, which meant progress\nwas slow but steady. Each run I'd tweak one thing (kernel size, hidden channels,\nlearning rate) and compare validation MAE.
\nEarly stopping triggers around epoch 80–100 in most runs. The model converges\nrelatively quickly, which makes sense given the small dataset and architecture.
\nSo how does ConvLSTM stack up against the baselines from Part 5?
\n| Crime Type | \nHist. Avg MAE | \nConvLSTM MAE | \nImprovement | \n
|---|---|---|---|
| Theft | \n1.28 | \n1.14 | \n10.9% | \n
| Burglary | \n0.35 | \n0.32 | \n8.6% | \n
| Assault | \n0.20 | \n0.19 | \n5.0% | \n
| Robbery | \n0.04 | \n0.04 | \n2.5% | \n
| Sexual | \n0.03 | \n0.03 | \n~0% | \n
| Harm | \n0.01 | \n0.01 | \n~0% | \n
| All types | \n0.39 | \n0.35 | \n10.3% | \n
A 10% improvement on the aggregate MAE. Not earth-shattering, but real.
\nTheft gets the biggest lift because there's the most signal to work with. The\nmodel genuinely learns spatial dynamics that the historical average can't\ncapture. When a cluster of cells in South Auckland trends upward over several\nmonths, ConvLSTM picks up on that momentum and adjusts its predictions\naccordingly.
\nBurglary sees a decent improvement too, likely driven by the spatial correlation\nwith theft that we spotted in the EDA.
\nFor the sparse crime types (robbery, sexual offences, harm) ConvLSTM basically\nlearns to predict near-zero, same as the baseline. There simply isn't enough\nsignal at 500m monthly resolution for these types. The model is honest about\nwhat it doesn't know, which I actually respect.
\nThe improvement isn't uniform across the grid. ConvLSTM does best in the\ntransition zones: cells on the edges of established hotspots where crime counts\nfluctuate month to month. It learns that these boundary cells tend to follow the\ntrend of their neighbours, which is exactly the kind of spatial-temporal pattern\nit was designed to capture.
\nIn the stable hotspot cores (the CBD, Manukau) the model performs about the same\nas the baseline. Those cells are consistently high, and the historical average\nalready captures that well.
\nWhere it properly struggles is with sudden spikes in normally quiet areas. A\ncell that's been near-zero for months and then gets 5 thefts in one month: the\nmodel doesn't see that coming. Neither does any other model, to be fair. Those\nevents are closer to random noise than learnable signal.
\nA 10% MAE improvement is meaningful but modest.\nRecent ConvLSTM crime prediction research\nreports larger gains, but those models typically work with much more data:\nyears of daily records across cities with higher crime density. Our setup is\ntougher. Monthly\nresolution limits temporal signal, Auckland is relatively low-crime by global\nstandards, and we only have four years.
\nThe model is also running on CPU with a deliberately small architecture. A\nbigger model on a GPU might squeeze out more performance. But the point of this\nproject was always to see how far you can push it with modest resources, and a\n10% beat over simple baselines feels like a real result.
\nThe question now is whether ST-ResNet's different approach to temporal modelling\ncan do better. ConvLSTM processes time as one continuous sequence. ST-ResNet\nbreaks it into three separate temporal scales: closeness, period, and trend.\nWith a seasonal dataset like crime, that decomposition might be exactly what's\nneeded.
\n","date_published":"Thu, 16 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/teaching-a-neural-network-to-watch-crime-like-video.png"},{"id":"https://jonno.nz/posts/open-source-agent-that-teaches-claude-code-your-architecture/","url":"https://jonno.nz/posts/open-source-agent-that-teaches-claude-code-your-architecture/","title":"Open-Source Agent That Teaches Claude Code Your Architecture","content_html":"AI has made building software cheap. A solo founder with Claude Code or Cursor\ncan ship an MVP in a weekend that would've taken a small team a month two years\nago. I've watched this happen across the NZ startup scene. Ideas that used to\ndie in the "can we afford to build it" phase now get built over a long weekend.
\nThis is mostly great. Velocity is what startups need. Cost of testing an idea is\nnow close to zero, and the business prioritises speed.
\nThe catch shows up when the idea works.
\nAI builds for right now. It optimises for the current prompt, the current\nfile, the current feature. It doesn't think about what happens when your billing\nservice needs to handle 10x the volume, or when your email notifications need to\nmove from inline calls to a queue. It doesn't plan for the evolutionary pressure\nyour system will face once it has users.
\nThat's the gap I've been thinking about, and it's what led me to build\ndomain-agents.
\nI want to be fair to the current generation of AI coding assistants. They're not\nstupid about finding code.
\nClaude Code runs an agentic search loop (grep, glob, file reads) iterating\nthrough your codebase to find what's relevant. Boris Cherny (who created Claude\nCode) has said they tried\nRAG with a local vector database early on and dropped it because agentic search\noutperformed it. Cursor takes a different approach: it\nchunks your codebase, generates embeddings,\nand stores them for semantic search so you can find code by concept rather than\nkeyword. Copilot combines semantic indexing with LSP-powered reference tracing\nfrom VS Code.
\nThe search works. If you ask Claude Code to find your billing service, it'll\nfind it. Ask Cursor for authentication logic and the embeddings will surface it\neven if the code never uses the word "authentication."
\nNone of them understand the architecture those files live in.
\nAll the information needed to understand domain relationships sits in the code:\nimport graphs, interface signatures, dependency patterns. These tools don't\nextract or structure it that way. They find files one at a time. They don't map\nout that your billing service depends on the email service, that\nBillingService is consumed by two other domains, or that changing its\ninterface is a cross-domain event. The information is in the codebase. Nobody's\npulling it together.
And every session starts from zero. The AI learned your architecture yesterday\nand forgot it today.
\nMy thesis: cheap AI-built MVPs plus expensive scaling problems point toward\nevolutionary architecture with domain-based boundaries.
\nThe idea isn't new. The reason it matters now is.
\nIn an evolutionary architecture, you focus on clean interfaces between business\ndomains. Your email service exposes a contract like\nsendEmail(to, subject, body), and the rest of the system calls that interface.\nBehind the interface, the implementation evolves through stages as your scaling\nneeds change:
graph LR\n A["Inline\\n(direct call)"] --> B["Async\\n(fire & forget)"]\n B --> C["Queued\\n(BullMQ/SQS)"]\n C --> D["Separate Service"]\n D --> E["Distributed"]\nDay one, sendEmail is a function that calls Resend directly. Inline,\nsynchronous, dead simple. When traffic picks up, you drop the await and let it\nrun in the background. Later, you introduce BullMQ or SQS. Eventually it becomes\nits own service. The interface stays put. Only the implementation behind it\nchanges.
This is the kind of evolution AI coding assistants are terrible at planning for.\nThey'll inline that email call because it works right now. They have no\nconcept of where this domain sits on its scaling trajectory.
\ndomain-agents is a CLI tool that\nruns static analysis on TypeScript codebases, discovers business domains, and\ngenerates AI agent context files for Claude Code and Cursor.
\ndomain-agents discover . # Analyse codebase → proposal.json\ndomain-agents init . # Generate agents/*.md + AGENTS.md\ndomain-agents hooks claude # Wire into Claude Code (rules + MCP server)\ndomain-agents hooks cursor # Wire into Cursor (.mdc rules)\nAfter setup, opening src/billing/invoice.ts in Claude Code loads the billing\ndomain agent into context. The AI now knows: billing depends on email (coupling\nscore 0.23), exposes BillingService consumed by 2 other domains, sits at the\n"inline" scaling stage with a path toward async queuing, and has 3 tracked tech\ndebt items.
It plans work accordingly. The context was loaded before the first prompt, no\nsearch required.
\nThe discovery engine runs 5 analysis passes because no single signal identifies\nbusiness domains on its own.
\nDirectory structure works for greenfield projects (src/auth/, src/billing/)\nbut fails for legacy MVC apps. Import graphs capture coupling but not business\nintent. Package dependencies hint at external integrations but miss internal\ndomains.
graph TD\n S["Structure Analysis"] --> O["Signal Orchestrator"]\n I["Import Graph\\n(TS Compiler API)"] --> O\n N["Naming Patterns"] --> O\n D["Dependency Mapping\\n(npm → domain hints)"] --> O\n IF["Interface Detection"] --> O\n O --> M["Merge Pipeline"]\n M --> R["Domain Proposal"]\nStructure detects whether the codebase is feature-organised,\nlayer-organised, mixed, or flat. Import graph uses the TypeScript Compiler\nAPI to parse each .ts file, resolve imports, and build a directed edge graph.\nType-only imports get weighted at 0.3 because they're a weaker coupling signal\nthan value imports. Naming patterns extract domain prefixes:\nauth.controller.ts → "auth". Dependency mapping maps npm packages to\ndomain hints (stripe → billing, @sendgrid/mail → email). Interface\ndetection identifies files imported across domain boundaries and calculates\ncoupling scores between domain pairs.
Each pass produces weighted signals. The orchestrator combines them with\nconfidence scoring: average signal strength plus a bonus for signal count,\ncapped at 0.99. Layer-organised codebases get an 0.85 multiplier because they're\nharder to discover.
\nFeature-organised codebases are easy. The directory structure is the domain.\nBut most real codebases look like this:
\nsrc/\n controllers/\n auth.controller.ts\n billing.controller.ts\n services/\n auth.service.ts\n billing.service.ts\n models/\n invoice.model.ts\n user.model.ts\nHere auth.controller.ts, auth.service.ts, and auth.routes.ts all belong to\nthe "auth" domain despite living in three different directories. domain-agents\nuses naming pattern extraction cross-referenced with import graph cohesion to\ncluster these. The auth.* files form a tight import cluster, which confirms\nthe naming signal.
Raw signals produce too many small, overlapping clusters. The orchestrator runs\na multi-phase normalisation pipeline.
\nPlurals merge: journals + journal → whichever has more files. Compound names\nconsolidate: bank-balance + bank-statement + bank-transaction →\nbank-accounts (the largest cluster). Small clusters merge into their strongest\nimport target, but only if they have a dominant dependency: more than 40% of\nimports from one target, and that target is at least 2x larger. This prevents\ncascading, where A merges into B, B gets bigger and attracts C, C pulls in D.
Files that import from 3+ domains get moved to "unassigned." These are coupling\nhotspots: middleware, orchestrators, shared handlers. Assigning them to one\ndomain would mislead the AI, so the tool surfaces them for a human decision.\nThat's the right call for architectural boundaries.
\nThe E2E test suite validates the complete pipeline against 3 fixture codebases\n(feature-organised, layer-organised, mixed). Current benchmark: 100% activation\naccuracy across all 3 patterns and all 3 activation levels (domain assignment,\nglob matching, MCP lookup).
\nThe integration into Claude Code and Cursor uses glob-based rule activation, the\nnative mechanism both tools already support.
\nEach domain gets a rule file with glob patterns in the frontmatter:
\n---\ndescription: billing domain\nglobs:\n - src/billing/**\n - **/billing.*\n - **/billing-*\n---\nWhen Claude Code opens a file matching those globs, the domain context loads. No\nMCP call, no background process, zero runtime overhead.
\nAn MCP server complements the rules with 4\non-demand tools: domain_lookup(file), domain_context(name),\ndomain_files(name), and list_domains(). A SessionStart hook prints a domain\nsummary at the start of every Claude Code session, so the AI has system-level\nawareness from the first prompt.
This is the bit I'm most keen on long-term.
\nAt Vend and Xero, teams owned domains. The billing team owned billing, the\nintegrations team owned integrations. Ownership meant knowing the interfaces,\nthe coupling points, the tech debt, and where things were headed. That knowledge\nlived in people's heads and got passed on through code reviews, architecture\nchats, and tribal memory.
\nDomain-specific AI agents formalise that same ownership model. An email agent\nloads the email domain's interface contract, its coupling to other domains, its\ncurrent scaling stage, and its tracked tech debt. A billing agent carries the\nsame for billing. They work within their boundaries and flag when a change\ncrosses a domain line.
\nYou don't need this from day one. Early on, one agent covers multiple areas. As\nthe product grows, agents split along the same lines engineering teams split: by\nbusiness domain. The operator (that's you) resolves conflicts where agents\ndisagree, the same way an engineering manager resolves cross-team dependencies.
\nThe analogy is rough, but it captures how AI-assisted development scales past a\nsingle person staring at a single context window.
\n","date_published":"Wed, 15 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/open-source-agent-that-teaches-claude-code-your-architecture.png"},{"id":"https://jonno.nz/posts/openhealth-chat-with-apple-health-data/","url":"https://jonno.nz/posts/openhealth-chat-with-apple-health-data/","title":"OpenHealth – Chat with Apple Health Data, Anywhere","content_html":"For years I've worn an Apple Watch and let my iPhone quietly hoover up my\nresting heart rate, HRV, sleep stages, every workout, every nutrition log.\nMillions of data points. And for most of that time, when I wanted to actually\nask something about my training — "am I cooked this week?", "has my recovery\ngotten worse since Christmas?" — I'd open ChatGPT and get an answer that was\nbasically vibes, because it couldn't see any of the data.
\nSo I built openhealth. It turns your\nApple Health export into seven short markdown files any LLM can read. Drop the\nzip in your browser at\nopenhealth-axd.pages.dev, run the CLI, or\nbeam the zip straight from your iPhone over WebRTC. Paste the output into Claude\nor ChatGPT and start asking the questions you actually wanted to ask.
\n![\"openhealth's](\"https://jonno.nz/img/posts/openhealth/hero.png\")
In January, Anthropic\nshipped an Apple Health connector\nfor Claude. OpenAI has one in ChatGPT. Both are US-only — if you're in New\nZealand like me, or the UK, EU, or Switzerland,\nthey're not available. That's\na lot of people locked out of the most natural way to use this data.
\nAnd even if you are in the US, you're letting Anthropic or OpenAI decide what\nthe model reads, how it's framed, and what tier unlocks it. I wanted control\nover the whole pipeline — including which LLM I feed it into.
\nopenhealth ships three ways.
\nA static web app. Drop export.zip, wait five seconds, download seven\nfiles. The browser does the parse. There's no upload endpoint because there's no\nserver — the Cloudflare Pages site is static HTML plus a tiny Web Worker. Open\nDevTools, watch the Network panel, nothing goes out.
A Bun-compiled CLI. openhealth ~/export.zip -o ./output gets you seven\nmarkdown files. --bundle concatenates them into one. --clipboard pushes that\nbundle straight to your system clipboard so you can paste it into any chat\nwindow. Zero deps beyond saxes for XML and fflate for unzip — even the\nargument parsing is node:util parseArgs, not Commander. One binary, put it\nwherever.
A phone-to-desktop handoff over WebRTC. The desktop site renders a QR code.\nPoint your iPhone camera at it, Safari opens a tiny receiver page, pick the zip,\nand it streams directly to your desktop browser over a DataChannel. The only\nbackend in the whole stack is a ~100-line Cloudflare Worker that relays the\nWebRTC handshake — it never sees a byte of your health data.
\n![\"Getting](\"https://jonno.nz/img/posts/openhealth/walkthrough.png\")
Apple's export.xml is\nproperly huge.\nA long-term Watch user can easily have a 500MB–4GB file with millions of rows.\nMost XML parsers build a tree in memory, which OOMs before they finish.
openhealth uses saxes — a streaming SAX\nparser in pure TypeScript. It's isomorphic, so the same parser runs in Bun,\nNode, and the browser. I tested it against a synthetic 169MB / 1 million-record\nexport and it finished in about 5 seconds in Chrome, with the main-thread heap\nstaying around 5MB because the parse runs in a Web Worker.
\nThe rest of the core is a small pipeline: stream XML, accumulate\nper-record-type, roll up into weekly and monthly summaries, run each through a\nwriter that produces one markdown file. Every writer is snapshot-tested against\nbyte-for-byte expected output. 85 tests, TDD throughout.
\nEach one is deliberately small and shaped to be LLM-readable:
\nhealth_profile.md — baselines, data sources, long-term averagesweekly_summary.md — current week plus a 4-week rolling comparison with\nweek-over-week deltasworkouts.md — detailed log for the last 4 weeks: HR, duration, distance,\nenergybody_composition.md — weight trend, recent readings, nutrition averagessleep_recovery.md — nightly stages, 8-week averages, HRV, resting HR, SpO2\ntrendscardio_fitness.md — running log, HR-zone distribution, walking-speed trendsprompt.md — a ready-to-paste system prompt that frames the other six as\ncoaching inputDrop one file or all seven, depending on which chat model you're using.
\nFeeding real data to an LLM is a different experience from answering its\nquestions. When Claude can see that my resting HR has crept up 4bpm over the\nlast fortnight while my HRV has dropped and my training load stayed the same, it\ngives a real answer — "you're likely undercooked on recovery this week, here's\nwhat I'd change" — rather than a generic reminder to drink water.
\nIt's especially good if you've got multiple devices in the mix. I've got data\nfrom Apple Watch, the iPhone step counter, a Withings scale, and MyFitnessPal.\nThe parser picks the highest-trust source per metric — Apple Watch wins over\niPhone for steps, Watch sleep beats AutoSleep which beats Withings,\nduplicate-weight entries on the same day get deduped. You feed in one zip and\nget one coherent picture.
\nAsk it about your recovery, your training load, what you might be doing wrong,\nhow your sleep correlates with your long runs. It'll tell you — and it'll be\nright more often than not.
\nopenhealth itself never uploads your data. The web app parses in your browser\ntab. The CLI runs locally. The WebRTC handoff stays peer-to-peer — the\nCloudflare Worker that relays the handshake never sees a byte of the file. Clone\nthe repo, diff the build output, and confirm it yourself.
\nWhen you paste the seven files into ChatGPT or Claude, they see the data.\nThat's the trade most people will take for convenience, and it's fine. But if\nyou don't want to make that trade, you don't have to — run the CLI and pipe the\nbundle into a local model:
\nopenhealth ~/export.zip --bundle -o ./out\nollama run llama3 < ./out/openhealth.md\nOllama, llama.cpp, LM Studio, whatever you run. Your health data never leaves\nyour laptop. The output is just markdown — it doesn't care what reads it.
\nThat's why the shape is seven files and not an API. You pick what sees them.
\nI'm not a doctor. Neither is the model. Use this for thinking out loud about\nyour own training, not diagnosing anything.
\nMIT, source at\ngithub.com/jonnonz1/openhealth. Web\napp at openhealth-axd.pages.dev. If you've\nbeen sitting on a 200MB export.zip with nothing that'll open it, have a go.
The moment this project went from "fun weekend hack" to something I actually use\nevery day was when I got the MCP server working. Claude Code on my laptop sends\na prompt to the orchestrator sitting under my desk, which boots a VM, runs\nClaude Code inside it with full permissions, and streams the results back.\nClaude delegating work to Claude.
\nIt's a weird feeling watching it happen. You're in a conversation with Claude,\nit decides a task needs isolation, calls the MCP tool, and a few seconds later\nyou can see a fresh VM spinning up in the dashboard. Like having an intern who\ncan clone themselves.
\nPart 1\ncovered why I built this.\nPart 2 was the\nguts of it — rootfs, networking, the guest agent. This last post is about the\ninterfaces, the streaming pipeline, and what I'd change if this needed to work\nfor more than just me.
\nThe orchestrator exposes an MCP server with\neight tools. The main one is run_task — give it a prompt, optional config\n(RAM, vCPUs, timeout, max turns), and it blocks until the task completes.\nReturns the task ID, status, exit code, result files, cost, and the output\ntruncated to 4000 characters.
Two transport modes. Stdio for when Claude Code runs on the same machine:
\n{\n "mcpServers": {\n "orchestrator": {\n "command": "sudo",\n "args": ["/opt/firecracker/bin/orchestrator", "mcp"]\n }\n }\n}\nAnd Streamable HTTP for network access — Claude Code on any machine on the LAN\ncan use it:
\n{\n "mcpServers": {\n "orchestrator": {\n "type": "http",\n "url": "http://192.168.50.44:8081/mcp"\n }\n }\n}\nThe other tools are for poking around: get_task_status, list_vms,\nexec_in_vm (run a command in a still-running VM), read_vm_file,\ndestroy_vm, list_task_files, and get_task_file. That last one is smart\nabout content types — text files come back as plain text, images come back as\nbase64 MCP image content so Claude can actually see screenshots the VM took.
if isImageMime(mimeType) {\n encoded := base64.StdEncoding.EncodeToString(data)\n return mcplib.NewToolResultImage("Screenshot from task "+taskID, encoded, mimeType), nil\n}\nThis bit is worth telling because it'll save someone else the debugging time.
\nI originally built the MCP server with\nmcp-go v0.45.0 using SSE (Server-Sent\nEvents) transport. Worked great. Then Claude Code updated to expect the newer\nStreamable HTTP transport, and everything fell over.
\nThe failure mode was confusing. Claude Code would try to connect, attempt OAuth\ndiscovery against the /sse endpoint, get a 404 (my server doesn't do OAuth),\nand fail with:
Error: HTTP 404: Invalid OAuth error response: SyntaxError: JSON Parse error: Unable to parse JSON string\nNothing in my code changed. The client just started speaking a different\nprotocol.
\nThe fix was small once I understood it:
\n// Before — SSE transport\nfunc (s *Server) ServeSSE(addr string) error {\n sseServer := server.NewSSEServer(s.mcpServer,\n server.WithBaseURL("http://"+addr),\n )\n return sseServer.Start(addr)\n}\n\n// After — Streamable HTTP transport\nfunc (s *Server) ServeHTTP(addr string) error {\n httpServer := server.NewStreamableHTTPServer(s.mcpServer,\n server.WithEndpointPath("/mcp"),\n server.WithStateLess(true),\n )\n return httpServer.Start(addr)\n}\nBumped mcp-go from v0.45.0 to v0.46.0, swapped the server constructor, changed\nthe endpoint from /sse to /mcp, updated the client config. Done. But\ndiagnosing "OAuth error on a server that doesn't do OAuth" — that bit took a\nwhile.
When Claude Code runs inside a VM, its output needs to get from stdout inside\nthe guest all the way to a browser tab on my laptop. The path:
\nflowchart LR\n A["Claude Code stdout"] --> B["Guest agent\\nvsock frame"]\n B --> C["Host vsock client\\nExecStream"]\n C --> D["Task runner\\nOnEvent callback"]\n D --> E["Stream Hub\\nring buffer + fan-out"]\n E --> F["WebSocket\\nto browser"]\nThe stream hub (internal/stream/hub.go) is a per-task pub/sub system. Each\ntask gets a stream with a 1000-event ring buffer. When a WebSocket client\nconnects, it gets all the buffered history first, then live events as they\narrive.
Fan-out is non-blocking:
\nfor ch := range s.subscribers {\n select {\n case ch <- event:\n default:\n // Subscriber is slow, drop the event\n }\n}\nA slow WebSocket client can't block the task runner. If the browser can't keep\nup, it misses events. In practice this never happens because the bottleneck is\nalways Claude thinking, not the network.
\nThe React frontend is compiled to static files and embedded into the Go binary:
\n//go:embed all:web-dist\nvar webDistEmbed embed.FS\nSingle binary deployment. No nginx, no separate frontend server, no CORS\nheadaches in production. The API server falls through to index.html for\nunknown paths, which gives you SPA client-side routing.
The most interesting page is the task detail view. Claude Code's\n--output-format stream-json spits out one JSON object per line — thinking\nblocks, text responses, tool calls, tool results, cost summaries. The dashboard\nparses these into coloured blocks:
A useWebSocket hook connects when the task is running and disconnects when\nit's done. Green pulsing dot for live streaming. Auto-scroll to the bottom as\nevents arrive. Image files in the results get inline previews pointing at the\nAPI's file download endpoint — so when Claude takes a screenshot inside the VM,\nyou see it immediately.
Dark theme. Orange accents. Obviously.
\nThis runs on one box with no auth. It's a home lab project. But the gap between\n"works for me" and "works for a small team" isn't as big as it looks.
\nPersistence is the most obvious one. The task store is an in-memory Go map.\nOrchestrator restarts? All task history gone. VM metadata already persists to\ndisk and gets recovered on startup — tasks should too. SQLite or bbolt, a few\nhours of work. I just haven't needed it because I don't restart the process very\noften.
\nTask queue with backpressure. Right now tasks fire as goroutines with no\nconcurrency limit. Submit 20 tasks on a 30GB machine where each VM wants 2GB and\nthe last few fail because there's no memory left. A buffered channel or\nsemaphore would fix this. You could get fancier with priority queues — quick\ncode generation tasks ahead of long research tasks — but even a simple\nconcurrency cap would be enough.
\nAuthentication. The REST API and MCP server accept requests from anyone who\ncan reach the port. For a team: API keys at minimum, mTLS if you're serious\nabout it. The MCP spec supports auth flows now — that'd be the right way to do\nit for the MCP endpoint.
\nThe OnEvent callback race. This one's a latent bug. The task runner's\nOnEvent callback is stored on the runner struct, not passed per-task:
s.taskRunner.OnEvent = func(id string, event agent.StreamEvent) {\n taskStream.Publish(event)\n}\ns.taskRunner.Run(context.Background(), t)\nTwo simultaneous tasks overwrite each other's callbacks. It works today because\nMCP tasks block (one at a time) and the API handler sets up the stream before\nthe goroutine runs. But it's the kind of thing that works until it doesn't. Fix\nis trivial — pass the callback into Run() as a parameter.
Graceful shutdown. There's no signal handler. Ctrl-C kills the process,\nrunning VMs become orphans. They keep running as Firecracker processes — the\nrecoverState() function on next startup finds them and starts tracking them\nagain — but their tasks are lost. A proper signal handler would stop accepting\nnew tasks, wait for running ones to finish with a timeout, then tear everything\ndown cleanly.
For real multi-user you'd want result storage on S3 or R2 instead of local\ndisk. A web auth layer. Per-user credential vaults so different people's Claude\ntokens don't mix. Usage tracking and cost attribution.
\nWhat I wouldn't change: the single-binary deployment, vsock for host-guest\ncommunication, ephemeral VMs as the isolation model, the embedded frontend.\nThose are the right calls regardless of scale. The architecture is sound — it's\nthe operational bits around it that need work.
\nMost of these are a weekend each. The project is about 3,200 lines of Go and 860\nof TypeScript. It's not a big codebase. Adding persistence, auth, and a task\nqueue would maybe take it to 4,500 lines. Still fits in your head.
\nFor now, it sits under my desk and boots VMs when I ask it to. Claude delegating\nto Claude, in complete isolation, on hardware I own. That's enough.
\n","date_published":"Mon, 13 Apr 2026 00:00:00 GMT","image":"https://jonno.nz/og/claude-code-can-now-spawn-copies-of-itself-in-isolated-vms.png"}]}