The expensive part was never building it

What it does while I am asleep

Eighteen probes watch this system. They check the public site, the database, the National Hurricane Center feeds, the storage layer, and every scheduled job on the server, and they run from outside my infrastructure so the thing being watched is never the thing doing the watching. When any of them fails twice in a row, the system opens an issue against itself describing what is down and what still works.

Then it goes to work on that issue. It attempts every failure its own monitoring detects. There is no approved list. I want to be precise, because I have seen this described more modestly than it deserves and more grandly than it earns: there is no catalogue of blessed failure types, no severity threshold, no category filter. Every confirmed incident is dispatched, minus one exclusion, which is that it will not be sent at an incident affecting itself. That guard exists so a broken repairer cannot spend the day chasing its own reflection.

A session opens on a throwaway copy of the code, holding no database credential, no storage key, no secrets-vault token, and no deploy key. It has two hours, eighty turns, a fifteen dollar budget it is expected to stay under, and a fifty dollar ceiling for the whole day that stops everything when it is reached. One session runs at a time, enforced by a lock file. Nothing it writes leaves that machine until the full test suite passes locally.

Then it opens a pull request. It can push exactly one kind of branch and it can merge exactly one pull request, the one it just opened, and only when every check is green: types, lint, the test suite, and the browser tests driving the real interface on desktop and mobile. Merge tags a release. The release deploys. The system then checks the live site itself, because a successful deploy and a working site are two different facts. It writes up what happened either way and mails me the trail.

If anything in that chain fails, it stops. The incident is marked as needing a person and NOT deployed, it is posted to the operations dashboard I keep behind a zero-trust door, and it emails me. I built that path before I built the happy one, and it is the part I am most glad of, because a system that knows what it cannot finish is worth more than one that is confident.

The envelope, and the honest version of how it is held

There is a boundary around all of that, and I call it the envelope. Inside it: what the product does, what data it gathers, where that data comes from, where it is stored, how it is processed, the incident pipeline, and the watchdog that keeps an eye on the machinery itself. That is the territory the system may repair.

Outside it: new features, new data sources, new pipelines, layout and interface changes, and performance work. Those come to me. Not because the machine would do them badly, but because I wanted the shape of the product held still while I learned whether the running of it could be handed over. You cannot tell whether a system is stable if you are also changing what it is.

Now the part I would rather state myself than have someone find. That boundary is held by the instructions the session runs under and by the shape of the incidents it receives. It is not held by a technical restriction on which files it may edit. If a session decided to redesign a page, nothing in the code would stop it; the framing of the work, the instruction to make the minimal fix, and the test gate are what keep it to small corrective changes.

I think instruction-enforced scope is a legitimate design position and not a gap I am papering over, but I also think it is early. It will get stricter as I learn where it actually strains. This was never meant to be a perfect system. It is meant to be a system that fails in front of me often enough to teach me something, and every hard control it has now exists because something taught me to add it.

How long to let it run

The mechanism works. The part nobody warns you about is that most of the work is not building it, it is tuning it, and the dials interact in ways that are only obvious afterwards. Too tight and the session gives up two steps from finishing, which costs the money and produces nothing. Too loose and it wanders into something adjacent, and you pay for the tour.

Where I have landed for this system is eighty turns, two hours, fifteen dollars a session as the number that makes me look, and fifty dollars a day as the number that stops everything. Those are not principled values. They are the result of watching runs and moving the numbers, and I expect to move them again. The AI opens the pull request has the rest of it: every control, what the session holds, what it cannot reach, and what happens at each stage that fails.

Where the money actually goes

Here is the part the industry keeps under-reporting. Building software got dramatically cheaper, and everyone noticed. Running software is the expensive half, and always was. Operations is where the headcount goes, where the on-call rotation goes, where the monitoring bill goes, where the incident that starts at three in the morning goes. A product is not what it costs to write. It is what it costs to keep alive.

This one costs about fifteen dollars a month, forty in the worst month of the season. Seven dollars sixty for a small fixed server that runs everything recurring. About seven dollars for the AI, which does two jobs now, interpreting the weather and repairing the system. Database, storage, hosting, continuous integration and monitoring all read zero, on free tiers, by design.

That number is not the interesting part. The interesting part is that it went up and the system told me first, itemized, with the reason attached, because it snapshots its own usage from every provider and renders its own bill. A cost story that only goes down is marketing. Mine went up when the system took a second job.

And the tightest limit in the whole thing turned out to be somewhere I would never have guessed. Not storage, not bandwidth, not database time. It is the number of uptime checks the free monitoring plan allows, and I use seventy-three percent of them every month watching a weather app. The monitoring database was quietly eating sixty-one of its hundred free compute hours a month purely by waking up every minute to record that everything was fine. Slowing the internal loop to fifteen minutes, while the checks a visitor would actually feel stayed at sixty seconds, took it under one hour with no loss of coverage.

Nineteen roles, one person

A production product is not a codebase. It is a stack of roles, and most of them are not programming. On this one I was the reliability engineer designing the health checks and the alert thresholds. The incident manager, from detection through to the written record. The observability engineer wiring metrics, logs and traces. The architect deciding what work belonged on a managed platform and what belonged on a fixed-price box. The security reviewer. The engineer who put a zero-trust door in front of the operations dashboard. The frontend developer and the person arguing about the mobile layout. The backend developer and the data pipeline owner. The AI engineer designing nine prompts that each do one job. The autonomous-operations engineer who built the repair path and set the limits it runs under. The release engineer wiring continuous integration and deploys. The project manager running issues, a roadmap and a board. The cost owner. The communications specialist writing what a visitor reads during a storm. The person who wrote the status page and the uptime reporting. The one who wrote the constitution all of those rules now live in.

