A coding agent can leave behind a detailed chat transcript and still make you hunt for the active run, the affected code, the access it had, and the change waiting on you.
That is the workbench problem. More generated text won't solve it. The developer needs a way to move between a live session, the relevant code and runtime, and a reviewable change. Those are different views of the same task, but none can stand in for the others.
Start with the bug, not the prompt
Imagine a settings dialog whose Save button works with a mouse but not from the keyboard. This is a hypothetical handoff, not a test of a particular agent product.
A screenshot of the button tells the agent where to look. It does not tell it whether the dialog uses a shared form component, which keyboard behavior is expected, or whether other settings screens depend on the same handler. Before delegating, give it the affected route and component, the expected keyboard behavior, and the neighboring screens that must keep working. Then identify the revision it should start from.
Browser element selection can help with that first step. PulseDev's product description proposes selecting an element in a local browser, passing context to a coding agent, and reviewing a proposed diff there. I like the shorter path from UI to code. I wouldn't mistake the selected element for a map of every place a shared component is used; the reviewer still has to inspect the call sites and behavior.
Make the run findable
Now suppose the agent is running while another developer takes over. A chat transcript might explain the original request; it is a poor answer to "which session should I resume?" A practical handoff should name the run, the repository and revision, its current state, and the pending decision. If a remote session or a stale checkout is involved, the handoff should say so rather than leaving the next person to infer it.
Corgi's maker describes an activity feed, unread-session navigation, and launch/resume search for agent terminals. Those are examples of useful session ergonomics, not evidence that the feed verifies work. An "active" badge does not tell you whether an edit is correct, and a quiet terminal does not prove nothing happened. The IDE discussion around project navigation and debugging points to the other half of the workbench: you still need to find the code and understand how it behaves in the project.
I would keep a small handoff card next to a nontrivial run. This is a proposed operator checklist, not a feature I tested in any of the tools above:
Task: keyboard Save behavior in settings dialog
Starting revision: <commit or immutable revision ID>
Affected route/component: <location and known shared call sites>
Expected behavior: <keyboard path and unchanged neighboring behavior>
Session: <run ID, location and current state>
Access: <declared file/tool/network scope; pending requests>
Review: <diff or commit to inspect; checks actually run or not run>
Decision: <accept, request changes, or investigate further>
If you can't fill in the revision or session ID, leave it blank and investigate. Guessing after the run just makes the handoff look more complete than it is.
Permissions belong in a separate column
A readable diff answers what changed in the repository. It does not tell you everything the agent could read or contact while making that change.
OpenShell's README describes an isolated agent runtime with file, process, and network policies, plus checks before proposed policy expansions are approved. That is a different control from a session feed or a code review. A request for broader network access deserves its own decision; approving it does not approve the resulting code. Conversely, rejecting a diff cannot retroactively revoke access the run already had. These are project-described controls, not a claim that any sandbox guarantees containment.
For the hypothetical dialog fix, inspect the proposed patch in the IDE, check related uses of the shared component, and look at the keyboard path in the running UI when possible. Separately, look for access requests that exceeded the task's declared scope. If a check wasn't run or the session history isn't available, mark that gap instead of treating the activity feed as a security receipt.
The handoff test
Another developer should be able to locate the run, see the code and context it touched, inspect any capability changes, and decide what happens next without reconstructing the task from a long chat. For a one-line typo, that's overkill. For a shared UI component or a run with new tool access, it's the difference between supervising work and merely watching it happen.
If the next developer can't tell what to approve or resume, a prettier chat pane won't fix the handoff.
Source notes
- DEV.to: Agents go mainstream while trust becomes the bottleneck — author's argument about review throughput and production quality; not a measured adoption study.
- NVIDIA/OpenShell README — project description of isolated runtime policy and proposed policy-change checks; not independent containment testing.
- Show HN: Corgi — maker description and operator discussion of live-session ergonomics.
- Reddit: Do we still need an IDE? — qualitative discussion of navigation, debugging, and responsibility; not a survey.
- PulseDev on Product Hunt — product description and comments on element context and diff review; not a hands-on evaluation.
Top comments (0)