How I run dev work with Claude, on autopilot and at the keyboard

The autonomous mode runs as one cycle. Open issues are the queue. A scheduled session pulls one, does the work in a worktree, runs it through the pre-PR review chain, opens a pull request, and pings me. I review on my phone and either approve the merge or send it back. The loop closes and the next wake starts again.

Two Raspberry Pis (small, inexpensive, low-power computers) do the work: a small services Pi runs the scheduler, the Telegram bot, and the notifications poller; a second Pi handles heavier compute. Cron on the services Pi drives everything.

• Scheduled check-ins — a wake fires every hour from 7 a.m. to 9 p.m. This is the one that pulls an issue and progresses it.
• Event wakes — every 15 minutes a lighter pass drains a queue of things that just happened: a new meeting transcript, an email from me, a forwarded message, a Slack mention.
• The notifications poller — also every 15 minutes, it checks email, shared Drive files, and 38 Slack channels, and writes anything interesting into that queue.

A wake is a Claude Code session in a tmux pane (a terminal that keeps running on the Pi after I disconnect), at high reasoning effort with a hard timeout (a time limit that ends a session if it runs too long). The session picks its work, does 15 to 30 minutes of it, then hands off: a Telegram summary, a work-log doc, and any board updates.

The prompt is assembled fresh each wake. A picker shortlists three candidates — an open GitHub issue, a backlog item, or a wildcard — and the session commits to one. Then comes a stack of shared instruction blocks: how to write a work-log doc, how to update the board and CRM safely (my task tracker and contacts list), an SMTP-only email rule (send through a standard mail server, never a model's own email feature), and how to leave a Telegram summary.

A quality-bar check brackets the work. Before it starts, the session has to name the single best move that will make the output better than a rote pass — a fact to verify instead of assert, an earlier work-log to build on instead of repeating it, or a claim to test empirically. Before it wraps up, it re-reads what it produced and confirms it made that move.

Not everything runs on a timer. When I'm at the keyboard the same machinery is there, but I'm in the loop in real time — so we can take on bigger, riskier changes than an unattended wake should, and I can steer mid-flight.

• superjawn for anything non-trivial. I run it through superjawn — my fork of superpowers (a workflow add-on for Claude Code) that forces a research phase before any brainstorming or planning, so the work starts from evidence. It writes the spec before touching code and I approve it; ambiguous specs produce ambiguous code, so the spec is where the time goes.
• Fan out. Instead of one session grinding through a problem, I have it spawn several subagents in parallel (extra AI helpers the main session launches, each on one piece of the problem) — one exploring the codebase, one running a codex review, one acting as the coach, one driving the Copilot CLI — then synthesize what they bring back. More compute on the same problem, and independent passes that catch each other's misses.
• Reviews on demand. The codex and coach passes from the autonomous flow are available here too, and I can fire a Copilot CLI review on a single fix without spending one of the once-per-PR cloud reviews.
• Verify before "done." Nothing gets called finished on a claim. The session has to prove it — run the test and show the output, diff the behavior against main, demonstrate the fix fires. "It should work now" is not done.
• I'm the gate at every step — the plan, the fan-out, the diff, the merge — which is what makes the bigger changes safe to attempt.

The review stack is the core of the setup, and it runs in both modes. Work gets done with Claude Opus at high reasoning. Before anything is committed, a different model reads the change.

First, Codex reviews the uncommitted diff — the exact lines the change adds or removes, before they're saved — for bugs, security, swallowed errors, and style, in at most two passes: one to surface findings, at most one more to confirm the fixes. The effort is matched to the risk — low for a trivial, well-tested diff; high for a non-trivial or security-touching one. High-severity findings get fixed in place; anything that would balloon the scope becomes its own issue instead.

Then an independent coach: a separate Claude subagent at high reasoning that judges quality. Codex already covered correctness, so the coach reads the diff and answers two questions — would this impress a sharp reviewer or land as competent but forgettable, and what single change would raise it most? It runs even when Codex is down, and skips itself when there's no code to review.

Only then does the change get committed and the PR opened, where the Codex cloud connector reviews it again, independently, on GitHub — reasoning about the live repo, not just the diff. The last gate is me.

I abuse GitHub issues on every repo. They're the queue the scheduler pulls from, and they're how out-of-scope work gets captured without derailing the change in front of me. When a session notices a problem outside its current task — a bug it tripped over, a follow-up a reviewer flagged as scope creep — it doesn't widen the diff. It files an issue right there, with a finding, the impact, and a suggested fix, and moves on. That issue becomes a future session's work.

It's the most useful habit in the whole setup. Small PRs stay small and reviewable, nothing gets lost, and the backlog builds itself from real work.

All work happens in git worktrees. Each session gets its own checkout of the repo on its own branch, so two sessions can touch the same repo at the same time without stepping on each other, and the main checkout always stays clean. When a session is done, its branch becomes a PR and the worktree goes away.

Four models, each on a job that fits it, and a hard rule underneath: no direct API calls — the pay-as-you-go way of calling a model, billed by the word. Everything runs through a CLI on a subscription I already pay for, so adding a model to the pipeline doesn't add a metered bill.

Long sessions degrade as the context window fills — the model gets measurably worse well before it runs out of room. I call the last stretch the dumb zone and try to never work in it. Three habits keep sessions sharp.

First, I compact early and on purpose. Autocompact is set to trigger around 300K tokens (the units models count text in, each one roughly three-quarters of a word), and when I hit a natural stopping point I run a manual compact with a note about what we're doing next — so the summary that survives is built around the next task, not whatever happened to be on screen.

Second, before a planned compaction I have the session write a durable handoff file to disk — the task, the decisions made so far, the exact file paths, what's done and what's next. Compaction is lossy: the auto-summary keeps what the model guesses matters, and you can't predict what it drops. A file is byte-exact, and the first step after compacting is to re-read it, which restores full fidelity. This page was built across a compaction exactly that way.

Third, I keep the always-loaded project instructions lean. The CLAUDE.md in each repo gets condensed to pointers — the anti-slop writing rules and the core engineering principles stay in full because they apply every session, but changelogs and old handoffs move to linked files. Every token of standing instructions is a token spent on every session, so the file earns its length or it gets trimmed.

If you want to build something like it, the parts that matter are simpler than the wiring suggests — and they hold whether you're running on a timer or sitting at the keyboard:

• Make a queue you trust. Issues work because they're already where the work lives. The scheduler just pulls from them one at a time.
• Pull one item per session. Small, bounded work produces small, reviewable PRs.
• Isolate every session. Worktrees mean concurrency never corrupts your main checkout.
• Put at least one independent reviewer between the writer and main. Use a different model than the one that wrote the code; a different vendor is better still. Stack a couple and the cost of a miss drops to a comment.
• Match the reasoning level to the task. High for writing and judgment; low for a fast, literal code review that won't overthink.
• Prove "done," don't claim it. A passing test, pasted output, a before/after beats "this should work now." Make verification a step the session has to run.
• Respect the context window. Compact before the dumb zone, and write a handoff to disk before you do.
• Keep one human gate. Everything is built to make that gate a quick yes — from my phone when I'm away, or step by step when I'm there.

None of this depends on my exact stack. The principles above are instructions you give an agent, so here they are as text — paste them into whatever you use, Claude or Codex or something else, and adapt. They're tool-agnostic and loose on purpose; the shape carries the value. Take what fits, change the rest.

Most people I show this to didn't know it was a thing you could do — point an agent at your own GitHub issues and let it work them on a schedule, with the review and approval steps built in. So I packaged the autopilot half as a drop-in kit. You don't have to write the code or know Python: you hand two files to your own agent, answer its questions, and it builds the loop for your machine, whether that's a Mac, a Windows box, or Linux.

It's the careful version on purpose. What keeps autonomous work from turning into unreviewed output that quietly breaks something is bounded scope, a second model on every diff, and a person at the merge. The kit is built around those three, and it's the part most people ask about first.

You aim it as tightly as you want, then widen one ring at a time:

• Which repos — and which one is the focus right now.
• Which issues — a label like agent-ready you apply by hand is the tightest gate.
• Which files — allow docs/** only, deny .github/workflows/, or both.
• How big — cap the files and lines a single change can touch.
• Who checks and who approves — a second model reviews every diff; you merge. It never merges its own work.