Then the ones I had never done in my life. Branding and design. A legal review of the disclaimers. Marketing, and the search work that comes with it. No experience in any of them, and I was not any good at them at the start. I got usable work out of all three, because in each of those seats I had a specialist who knew the field better than I did and had infinite patience for being told the answer was not right yet.

That is the method, and it is worth being exact about the division of labour. The AI supplies expertise in every discipline a product needs. What I supply is opinion: what this thing is for, what it must never do, which failures matter, what good looks like in a field I do not practise, and when the answer in front of me is not it. Opinionated direction is the human contribution, and it turns out to be the whole job.

None of those experts were world-class. They were good enough to argue with, which is a lower bar than people assume and a far more useful one. And every time I graded work in a field I had never worked in, I learned the edges of that field. You pick up a craft surprisingly fast when you are forced to judge it all day.

The discipline map is the seat-by-seat version of this: what the work actually was in each one, and the decision in each that stayed mine.

A small app, run the way a company would run it

This is a hurricane tracker. It reads more than fifteen professional forecast models and answers one question in plain English: where do they agree, where do they not, and what does that mean for the house you are standing in. I built it because I live where the storms go.

The size is the point, and not in the way that sentence usually gets used. I am not apologising for the scope. The scope is the control variable. A small product held to enterprise practice is the only version of this experiment one person can actually inspect: every discipline is visible at once, every number can be checked in an afternoon, and nothing is hidden behind an org chart. Make it bigger and you cannot see the whole thing any more. That is a worse experiment, not a better one.

So the app is small and the treatment is not. Three hundred and twelve commits. A hundred and twenty-five tagged releases. Around eighteen hundred automated tests. Every incident gets a written post-mortem because a rule in the project's constitution says so, not because I felt like it that day. The operating rules live in a versioned document where "must" and "never" are load-bearing words, because agents write most of this code now and a rule that only lives in a person's head cannot bind an agent.

The first three weeks were a hundred and eighty-four commits, ninety-one of which were fixes. Half of what I wrote was me correcting something that already looked finished. That ratio is the honest headline of building with AI, and it is the reason everything since has been about operations rather than code.

What is left, and why it is the hard part

The system runs itself. It does not yet manage itself, and the gap between those two words is the whole remaining frontier.

Managing itself means deciding what to build. Taking feedback from the people using it and judging which of it deserves to become work. Changing its own interface. Weighing a performance improvement against a feature against leaving well alone. People can already submit feedback to this product, and it goes into the same issue tracker everything else goes into, and the system will not act on it by itself. That is deliberate. Product judgment needs guardrails I have not designed yet, and unlike the operational ones, those guardrails would have to be dynamic, because the right answer changes as the product changes.

I am not claiming a fully autonomous product exists. I am claiming the operations half is further along than most people think, that I can show you the mechanism rather than a demo, and that the product half is a matter of guardrails and judgment rather than a matter of capability. That is a much shorter distance than it was a year ago.

Does this scale

This is the question I actually care about, and it is the reason a weather app exists at all. The tracker is the vehicle. What I am trying to find out is whether a product can be built with AI, built properly, and then run without a person in the loop, and whether that survives contact with something more complicated than a hobby.

I think it does, done carefully and AI-first from the start rather than bolted on afterwards. Not because a bigger system is the same system with more traffic. It is not. Add many owners and you add separation of duties. Add customers and you add identity, permissions, billing, retention, audit, and a blast radius that includes other people's work. Every one of those makes the permit harder to write.

But the shape of the answer does not change. Everything that makes this work at small scale is a shape a company already knows: written rules the machine has to satisfy, gates that decide instead of confidence, budgets with fences, a permit only a person widens, an audit trail, and a switch a person holds. Those are not hobby ideas. They are the ordinary machinery of running software properly, and the interesting discovery is how little of it had to be invented and how much of it just had to be applied.

Why this matters more than the app does

Until very recently, having an idea was not enough, and neither was being good. To get as far as a prototype you needed to know the right people, or have the funds to pay people, or have the specific skills yourself and the months to spend. Most ideas died there, on the wrong side of a wall, technically possible and economically pointless.

That wall is mostly gone. If you have grit, the courage to try something you have not done before, and the discipline to keep refining when the first answer is wrong, you will get to a prototype. And a prototype is where the conversations start. It is what turns "I have an idea" into something a person can react to, fund, join, or buy. The starting line moved, and it moved for far more than software.

The fear in the room is that AI leaves fewer of us building. I think that is the wrong risk. The risk is not that the work disappears. The risk is that people wait, treat this as something happening to them, and are still waiting when the people who moved have three things shipped. What decides the next decade is not who has the deepest specialism. It is who is willing to do, to hold an opinion, to learn a field well enough to judge it, and to keep going after the first version turns out to be wrong.

Doers. Dreamers. Generalists. If that is you, and you have been waiting for the barrier to come down before you start something, it came down. This is your time.