What my job looks like now

What this used to take

The old way to build something like this, you'd need backend and frontend developers and a reliability engineer, plus someone on call for 3 a.m. incidents. Then a legal review for the disclaimers, and somebody watching the cloud bill. That's months of work and tens of thousands of dollars before the first user, and for a side project about hurricanes the math never worked.

I built it and I run it by myself. My cost model puts it at about $15 in a typical month and about $40 in a stormy peak, and that's providers only, not my time. I held every one of those roles, with an AI specialist in each seat.

Most of the money and people used to go into running it, meaning the on-call rotation and the monitoring bill, every month for years. As far as I can tell that's where the cost is dropping now.

Fixing what already looked finished

The AI writes most of the code now, so the first working version of almost anything is close to free.

Of the first 184 commits (2026-05-30 to 2026-06-21), 91 were fixes to things that already looked done. Karpathy made the same point at YC AI Startup School in June 2025 ("Demo is works.any(), product is works.all()").

I keep a short list of rules the model won't reliably follow on its own. Bug fixes start from a failing test. Each fact lives in one place, so two parts of the code can't drift apart. Most of my job now is holding those. In DORA's September 2025 report, more AI adoption went with faster delivery and less stable delivery, and automated testing and fast feedback were what kept stability up.

Picking the agents

In a single day I might brief a software engineer agent, a legal reviewer, an incident responder and a cost analyst.

Picking which agents to call ended up being where most of my judgment went, and I found that out writing these posts.

For days the wording just wouldn't land, and better prompts to the same agent didn't fix it. The facts checked out and the sentences were still flat. So I added a conversion copywriter, an agent briefed to make a reader care, and after that the words worked.

On the same paragraphs the copywriter agent caught things the engineering agents didn't. What made them different was the brief I wrote each one.

The model doesn't pick the roster for me yet. I knew who to call from years of watching which kind of expert solves which kind of problem, and nothing told me the room needed a copywriter. On this site there's also a standing council of ten reviewer agents, with a contrarian and a chair, because one agreeable reviewer can miss a false assumption.

Reliability targets

None of the specialists decided how reliable each part had to be. I did. Google's SRE book argues 100% is the wrong reliability target for basically everything, since each extra nine costs more than the last and past some point users can't tell.

I set reliability high where a person would feel a failure, and lower where a slower signal is enough. Four of the nineteen checks run from outside my infrastructure, the fastest every 60 seconds and the others every 3 minutes. The internal loop runs every 15 minutes for slow signals whose alarm thresholds are in hours. Grafana's free plan allows 100,000 synthetic checks a month, and the monitoring is designed to use about 86% of them.

Learning the tools

This project runs on Vercel, Neon, Cloudflare, Anthropic, Hetzner, Grafana and GitHub Actions, plus a secrets vault and a zero-trust check in front of the ops dashboard. I'm not an expert in most of them, and I can't point to anything in the product that suffered for it.

Each one used to mean days or weeks in the documentation before anyone could put it in a stack. Usually one person paid that time, and when they left the knowledge went with them. Teams keep a vendor for that reason a lot. Somebody spent a year getting good at it, and swapping means someone else learns the new one from scratch, so the stack stays put even when the diagram shows it as modular.

Here the AI did that reading. It went through the vendor docs, wrote the configs and told me things about each tool I hadn't thought to ask. If that keeps working, the only thing tying me to any of these is what the tool does.

I haven't actually swapped a vendor yet, so I'm treating that as a hypothesis for now.

Cheap prototypes

It used to be that you found out whether an idea was any good by building it, and building meant hiring people and funding a quarter. Most ideas never got that far because they cost more to try than they seemed worth.

When an operated product costs a few weeks and about $15 a month, a lot more gets built. Companies already skip purchases on that basis (32% of organizations passed on at least one software product or feature they could build in-house with agentic coding tools, McKinsey 2026).

Finding the people who need it is still hard, and cheap building hasn't changed that for this tracker.

What changed in my job

I used to be in the fix loop: read the report, write the change, push it. For repairs I'm a level above that now. I write the rules the machine has to meet, set its budgets, read the trail it sends me, and hold the switches that turn it off. The AI session has no GitHub credential; an orchestrator around it pushes the fix branch and merges only the pull request that session produced, and only once every check is green.

I own what the resolver ships, bad fixes included. Most of the work is writing expectations down and checking gates, which I've done for years leading engineers, and it carried over better than I expected.

Longview, my private home system, has stricter rules: I wrote its constitution first, irreversible decisions go through adversarial review, and its repair agent is blocked by design from merging or deploying. Details are in Laws before code.

What about juniors

If AI does the junior work, the next experienced builders have to come from somewhere, and one person's project doesn't settle that. What I can say is how I learned on this one. I learned reliability by watching a green check hide stale data, and then writing the check that measures freshness.

The specialists weren't world-class in any of these fields, but I could argue with them. Every time I sent work back I picked up another edge of a craft I don't practice, at about the pace I got better at telling good work from bad.

People ask me if AI is going to take the work. I didn't want to stand still while that settles, which is part of why I built this one and ran it on real storms.

What I still decide

Anything new on the tracker is still my call.

That covers deciding what the tracker offers: taking user feedback and judging which of it turns into work, changing its own interface, and weighing a feature against a performance fix or against leaving it alone. I've kept all of those. The resolver's instructions and the shape of the incidents it gets keep it off them, and no technical restriction on which files it may edit backs that up.

Fully autonomous would mean handing it product judgment, features and user feedback as well. Those need guardrails I haven't designed yet, and I think they'd have to move as the product moves, which the operating limits don't.

Building a prototype

One person with a set of AI specialists can get to a prototype now, if they're patient enough to keep sending work back after the first answer is wrong. Then somebody else can react to it, or fund it.

This is a small system run by one person under the practices a company would use. I had to know what the tracker should do, and know enough of each field to say when the work was wrong.

I lead platform engineering, and for three weeks I also did design, a legal review and copy. I know a fair bit more about each of them now.

I built the tracker for my own house, ran it on real storms, and wrote its operating rules down after the first version shipped.