Three weeks, 184 commits, and 91 of them were fixes

The experiment underneath the tracker

I wanted a hurricane tracker for my own house. I live where the storms go, the official forecast products are written by meteorologists for meteorologists, and every consumer app I tried either buried the useful part or dressed the whole thing up as a disaster movie. So I built one. It reads the National Hurricane Center and NOAA feeds, runs more than fifteen professional models through a model that explains them, and answers one question in plain English: where do the models agree, where do they disagree, and what does that mean for where you are.

That was the excuse. The actual experiment was narrower and I knew it going in. Could one person plus AI take a hobby all the way into real production, and then keep it alive without babysitting it? Not a demo that works once on a good day. A live thing with uptime, incidents, a legal surface, an observability stack, and a bill.

The first working version took about three weeks and 184 commits. Ninety-one of those commits were fixes.

What a fifty percent fix rate actually tells you

I have seen that number quoted back at me as a criticism, and I understand why. It is also the single most useful thing I learned. AI is extremely good at the first version of anything. It is fluent, it is fast, it never gets bored, and it produces code that runs. What it does not produce is code that has met reality yet.

Every one of those 91 fixes was reality disagreeing. A storm that dissipated but stayed on the page. A health check that reported green while the data behind it went stale. A cron schedule that turned out to be a suggestion. A JSON response that truncated at exactly the wrong byte. None of those were things a better prompt would have prevented, because none of them existed until the system had been running for a while against a source it did not control. The phantom storm walks through five of them in detail, because they are the most instructive thing in the project.

So the real work was never the first version. It was the second and the third, after the world filed its objection. That is not a new idea in engineering. What is new is the ratio. When the first version costs almost nothing, you get to the objections much faster, and you spend almost all of your time there.

The division of labour that made this possible

There is a specific kind of work that has quietly dominated every infrastructure project I have ever done. Two days inside a vendor's documentation learning which keys their agent wants in its config file. An afternoon working out what their free tier actually counts. A morning on which of their four auth flows applies to your case. Multiply that by every system a real product touches, and you get weeks, in a different specialist's discipline each time.

On this project that entire layer became a conversation. Observability is the cleanest example. I will probably never master the Grafana agent's configuration language, and I no longer need to. I know what it can do, which is enough to decide what to hand over and where to check. I said what I wanted watched: the pipeline, the host, the logs, and the public site from the outside. The AI read the documentation, wrote the agent config, wired the synthetic checks, and came back with the part I actually needed, which was the free-tier ceilings and where we would sit against them. Along the way it surfaced a few features I would not have known to ask for.

The same pattern set up the scheduled services on the server, the zero-trust door on the internal dashboard, the vault wiring for secrets, and a parser for NOAA's fixed-width storm format, which is a file layout older than most of the people who use it. Each of those used to be a specialty you hired for or spent a fortnight becoming.

What did not move is the part my fifteen years are for. I decided what deserved watching and what did not. I set every alert threshold. I decided which checks had to run every sixty seconds and which could amble along every fifteen minutes. And I caught the confidently wrong configuration that was about to burn a free tier, more than once, because the model had no idea that the number it had chosen was a bill.

The chairs I had to sit in

A product is a stack of roles and most of them are not writing code. On a normal day I would be the analyst turning fifteen disagreeing models into one read, then the reliability engineer designing the health checks, then the cost owner fighting to keep a service inside its free band, then the legal reviewer on the disclaimers, then the product designer on the mobile layout, then the copywriter on the words that go on the page during a storm.

None of those were hires. Each was the same model, pointed at a different job, with a different brief and a different bar to clear.

The skill that mattered was knowing what each chair required before I sat in it, and being able to tell when the work in it was not good enough yet. That skill did not come from the model. What a room of specialists like that ends up teaching the person grading them is the argument of The job moved up a level.

Where it is now

Since the first version shipped, the project has grown to 312 commits, 125 tagged production releases, and about 1,880 tests. The operating rules that used to live in my head became a versioned constitution where "must" and "never" are load-bearing words, because AI agents write most of the code now and they only obey rules that live somewhere they can read them.

The pipeline checks for new data every sixty seconds. Probes outside my infrastructure load the real site every minute, the way a visitor would. When something breaks, the system opens a ticket that names what is down and what still works, links straight into the right logs, and closes itself when the service recovers. Every resolved incident gets a written postmortem, which is a rule in the constitution rather than a habit I keep.

Since this summer it goes one step further. When its own monitoring detects a failure, it writes the fix itself, opens a pull request, passes the same checks any change of mine would face, ships, and then verifies the live site before calling it done. There is no approved list of failures it is allowed to touch, because detection is the permit: if the system can see it, the system may try to fix it. What it may not do is change what the product is. The AI opens the pull request is the whole mechanism.

All of it runs for about $15 a month, and roughly half of that is one small fixed server.

The experiment this was really for

The scope of this thing is small and the treatment is not. It serves a public weather read that regenerates continuously, holds no accounts, and stores nothing private about anyone. I kept it that small on purpose: at this size every discipline is visible at once and every number can be checked by one person in an afternoon, which is not true of anything built by a team.

So it gets run the way a company would run a product, across nineteen disciplines, three of which I had never practised before this build. The full map is here, seat by seat, with the work in each one and the decision that stayed human.

That is the actual experiment. Not whether one person can write an app, which was never in doubt. Whether one person can hold every discipline a production product demands, and then hand the running of it to the product itself. What I am trying to find out is how far that goes, and whether the same thing works on something far more complicated.

If you start your own

Three moves from this build transfer to any project you mean to keep. Write down the rules you will not bend before the first feature: one source of truth, a test with every change, secrets in a vault. You will enforce them on the AI far more often than on yourself. Let the AI be the setup expert for every tool you have not used, and keep for yourself the decisions about what to watch, how tightly, and what the system must never do. And automate the watching before you add more features: a project that opens and closes its own incidents is one you can keep for years, and that is what decides whether the hobby survives your attention moving on.