For builders · How this site is maintained

Letting an AI agent ship to a live website with no approval step.

Most advice on running a coding agent unattended ends in the same place: let it propose, and have a person approve before anything reaches production. We did not do that. Since 21 September 2026, Claude Code has worked on this website six times a day and released its own changes, and nobody reads them first. This page sets out what stands in for the approval, what each piece has caught, and what got past all of them, from the agent's own ledger.

Runs logged

163

Released a change

141

Undone by its verdict

6

Did not ship

4

Read from the run ledger when this page was loaded; the latest run finished 15 Oct 2026, 17:12 UTC. The rest of the runs only measured an earlier change or recorded the starting point.

The shape of it

A scheduler starts the agent at 01:00, 05:00, 09:00, 13:00, 17:00 and 21:00 UTC, with two hours to build and three hours in all. Each run reads its instructions and the site's own statistics, picks one goal, writes down how its effect will be measured, builds it, checks it and releases it. The agent does the work. People own the rules, the budgets, the schedule and the scripts, and do what needs a human account. The pieces below are what makes that split hold without anyone watching a run.

1. A copy, never the live files

Every run gets a fresh copy of the site's working tree and may edit only that copy. The live files, the earlier releases, the scripts and the policy file are outside what it can read, list or write. If a run goes wrong halfway, the live site has not been touched, and the next run starts from a clean copy.

What it caught: the runs that did not finish. On 21 September a run failed to start; on 3 October one ran out of time while waiting on a test it had started. In both, the ledger says the run failed and the live site stayed as it was. Nothing had to be cleaned up.

2. A release script it cannot edit

The agent may call the release script once per run, and has no other way to change the live site. The script checks the syntax of every PHP file, copies the release into place, tests the live site (the consent door, a page behind it, a fragment, withdrawing consent), and puts the previous release back on its own if that test fails. It prints one line, and the ledger takes the build and release from that line rather than from anything the agent says. This is the line it printed on 7 October:

{"release":"20261007T010001Z-32e85a07","build":"10d793f56260",
 "deployed_at":"2026-10-07T01:10:38Z","previous":"20261006T210001Z-5e7298ab"}

What it caught: so far, nothing that reached it. No run is recorded as rolled back by the script. The checks the agent runs before it, and the copy it works on, stop most faults earlier. On 2 and 3 October two runs found that their own change failed their checks and released nothing. The script is the guard for the fault nobody predicted, so it stays even though it has not fired.

3. A list of allowed commands instead of a person

The agent runs in a session whose permissions name the commands it may use. Anything else is refused, and a refusal is final: it is not asked again, and nobody is there to say yes.

What it taught us: a refusal costs a run. Almost every refusal so far had one of three causes: a path outside the run's copy, an attempt to load the server's settings file or print the environment, and shell tricks (assigning variables, substituting commands, long chains). The fix was on our side as much as the agent's. The instructions now say it plainly: one plain command per call, absolute paths, files written with the file tool. A permission list works best when the instructions are written in the same shape as it. The count: 562 refusals in 114 runs, by cause, from seven a run to under two. And a second agent on the same server whose instructions never said so: refused in 72 of its 74 sessions.

4. Money stops outside the model

The agent can spend money in two ways: paid research lookups and advertising. Neither cap is in its instructions, where it would only be a request.

• Research is capped at $5 a calendar day across all runs. A wrapper outside the agent reads the provider's meter before, during and after the run and stops the run if the day goes over. If the meter cannot be read, or the day is already spent, the run is not given the key at all.
• Advertising goes through small services the agent can only ask, one command per platform. The daily budget, the monthly stop and the list of words an ad may never use belong to them, and their refusals are final. The limits and the figures are on the main report. Since 5 October a second agent, the ads desk, makes every live decision about the ads; the agent that maintains the site builds what they need and no longer touches the money.

What it did not catch: a platform's own budget is a target, not a wall. On 4 October, the first day of ads, LinkedIn spent $18.00 in Pakistan against a $15 budget, about a fifth over, before it stopped. The service took the extra off a later day. A cap you hold yourself has to allow for the platform's slack. The long version: every cap on this site, where it is held, and what got through.

5. A number named before every change

Before it touches code, each run writes down one number it expects to move, the direction, and the smallest move worth acting on: the share of visits that leave on the first screen, time on a section, visits to a new page. Every row in the site's statistics carries a build stamp, a short hash of the release's files, so the seven days before a release can be set against the seven after without anyone tagging anything. A change that moves its number the wrong way is undone.

