jarvis is a watch loop that stays at your side while you write code yourself, watching the changes and automatically waking the pair navigator Jarvis only at the moments that matter. The human writes the code; the AI stays an observer.
An approach to AI pair development that preserves authorship. jarvis isn't just an automation tool — it starts from a single stance: the author of the code must remain the human, all the way through.
Jarvis amplifies Tony Stark's abilities. But the one who suits up, fights, and makes the calls is always Tony — he takes information and assistance from Jarvis, but he never hands over the controls. Jarvis lifts him up from the side; the decisions and the actions are Tony's.
Today's coding agents tend to go the opposite way. Not because automation is too capable, but because they build a "it's my code, yet I'm not in the cockpit" structure — one that pushes the human out of the decision loop.
That's why the name is Jarvis — an AI that keeps the human in the cockpit.
Install, restart, launch. The first run asks you for a strength once — then jarvis watches your changes while you write the code, and wakes a pair-navigator only when it matters. It never edits your code.
The installer asks you to pick a language — English / Korean.
Hooks and the status line load at session start.
That's it. Jarvis wakes only when new change has accrued, a risk path was touched, or a commit boundary was crossed.
interrupt the loop (Esc)
/loop /jarvis · restores saved settings
/jarvis-reset
/loop /jarvis with no interval.
/loop 5m /jarvis runs on a fixed schedule and ignores
jarvis's own active /
idle /
strength pacing.
Reviewing as an observer creates false metacognition. Understanding accumulates inside the tool rather than in the person, and errors become already-committed code that someone has to unwind.
The implementation lives on as long-term memory in the human's hands. The machine stays an observer, pointing the way — but the human holds the keyboard all the way through.
As AI full-automation development spreads fast, the author of code generation is shifting from human to AI. The conventional "Human in the loop" is a structure where the AI produces code and the human reviews and approves it.
This structure works against the developer's grasp of the logic. As automation cycles pile up, the developer knows the overall context but loses awareness of the detailed logic.
More dangerous still, reviewing as an "observer" rather than an "author" creates the illusion of "knowing" — false metacognition — and this blind spot accelerates as scale and change grow.
A developer who has lost the context drifts toward ever more abstract instructions, and after rounds of ping-pong with the AI the result veers off, so the cost of starting over compounds.
We flip the roles to build Machine-in-the-loop instead of Human-in-the-loop. The author of the development is the human, and the machine assists from inside the loop.
The human writing the code directly is the founding principle, while the AI continuously observes the logic in progress and offers Review · Navigation · Warning — but it intervenes in the code only when the user asks. Otherwise it stays an observer.
Crucially, Navigation offers reference knowledge and patterns, not a finished answer — it shows without spoon-feeding, preserving authorship.
Because the human writes it directly, the implementation's locations and the path through the algorithm remain as long, concrete long-term memory — the exact opposite of false metacognition.
The cost of errors is also asymmetric. An AI hallucination can simply be ignored by the author, but a full-automation error becomes already-committed code that someone has to find and unwind. When the human slips, the AI actively leaves a warning.
The developer can focus more on the real work, and the anxiety over black-boxed logic disappears.
On speed, it won't turn a day's work into ten minutes — it turns an 8-hour job into 3–4 hours, but sustains that consistently. Even as scale grows and change accelerates, context forgetting and loss shrink, so we can always give the AI clear instructions.
And the developer can take responsibility for their own code.
Jarvis gives the human only three things. What they share is — they're all guidance, not production.
"I think this part is left out"
"This logic would be more efficient"
"Next, I think you could do this"
Polling itself is a single git diff,
so it barely uses any tokens. The expensive Jarvis review runs only when new change has accrued since the last review, a risk path changed, or a commit boundary is crossed,
keeping token consumption to a minimum.
On every wake, gauge the working tree's changed lines, risky-path changes, and the current HEAD. Almost zero tokens.
Was a new commit made? Were changes reverted? Compare against the marker (.jarvis/baseline) and auto-correct.
If any one of new change, risk, or commit boundary is met, it's a review candidate. But if a conversation is underway, hold, then flush the accumulated changes all at once when it settles.
Collect the changed files' AGENTS.md, README, and per-path rules, pass them as context, and call Jarvis. The result is wrapped in markers.
It picks its own next interval with ScheduleWakeup, riding on /loop's self-paced mode. Launch it as /loop /jarvis.
When new change has accrued since the last review (any amount — no fixed line/file threshold), it reviews. It fires once per accrual, never re-reviewing the same change. The AI shows up only after the human has personally written something.
Risky paths like payments and login warn instantly the moment even one line changes, regardless of volume. It never misses the "small but fatal."
When a new commit is detected, it checks once regardless of accrued volume. The moment just before a slip gets sealed into code is the golden time for a warning.
It defers reviews during a live conversation, then delivers the accumulated changes all at once when the conversation settles. It doesn't break your flow.
It gathers the changed files' nearest AGENTS.md, directory README, and per-path team rules and injects them into Jarvis. It reviews knowing even "this package's rules."
Launched as /loop /jarvis, ScheduleWakeup picks each next interval itself — it keeps watching with no further input.
Fill in the empty persona.md to set who Jarvis looks like, and what it's sensitive to. Navigation tuned to your own hands, not a vague, universal context.
Collect "what especially deserves attention in this project" under .claude/jarvis/focus/, and it looks through that as a priority lens over the general catalog.
When a large share of the accumulated changes is generated code, it reflects, in a single line, whether you've actually grasped it. It neither blocks nor fixes — just a mirror, so responsibility opens its eyes.
Optionally turn a source (Jira / Confluence / Notion / a doc / your own words) into a plan + checklist you approve, then every gated review checks your code against the checklist — what's missing per item, what's falsely "done." You author the plan and sequence the work; jarvis only drafts and recommends. Fully opt-in.
An AI-generated review is visually distinct from ordinary conversation. What's between the markers is Jarvis speaking; what's outside is the watch's operational messaging. The closing line reminds you of authorship every time.
On the first /loop /jarvis — before the strength question — it asks
"Draft a plan + checklist for this work?" Say no and nothing changes.
Say yes, and every gated review checks your code against a checklist you approved.
A Jira ticket, Confluence / Notion page, an existing doc — or write it in your own words. (Jira/Confluence needs the Atlassian MCP; otherwise it falls back to a doc path or direct dictation.)
jarvis-plan drafts a plan + a detailed checklist. You edit, resequence, cut, add — and approve. Only then are they written to .jarvis/.
Each gated review flags what's missing per item and any item you ticked that the code doesn't back up. Status line shows · plan 3/7. When all items look done, a final review — then it recommends closing; you confirm.
/loop /jarvis strength=high risk=**/*payment* debounce=90s
⚠️ Don't give /loop its own interval. Launch as /loop /jarvis (no interval) so it self-paces — the active/idle/strength args drive the cadence via ScheduleWakeup. /loop 5m /jarvis runs on a fixed schedule and ignores them.
| Key | Meaning | Default |
|---|---|---|
strength | Strength preset — bundles the polling-interval knobs below (low/medium/high) | medium |
risk | Risky-path glob — warns instantly, regardless of volume | off |
debounce | Quiet time before a conversation is considered settled | 90s |
active | Wake interval when the working tree has changes / right after a review | 4m |
idle | Wake interval when the working tree is clean | 25m |
warmup | Number of fast-polling ticks right after first load | 3 |
paths | Restrict the watched paths | all |
focus | Focus-area directory — a set of docs viewed as a priority lens | .claude/jarvis/focus/ |
mirror | Gray-zone mirror — a one-line memo when generated code runs high (non-enforcing) | on |
plan | Plan mode — asks on first boot; off to skip, or a source (plan=PROJ-1, URL, path) to opt in directly | ask on boot |
“During the few hours an AI service is down,
should our work be down too?”
The deeper we lean on full automation, the more those few hours leave us unable to do anything — because the understanding has accumulated inside the tool rather than in the person. For our hands to keep moving, unshaken, even when the tool briefly disappears, shouldn't our understanding of the code accumulate more inside us than inside the tool?
jarvis is one answer to that question.