HISTORICAL DIG · JUL—AUG 2026
Where do multiple coding agents need a person to step in?
When several coding agents work at once, task state, permission requests, failures, and diffs get scattered across windows. The practical question is not how many windows can stay open, but which events should bring a person back to decide.
WORKFLOW 001 · NODE POSITION
Current node 027 nodes total
Make human handoffs visible
HOW IT RELATES TO WORKFLOW 001
Relation to the current subject
It answers only when to call a person back.
The current Workflow 001 asks how to narrow an AI toolset and working method; Q03 asks how to return to the correct project state days later. This historical record covers one smaller moment: once agents are already running in parallel, how should blockers, permissions, failures, diffs, and final confirmation become visible to a person?
Record state at the time
- Coding & agents
- AI agent collaboration
- In-depth record
- Developing
- Two first-party product sets + one secondary directory record · not installed or tested
THE GUIDANCE AT THE TIME
Judgment at the time
A person need not watch every step, but must see the moments that can change the result.
Open full rationale and return rules
The editorial judgment at the time was to foreground blockers, permissions, failures, code diffs, and final confirmation. Audio or status cards can call a person back; terminals, diffs, and test results keep the inspectable detail.
- Who it was for
- Developers already using multiple agents in low-risk repositories who are starting to drown in terminals, diffs, and permission requests
- Why it mattered then
Open note
If parallel results can only be found by constantly polling windows, adding agents may increase decisions awaiting review before it increases deliverable output. That is a working hypothesis that still needs a real run.
- Where the judgment stops
Open note
This record did not install or run the tools side by side and has no BitShovel Run, completion rate, or independent-user result. Product interfaces show how makers present a workflow; they do not establish that parallel work is faster, safer, or more stable, and they do not validate DevHub.
CHECK BEFORE READING ON
Fit check
First check that manual polling is a problem you actually have.
This record may help
- You already run two or more coding agents and manual status polling is beginning to consume attention.
- The work is in a low-risk test repository, can use isolated branches, and will still receive human diff and test review before merge.
Do not use it yet when
- You only run one occasional agent; a normal terminal or editor tab is already enough.
- The first trial requires production secrets, bypassing isolation, or automatic merge.
- Your decision requires BitShovel tests of stability, efficiency, or safety—this record has none of those results.
NEXT VALIDATION, NOT A RESULT
Historical trial
Unrun validation draft: use two reversible tasks on low-risk branches.
- Time needed
- 15–30 minutes
- Likely cost
- Start with existing tools or a free tier
- Permission boundary
- Low-risk test repository, isolated branches, no production secrets
- 01
First step
Open this step
Give each of two agents one small, easily reversible task. Note every moment that requires you to return to the terminal, a permission request, the diff, or the tests.
- 02
What should exist
Open this step
A short list containing only the events that truly require a human decision.
- 03
If run, what to watch
Open this step
If run, observe whether blockers, permissions, failures, and the final diff remain visible after you step away. A person must still confirm the merge.
- 04
Stop when
Open this step
The tool asks to bypass isolation, disable safety controls, use production secrets, or merge automatically.
- 05
How to back out
Open this step
Stop the agents, revoke temporary access, delete the test branches, and keep the run record.
MAKER INTERFACES, NOT BITSHOVEL RUN CAPTURES
Method and interfaces
Interfaces can show how attention is organized; they cannot replace a real run.
Open method boundary
Two official JetBrains Air interfaces show parallel task state and code-diff review. They support an observation about public information architecture, not a conclusion about speed, stability, safety, or data flow.
This maker interface shows how task state and review alerts are presented. It is not a BitShovel run capture and says nothing about actual speed, stability, or data flow.
About this image and its source
Copyright © 2026 JetBrains s.r.o., used with permission. JetBrains Air and the Air logo are trademarks of JetBrains s.r.o. Here, permission follows the general limited license in the public JetBrains Brand Guidelines; it is not a separate BitShovel approval or endorsement. BitShovel preserves the original ratio only to comment on the publicly presented parallel-task workflow.
Open source page ↗Read use and attribution guidelines ↗
This maker interface only shows that a completed task can return to a file diff. It does not establish that review found problems or that the change was safely merged.
About this image and its source
Copyright © 2026 JetBrains s.r.o., used with permission. JetBrains Air and the Air logo are trademarks of JetBrains s.r.o. Here, permission follows the general limited license in the public JetBrains Brand Guidelines; it is not a separate BitShovel approval or endorsement. BitShovel preserves the original ratio only to comment on the public diff-review interface.
Open source page ↗Read use and attribution guidelines ↗SOURCES AND EVIDENCE
Sources and evidence
As of August 15, 2026, the record has two first-party product sets and one historical secondary directory entry; BitShovel still has not installed or run these tools side by side.
Open evidence boundary
A 2026-08-15 recheck retained two first-party product sets, JetBrains Air and Heard. The old CodeAgentSwarm link is a third-party directory entry, preserved only as source history and not counted as maker evidence.
- 01First-party product material · Rechecked
JetBrains Air public-preview launch material
Open source boundary
Checks maker descriptions of planning, isolated workspaces, parallel tasks, and human review. A public preview is not a stable finished product.
Open original source ↗ - 02First-party product material · Rechecked
JetBrains Air Review documentation
Open source boundary
Checks how the maker presents file diffs and human confirmation. This review flow was not run by BitShovel.
Open original source ↗ - 03First-party product material · Rechecked
Heard product page
Open source boundary
Checks maker descriptions of selective audio alerts for blockers, decisions, failures, and completion. The product was not installed.
Open original source ↗ - 04Historical secondary directory record · Rechecked
Uneed directory entry for CodeAgentSwarm
Open source boundary
The old record mislabeled this as maker material. Uneed is a third-party directory; until a readable first-party page or repository is available, it does not support specific capability claims.
Open original source ↗
REVISION RECORD
Revision record
Keep the most important correction, including the original claim and its new boundary.
Open 1 revisions
- Revision 3
Corrected mistaken claims about JetBrains Air running locally and keeping data on-device, then returned the record to one question: when a person needs to step in.
- What the record said before
- JetBrains was described as releasing a local AI coding assistant whose code never leaves the machine.
- What changed
- What is supported is a multi-agent planning and review workspace. Where data actually goes, and how stable or safe the tool is, still require testing with the chosen configuration.
WHAT THIS RECORD LEAVES
What this record leaves
Map the intervention points before deciding whether the test is worth running.
If the problem is restoring project state, return to Workflow 001 or Q03. This historical record is worth another test only when manually polling several agents has become a real cost.
Back to the Dig index