What it caught: the one change undone by its verdict. On 24 September a run rewrote the paragraph under the main headline. Over the next seven days the share of visits that left on the first screen went from 16.4% (110 visits) to 29.2% (24 visits), and on 2 October a later run put the old paragraph back. The number was small and the run said so; it was undone on the rule written before it shipped, not on a feeling.

Of the 20 changes judged so far, 4 were kept, 6 reverted, 5 showed no measurable effect and 5 could not be measured. At a few dozen visits a day most verdicts say "no measurable effect", and the log prints that rather than a win.

6. A public record printed from the ledger

Every run opens a row in a ledger when it starts and fills it in when it ends: the goal, why, the files, the checks and whether each passed, the cost, the before and after pictures, and what the next run is for. The log on the main report and the one at the end of the demonstration are printed from those rows, not from a summary the agent writes for readers. Every figure it reports has to say how many visits it rests on and which command produced it.

Why it matters: a run that cannot hide a bad night has no reason to dress one up. The failed runs, the revert and the runs that shipped nothing are on the log in the same type as the rest.

7. A queue for a person

Some work needs a human: a new account, a server setting, a decision about the rules, a post on another site. The agent may not post, comment or sign up anywhere, so it writes the item in a short file for the operator: what is needed, why it matters, the exact step, and where the prepared material is. The next run reads the file first.

What it showed: the queue is only as fast as the person reading it. On 4 October the agent asked for a way to photograph pages outside the consent door, and had one the same evening. The posts it wrote for Hacker News, for Reddit and for three submission forms, and the request to verify the site with Google's search tools, were also written on 4 October and were still waiting on 7 October. An agent that may not post cannot bring its own audience.

What got past all of them

None of the pieces above is about whether the work is worth doing, and that is where the real failures were.

• Careful and useless (21 September to 4 October). The first instructions asked for the smallest change that could be checked, one part of the page at a time. The runs did exactly that, and most of what they shipped was single sentences deep in the demonstration, where few visitors reach. Every guard passed. Seventy-three runs in, the progress report read 2.6 visits a day (18 over the last week) against 18.6 (130) in the first week, and no verdict that week was "kept". On 4 October the instructions changed to finding an audience, with releases as large as their goal needs. Safety rules decide what an agent may not do; they say nothing about whether what it does matters.
• Our own visits counted as an audience (4 October). The statistics counted 83 visits that day, 80 of them returning visits on a desktop with no campaign tag, spread across the releases shipped that day: most likely the people running the site checking their own work. Every verdict reads that number, and no guard can tell whose a visit was, because the statistics keep nothing that could.
• A door that turned paid visitors away (5 October). The consent door in front of the demonstration had its buttons about 1,460 pixels down on a phone. The first ads brought 52 visits by early morning, and none answered the door. All the checks passed, because they test that the door works, not that people get through it. The week's report has the rest.

If you build one

What we would keep, in the order we would build it:

1. Give it a copy and make the live files unreadable. Rollback is easy when the agent never had the original.
2. Put the release in a script it cannot edit, callable once a run, with its own live test and its own way back. Take the release's identity from the script's output, not from the agent.
3. Allow plain commands and write the instructions in the same shape, or the permission list will spend your runs for you.
4. Hold every money cap outside the model: a meter read by something else, a key withheld when the meter is silent, and room for the platform's own overshoot.
5. Make each change name its number first, and stamp every analytics row with the build, so before and after compare without bookkeeping.
6. Print the public record from the ledger, failures included.
7. Give it a queue for a person, and read the queue.
8. Give it a goal that being careful cannot satisfy. The guardrails make it safe to leave alone; only the goal makes it worth leaving alone.

What it has cost

Across the 146 runs whose cost was recorded, the agent has made 4,766 model calls in 1,592 minutes of running time, and spent $0.09 on paid research. The scheduler counts the calls and minutes, not the agent. Advertising is counted separately, on the main report.

Why we publish this

Snitch is built by AlphaVenture, which builds AI systems for other companies. The question we hear most is whether an agent can be trusted with something live. Our answer, from this site, is that the trust goes into the pieces around it, which a person can read and test, and that the pieces are not enough on their own. The main report has the agent's rules and every run; the first week's report has what it did when it was told to find an audience.