The expensive part was never building it

The repair path

HurricaneWise has nineteen health checks. Four of them run outside its infrastructure, on Grafana, since a server that's down usually can't say so; the fastest runs every 60 seconds and the others every three minutes. The rest run on the server's own 15-minute loop or on the status route. Six check the checkers using what the OS reports, and if the OS reports nothing they just return no result. Two bad checks in a row open an incident, and the incident says what failed and what still works. Then the AI writes it up twice: a notice for visitors, and an engineering report with links into the logs.

It attempts every failure its own monitoring detects. There is no approved list. The one exception is an incident that affects the resolver itself, and that comes to me. The system opens the issue against itself with a written severity, closes it when service comes back, and keeps a post-mortem for every resolved incident. I need that record to see what the resolver actually worked on, including the times it couldn't finish.

Every five minutes the resolver checks for work. Only one session runs at a time (there's a lock), and it works in a workspace that gets reset to a clean copy of main before and after every run. The AI session doesn't hold a GitHub credential, or any database, storage, vault or deploy credential. It has a clock, a turn limit and a spending cap, and it runs on its own ops API key. Nothing it writes leaves the machine until the full test suite passes locally.

The constitution requires a traceable chain for every fix, so every step from the session to the live site leaves a record. The orchestrator around the AI pushes fix branches and merges the pull request that session made, and nothing else, and that's enforced in code. Before the merge, lint, types, the full test suite and browser tests on desktop and mobile all have to pass. Merging tags a release and the tag deploys. Then the system loads the live site (passing tests don't tell you much about the deployed page), writes the post-mortem and emails me the trail.

If any stage fails, the incident gets marked as needing a person and the fix is not deployed. It shows up on the operations dashboard and I get an email. A paid session can end without a usable repair, so the record has to show that too. There are two switches on that dashboard, behind Cloudflare Access: one stops the resolver, the other stops its permission to deploy. Access fails closed.

What the resolver may change

I call the boundary the envelope. Inside it the resolver can repair behavior that already exists: the feeds, the data processing, storage, the incident pipeline, and the checks on those jobs.

New features, data sources, pipelines, layout and interface changes, and performance work stay with me. If the product changed while a repair was running, a new failure would have two possible causes and I couldn't tell which. A broken parser for an existing NHC feed counts as repair (so does a monitor that reported healthy on stale data). Adding a feed or redrawing the storm page doesn't, even if the session could write the code.

The session instructions and the incidents it gets hold that boundary. There's no file permission stopping the AI from editing a page. The model is asked for the smallest corrective change and handed a detected fault, which usually points it at existing behavior, and then the tests check whether the fix works. I don't think those controls prove that every out-of-scope change would get caught.

I wanted to try automated repair while keeping product direction for myself, and where a failure shows the instructions were weak I'll tighten them.

Limits on a session

Once the mechanism worked, most of my time went into the limits. A session that gets cut off early has spent the money and there's no fix, so the turn and time limits had to leave enough room to finish an ordinary repair.

Right now it's 80 turns, two hours, $15 a session (where I take a look) and $50 a day (where everything stops), with at most 12 sessions a day. I set those after watching runs and I expect to move them again. Repair spend is on its own ops API key, so it shows up separately from the weather interpretation. How HurricaneWise ships its own repairs goes through each control along the release path, including what happens when a fix fails its checks.

Costs

