How it's built AI does the work, people decide

Built at the speed of AI. Steered by people.

Feedback becomes an issue. AI ranks it against written priorities, builds a fix and tests it. People step in at a few deliberate points, the ones that need judgement, and nowhere else. That's how a fix can arrive the same day.

First line written Oct 13, 2026 179 changes 65 pull requests merged 146 tests guarding your library Mac and Windows, one codebase

As of October 21, 2026, eight days in.

The whole thing

One loop. People where it counts.

Everything that's filing, sorting, building or checking runs by itself. People do the parts that need judgement: saying what's wrong, setting what matters, and deciding what ships.

A person decidesAI does the workHappens by itself
How Hey Archi gets better A loop: you say what's wrong, it becomes an issue, AI ranks it against the priorities, it goes on the roadmap, an AI worker builds and tests it, a second AI reviews it, a person merges it, and everyone updates when they choose. In the middle, a 7 am report goes to your phone, and replying “take the next one” starts a worker. every hourovernight,or when asked you choosewhen YOUSay what's wrong AUTOMATICIt becomes an issue AI, WITH ITS REASONSRanks it AUTOMATICOn the roadmap AI, ON A REAL MACBuilds and tests it AIA second AI reviews A PERSONReads it and merges EVERYONEUpdates when ready WRITTEN BY A PERSONThe priorities page ranks and picks by it 7 AM, ON YOUR PHONEThe morning report what changed,what's next YOU REPLY, IN A SENTENCE“Take the next one”
A real example

From “this is broken” to fixed, before lunch.

On October 21, 2026, Claude couldn't reach Archi, and nothing in The Archive said so. It was fixed three and a half hours later, and for most of that time Nate wasn't working: he was out taking his daughter on her first drive with her learner's permit. Every step is on record.

  1. Feedback, in plain words. Archi offered to send it, showed the draft and sent it after a yes: “The app doesn't warn me when Claude isn't connected.”
  2. Ranked by AI, with its reasons. Triage read the issue against the written priorities and put it at the top.
    TRIAGEP0 · Who: Nate + Mac · Size: M → Ready

    “A current user says Claude couldn't reach Archi and it stopped their work, which is P0 under … ‘blocks work’.”

  3. Nobody needed. The issue sat ranked and ready on the board, with its reasons, while Nate was out of the house.
  4. Built with Claude, on a real Mac. Archi notes when it starts, which Claude app connected and why it couldn't start. The Archive shows a light in the top bar: connected, not in use, or what to fix.
  5. Tested, reviewed, merged. The tests ran on Mac and Windows. A person read the change and merged it. Anyone can update from Settings > Updates.
  6. And then it got better. Using it raised a new question (“which Claude apps are connected?”), and the next change, naming each connected app, was up for review within the hour.
The idea

People in the loop, only where it counts.

Most of the work between “this is broken” and “it's fixed” is filing, sorting, building and checking, and AI does all of that. What's left for people is judgement: what matters, what's safe, what ships. Each of those takes a click or a sentence.

Runs by itself
  • Feedback filed as an issue, with where it came from
  • Ranked: goal, priority, who, size, and why
  • Placed on the roadmap
  • The top issue picked up overnight
  • Built, tested on Mac and Windows
  • Reviewed by a second AI
  • Pull request written up for review
  • The next jobs made ready, for a person to approve
  • A morning report of all of it
A person decides
  • Send it? You see the feedback before it goes.one yes
  • What matters? The owner writes the priorities, once, in plain English.one page
  • Run outside ideas? A person reads feedback from strangers before AI runs code for it.one label
  • Stuck or unsure? AI stops and asks instead of guessing.one answer
  • Want more? Reply “take the next one” to the morning report.one sentence
  • Ship it? Every change is merged by a person.one click
  • Update now? You choose when your copy changes.one click
The night shift

It keeps working after everyone goes home.

