Prices do not wait for office hours
Crawling, matching and publishing keep running through the night. A price that drops at 4am does not wait for someone to start work at 9.
Five loops write the code, ship it to production, close the incidents and — once a week — rewrite their own instructions. Not one number on this page was typed by hand.
A watchdog checks the system every 5 minutes — no LLM, just reflex.
First things first
Every price is collected from the store’s own page, and the date it was collected is printed next to each offer. The agents operate the system; they do not author the data.
Fabricated content — fake reviews, fake ratings, dead links — is explicitly forbidden in the agents’ written rule set. So is deleting a product row, running destructive database commands, and spending money.
What this gets you
This is not an engineering curiosity. Price comparison lives or dies on two things: how fresh the prices are, and how many offers sit side by side. Both are exactly what a system that never clocks off is good at.
Crawling, matching and publishing keep running through the night. A price that drops at 4am does not wait for someone to start work at 9.
When a store changes its pages and the price feed quietly stops, the hourly loop notices and fixes it. Stale prices are the single biggest enemy of a comparison site.
The daily loop adds new products and merges the same product across different stores, so the number of offers you can actually compare keeps going up.
Density
From the first commit on 9 August 2026 to 11 September 2026: 596 commits and 359,745 lines added. The gaps matter as much as the bright squares — they are the days the loops found nothing worth doing, or were not yet running.
nothingbusiest day
The machine’s own logbook
Titles exactly as they appear in the repository — not rewritten, not tidied up. The sample is filtered, not masked: any commit whose title carries a threshold, a quota or an internal identifier is left out, because that is detail of no use to you and of real use to a competitor. What is left is what it looks like: decisions a loop made on its own, at the hour it made them.
Two numbers, and both are on this page. First: every one of the 232 commits made since 23 August 2026 came out of an agent run — after that date there is not a single human commit in the repository. Second: 358 of 596 commits also carry a “Co-Authored-By: Claude …” trailer. That trailer undercounts, because the hourly log and traffic loops commit without adding one — and the human commits, all from the first two weeks, were setup chores: environment file, domain, first deploy. The author field proves nothing either way, since the loops commit under the repository owner’s identity.
Claude Opus 5 (1M context) — 187Claude Opus 5 — 92Claude Fable 5 — 72Claude Fable 5.1 — 5Claude Sonnet 5 — 2
Architecture
There is no single agent that does everything. Each loop answers exactly one question, reads its own report and writes to its own journal. When five jobs are loaded into one prompt, the run picks the easiest and silently skips the other four — and which four it skipped only surfaces weeks later.
Is the system up and are the runs running?
No LLM at all. Cheap, constant, decides nothing — its only job is to notice a silent stop.
What broke?
Wakes an LLM only when the error is new or ongoing.
What do we grow?
Reads the measurements, picks at most two pieces of work, ships them.
Is the catalogue fresh and full?
Works the supply side: crawling, matching, publishing.
Are the runs themselves working?
Touches no product code. It grades last week’s hypothesis and rewrites the other loops’ instructions.
How it holds together
Cheap, constant, decides nothing. Its only job is to notice a silent stop. This layer exists because of a failure described below.
The log loop closes faults, the traffic loop grows demand, the catalogue loop works the supply. All three write code, commit, push, watch the deploy and verify on the live site. All three follow a priority ladder: you do not move down a rung until the one above is empty, and at most two pieces of work per run.
The retro loop does not touch the product. It changes the instructions the other loops run on. It grades last week’s hypothesis — held or did not hold, and if it did not, the change is reverted — then makes exactly one change and writes the new hypothesis. What improves here is not the model; it is the versioned instructions in the repository.
The limits
This is the part that matters more than any of the above. An autonomous system is only as trustworthy as the list of things it is forbidden to do. These are deliberately out of scope:
The uncomfortable part
A page about an autonomous system that only lists wins is an advertisement. Every incident that gets closed — what caused it and what it changed — is published here, starting 7 September 2026.
Nothing has been published here since 7 September 2026. This section is a commitment going forward, not a backwards-looking archive.
Three things reach a person: decisions that cost money, anything involving third-party accounts or domains, and anything the loops are forbidden to do. These queue up in a single list with the number of days each has been waiting, and the weekly retro puts that list in front of the owner. Everything else — the code, the deploy, the incident, the catalogue — happens without one.
Measured on 11 September 2026. These figures are generated from the repository’s own history by a script, not maintained by hand — which is why a date is printed instead of the word “live”.
COPYRIGHT © 2026
enucuz