For most software, on-call and the monitoring bill were the expensive half, and you paid them every month. Both are getting cheaper. Model time costs a fraction of what it did (Stanford's AI Index 2025 has GPT-3.5-level inference falling more than 280-fold from November 2022 to October 2024). Here the model does operations work: it interprets the weather and it repairs the system. My own design and review time isn't in the bill below. Steady every-minute work sits on one fixed-price server and the bursty public traffic goes to managed platforms. The NHC poll runs every minute, but the core database only wakes up when an advisory changes, roughly 8 to 15 times a day.

My cost model puts it at about $15 in a typical month and about $40 in a stormy peak month. The server is $7.60 ($6.99 for the box plus $0.60 for the public IP). AI is roughly $7, because it interprets forecasts and also runs repairs. Neon, Cloudflare R2, Vercel, Grafana Cloud and GitHub Actions cost $0 on free tiers, and I set it up that way on purpose.

Earlier in 2026 the estimate was about $9. The server went from $5.25 to $7.60, and AI went from roughly $3.60 to roughly $7 once it took on repairs. I get those numbers from a script I run myself that pulls usage from every provider and lays the bill out line by line; the repair agent's spend is metered separately on its own key. They're estimates, so I don't read a quiet month as what the next storm will cost.

The tightest free-tier limit is Grafana's synthetic checks. The monitoring is designed to use about 86% of the free plan's 100,000 checks a month, and it's the four outside checks that spend it, so I set their cadences against that allowance. Before I add another probe I look at what's left.

The roles I covered

A production product needs a lot of roles, and most of them have little to do with writing code. On this one I designed the health checks and alert thresholds, and handled incidents from detection to the written record. I wired metrics and logs, and decided which work went on a managed platform and which on a fixed-price box. Security review was mine too, including the zero-trust check in front of the operations dashboard. Then the frontend (I argued a lot about the mobile layout), the backend and data pipeline, nine prompts that each do one job, the repair path and its limits, and CI and deploys. I also ran issues, the roadmap and the board, owned the bill, wrote what a visitor reads during a storm, built the status page, and wrote the constitution where all of those rules live now.

Then there were the ones I'd never done: branding and design, a legal review of the disclaimers, and marketing plus the search work that goes with it. I wasn't good at any of them at the start. I still got usable work in all of them, because each seat had a specialist that knew the field better than I did and kept going every time I said the answer wasn't right yet.

Mostly I asked what backed a recommendation. If it didn't fit what I want the tracker to do I sent it back. The work in those fields came out better than anything I'd have done myself.

The work and the human decision in each seat are on the discipline map.

What HurricaneWise is

HurricaneWise reads official NHC and NOAA data and tracks eleven forecast models, including the official forecast and two consensus aids. Claude takes those professional models and explains them in plain English for your location; it doesn't make a forecast of its own. I built it because I live where hurricanes go.

I kept it small on purpose, so one person can see every discipline at once and check any number in an afternoon. There are no accounts and no personalization. The feedback form keeps an IP and browser string for abuse control, Turnstile gets verified on the server, the form has a per-IP limit, and two privileged routes need tokens. Nothing a visitor types goes to the model.

As of mid-October 2026 the repo is at 357 commits, 156 tagged releases and about 2,200 automated tests. The constitution (v1.0.0, ratified 2026-07-26 after an adversarial review) requires a failing test before any bug fix, a post-mortem for every resolved incident, and a manifest entry for every monitor before the monitor exists, and the tests fail if those drift apart.

The first working version took about three weeks, May 30 to June 21, 2026: 184 commits, and 91 of them were fixes. After it looked finished I kept working on the checks and the operating rules. A storm that had dissipated stayed on the page. A health check stayed green while the data behind it went stale. Both needed tests and monitoring changes before I could trust its incidents enough to start automated repair from them.

Product decisions

The resolver only repairs existing behavior, so new features and changes to what the tracker offers are still decisions I make.

People can already send feedback, and it lands in the same issue tracker as everything else. The resolver only sees incidents about existing behavior, though. It doesn't turn feedback into product changes and I haven't written rules that would let it. For a bug fix there's a test that shows the old behavior is back. Picking which feedback becomes a feature means weighing one group of users against another and against what it costs to maintain, and that answer changes as the product does.

I haven't built anything that makes product calls, ships features or acts on user feedback. Fully autonomous would need those too.

On a bigger system

HurricaneWise is small enough that I can inspect every part of the repair path. A bigger system has more owners and a wider blast radius.

More owners means separation of duties. Once there are users with accounts you also get identity, permissions, retention, audit, and a blast radius that includes other people's work, and every one of those makes the repair rules harder to write. The controls themselves are ones a company already runs: written rules, CI gates that decide the merge, budgets with a hard ceiling, an audit trail and a switch a person holds. I think they carry over if they're in place from the start.

I'm trying the same approach on Longview, the private system that runs my home. As of September 2026 it tracks 35 components and 39 warranties. Its repair agent is structurally barred from merging or deploying. I set that line separately for each system.

Who can try an idea now

A working prototype, something a person can react to or fund, takes weeks now, without a hire or months learning the tools (in McKinsey's 2026 survey, 32% of organizations had skipped buying at least one software product or feature because agentic coding tools let them build it in-house). Making it usable and finding people who need it is still hard, and I don't think that part got much cheaper.

In my case it was a small thing for a problem I already had. I ran it on real inputs and fixed what I could measure, and the AI set up the tools I didn't know.

I didn't want to wait on this while other people shipped, whatever AI ends up doing to the number of people building. So HurricaneWise ran in front of real storms before it had written rules. I spent about two months after that fixing what the monitoring caught, before the resolver could act on its incidents. It started as a problem I already had, run on real inputs.