The computer that would sit idle all night becomes a build team. Every hour, an AI worker takes the most important job that's ready, builds it, tests it and has it reviewed. By morning, finished work is waiting for a person to look at.

  1. Every hour, one job. The top-ranked ready issue is built and tested on a real Mac, checked by a second AI and written up as a pull request. Work stops at six waiting, about one morning's review, so it never piles up faster than a person can read it.
  2. It gets the next jobs ready. Out of ready work, it takes an unclear or oversized issue and proposes how to finish it: a “done when” checklist, a split into small pieces, and its questions. A person approves with one label.
  3. A morning report on your phone. What needs you, what happened overnight, what's next. On Mondays it adds the week's plan, ranked against the written priorities, with a reason for each item.
  4. Review, merge, move on. The judgement calls are the only part left for people. Anything that needs a decision is waiting for one, with the question already written.
  5. Need more? Say so. Reply to the report with “take the next one”, from a phone, and the same crew starts during the day.
Morning summary7:00 am

Two AI pull requests are ready for review and both pass their checks. One decision is waiting on you before the partner demo can move.

Needs you
  • Review Script step: a “promo” brief template AI PR · checks passing
  • Review Session log of Archi's tool calls AI PR · checks passing
  • Your call Who the partner is, and the promo plan's open questions
Overnight
  • 8 runs · 2 pull requests opened · 1 issue made ready
  • 1 new piece of feedback, already ranked
Next for the crew
  • Review flags unlabelled AI voices and avatars P1 · S
Example, built from real issues. The night shift started October 21, 2026.
Another real example

One sentence from a phone. A pull request, three minutes later.

The evening of October 21, 2026, the first time it was tried. Nate replied to his morning report from his phone, and the crew did the rest.

  1. “Take the next one.” A one-line reply to the morning report, typed on a phone.
  2. Understood and started. AI read the reply and started a worker. The answer came back to the phone: “Done: started a worker on the top Ready issue.”
  3. The right job. The worker took the highest-priority job that was ready: a template for writing promo-video scripts, on the path to the partner demo.
  4. Built, tested, reviewed. Claude wrote it, the tests ran on a real Mac, and a second AI reviewed it against the request and the project's rules.
  5. Waiting for a person. A pull request with a summary and the review, ready to read and merge.

That job changed a document, so it was quick. Code changes take longer, because the whole app is built and tested first, but the reply is still one sentence.

The loop

Six steps, every time.

The same loop runs for a one-line wording fix and a new feature. Open “Under the hood” for the technical how.

  1. Listen: anyone can say what's wrong, in their own words.

    What happens

    Ask Archi in Claude, click Feedback in The Archive, or use the website. Archi shows you exactly what it will send and sends only after a yes. It sends words only: never footage, faces or anything from your library.

    Where it goes
    • A GitHub issue on the roadmap
    • Labelled with where it came from and how much it hurts
    • Kept and retried if you're offline
    Under the hood

    feedback.rs shortens file paths (feedback::redact) and files a GitHub issue labelled feedback, through a small relay that holds the only token, so neither the app nor the website carries one. What can't be sent waits in an outbox and goes with the next one.

  2. Rank: AI reads it against priorities a person wrote.

    What happens

    Within a minute, Claude decides what goal it serves, how urgent it is, who can do it and how big it is, and writes one sentence on why. It lands on the roadmap board. A person can overrule any of it.

    What it decides
    • Goal and priority (P0 to P3)
    • Who: AI alone, AI with Nate's Mac, or Nate
    • Size, and whether it's Ready
    Under the hood

    A GitHub Action (triage.yml) runs Claude on each new feedback issue with docs/priorities.md as its rulebook. Anyone can send feedback, so the text is treated as untrusted: that Claude can only read, and write a decision file. A separate script (triage_apply.py) checks every value against allowed lists and is the only step holding a token that can change the board.

  3. Build: two ways, both on a real Mac.

    What happens

    With Nate: work that needs the running app, real footage or a judgement call is built together with Claude Code, live.
    Overnight: work AI can do alone is picked up by AI workers every hour overnight, one issue at a time.

    Why a Mac
    • It's the real app, built and tested where people use it
    • No cloud build machines to pay for
    • Runs while no one's using the computer
    Under the hood

    Workers are a GitHub Actions workflow (worker.yml) on a self-hosted runner on Nate's Mac. worker.py picks the top issue by fixed rules (Ready, size S or M, allowed to start alone) and claims it. Claude Code works on its own branch with file tools and cargo only: it holds no token that can push. The job runs in its own home folder, so it never sees Nate's library, settings or Claude connectors.

  4. Check: tested twice, reviewed by a second AI.

    What happens

    The workflow runs the tests itself rather than taking Claude's word for it. Then a second Claude reviews the change against the issue and the project's rules, and its verdict goes in the pull request.

    What has to pass
    • 145 tests, including ones that protect existing libraries
    • The build on Mac and on Windows
    • A review, written for the person merging
    Under the hood

    cargo test --release runs on the runner, then CI on GitHub's macOS and Windows machines for every pull request. Tests like index_compatibility_is_pinned and existing_catalogs_open_without_losing_anything stop any change that would quietly make people re-index or lose ratings and tags. A pull request touching protected files is labelled needs-owner.

  5. Decide: a person reads every change and merges it.

    What happens

    AI never merges its own work. Nate reviews each pull request with the summary, the test results and the second review. If the AI couldn't finish or wasn't sure, it stops and says why instead of guessing.

    Kept in check
    • At most 6 AI pull requests waiting at once
    • Outside feedback runs only after a person says “go”
    • Stuck work comes back with a question
    Under the hood

    If Claude stops (unclear, needs the owner, too big), it writes the reason to stop.md, and the issue gets that as a comment, the ai-stuck label and moves to Blocked. Feedback issues need the go label, which only Nate adds, before a worker runs code for them.

  6. Ship: you update when you choose.

    What happens

    Settings > Updates in The Archive, or “Hey Archi, check for an update.” Checking changes nothing. Updating needs your yes, backs up your catalog first and stops if anything could lose your work.

    Never
    • Updates by itself
    • Throws away local changes
    • Re-indexes without saying so first
    Under the hood

    update.rs only fast-forwards a clean main. Local changes, another branch, indexing in progress or a “Re-index required” note in the changelog stop it and say why. It runs from a copy outside the app, because the update restarts The Archive and Archi.

What comes first

Fast is easy. Fast at the right thing is the point.

AI can build almost anything quickly, so the hard part is choosing. Hey Archi's priorities are one short page in plain English, written by a person. Every ranking quotes it, and changing the page changes what gets built next.

The goals, in order
  1. A public demo for partners
  2. Keep current users working
  3. Safe to hand out: the installer and licences
  4. Network storage for teams, and personal libraries
  5. Ideas that don't serve the above wait here
How to rank

P0, now: anything that exposes a real person or a child, risks someone's index, ratings or tags, or stops a current user's work.

P1, this month: on the path to the partner demo, or unblocks the AI.

Ties: unblocks other work · a current user asked · smaller first · AI can do it alone.

Never, whatever the ranking

Footage, faces or library data leaving the computer. Changes that would make people re-index, without the owner's OK. Spending money without a yes. AI merging its own work.

Fast, not reckless

Your library is protected by tests. Ratings, rejects, tags and collections are hand-made and can't be regenerated, so tests stop any change that would lose them or force a re-index.

The rules are written down. One file (AGENTS.md) tells every AI and person what they may and may not change, and why.

Each AI gets only what its job needs. The one reading outside feedback can't change anything. The one writing code can't push it.

Honest when unsure. When an AI worker found the site said Archi “never” names children, it pointed out that this is an instruction, not something the code enforces, and changed it to “is told never to”.

Everything is on record. Every issue, ranking, change and review is kept on GitHub, with who or what did it.

A person merges everything. AI proposes; people decide.

Still being built

What isn't there yet.

Feedback from everyone

The relay that files feedback for people without the GitHub repo isn't live yet, so their feedback waits on their computer until it is.

A track record

Hourly overnight work started on October 21, 2026. We'll share how much each night actually ships once there are weeks of it, not days.

More than one Mac

Overnight work runs on one Mac, so it waits while that Mac sleeps. A Windows PC is next.

Say what you need

Tell Archi.
Watch it get better.

Something broken, confusing or missing? It goes straight into the loop. Partners: we'd love to talk about how this way of building could work for you.

Send feedback → Talk to Nate