PaperlayerView exact revision on arXiv

Source-linked AI summary

ParallelPilot: Supporting Coordination and Monitoring in Parallel AI Coding

Tao Long, Weili Shi, Hussein Mozannar, Maya Murad, Rafah Hosn

arXiv:2609.33113v1cs.HCcs.AIcs.DCcs.MA

TL;DR

Developers running concurrent coding agents must coordinate tasks and monitor activity across sessions, yet fragmented state and activity streams make that work demanding. The paper identifies PILOT through formative interviews and builds ParallelPilot as a supervision layer alongside existing coding tools. In a within-subjects study, the tool improved task outcomes and reduced tracking burden, but did not significantly improve perceived control or intervention success.

  • Problem

    Parallel coding requires developers to coordinate tasks and maintain awareness across sessions, while fragmented windows and continuous logs make session state difficult to track and recover.

    Source: §1 · p. 2

  • Method

    The paper derives the PILOT supervision framework from developer interviews and instantiates it in ParallelPilot, a coordination and monitoring layer alongside existing coding tools.

    Source: §1 · pp. 2–3

  • Results

    ParallelPilot improved task performance and reported efficiency, planning, awareness, and context recovery, but perceived control and intervention success did not significantly change.

    Source: §1 · p. 3

  • Takeaways & Limitations

    Supervisory support can ease coordination and monitoring, but does not by itself make agent outputs easier to verify or intervene on.

    Source: §1 · p. 3

    The short study blocks and fixed six-task set may limit ecological validity and constrain measured throughput; systematic code review was not required, so verification accuracy was not directly measured.

    Source: §9 · p. 22

Abstract

from arXiv · show

As coding assistants become increasingly autonomous, developers run multiple sessions in parallel, shifting the challenge from code generation alone to coordinating and monitoring concurrent agent work. Through a formative study (N=14), we identified PILOT: five supervisory practices for Planning, Isolating, Logging, Observing, and Triaging parallel sessions. We present ParallelPilot, a design probe that instantiates PILOT through a planning interface, a run-logger, and an ambient dashboard alongside existing coding tools. In a counterbalanced within-subjects study (N=16), participants using ParallelPilot increased ticket throughput by 63% in short coding tasks and supervised an average of one more concurrent agent at peak, while their tracking effort and context switching dropped. ParallelPilot also clarified execution plans, task dependencies, and intervention cues, and 14 of 16 participants preferred it over their current setup. These gains were not accompanied by significant improvements in perceived control or perceived success in redirecting the agents. Our findings demonstrate the value of explicit supervision support and position PILOT as a scaffold for designing tools that help people supervise concurrent work within and beyond coding. We suggest that future coding assistants should pair high-level awareness with low-cost paths back to the implementation evidence developers need to judge and steer agent work.

1 Introduction

As coding assistants take on complete engineering tasks, parallel sessions add coordination and monitoring work across tasks, contexts, and noisy activity streams. The paper introduces the PILOT framework and ParallelPilot, then reports improved task outcomes and reduced tracking burden without significant gains in perceived control or intervention success.

1 Introduction

  • Parallel AI coding runs independent coding sessions concurrently so developers can progress on multiple actionable tasks or projects instead of handling them sequentially.This arrangement adds coordination demands around task division, context, dependencies, session identity, progress, and intervention.Source: §1 · p. 2
  • The paper frames supervision as intertwined coordination—structuring tasks and assignments—and monitoring—tracking activity and deciding when to intervene.These demands are examined through context switching, monitoring effort, and session-state recovery after interruptions.Source: §1 · p. 2
  • Fourteen developers described brittle workarounds, missed stalls and input requests, lost task-session mappings, and difficulty recovering context after interruptions.These practices informed five recurring strategies: Planning, Isolating, Logging, Observing, and Triaging, synthesized as PILOT.Source: §1 · pp. 2–3
  • ParallelPilot adds a lightweight coordination and monitoring layer alongside existing agent CLIs, editors, and workspaces rather than replacing them.Its components support dependency-aware planning, per-agent event logging, and dashboard summaries for attention and context recovery.Source: §1 · p. 3
  • ParallelPilot improved ticket completion and throughput while reducing reported tracking and context-switching burden, but perceived control and intervention success did not significantly change.Participants also reported better planning, situational awareness, and context recovery while supervising more concurrent sessions.Source: §1 · p. 3

2 Related Work

Related work describes the promise of concurrent coding alongside the coordination demands of structuring tasks and maintaining context. It also highlights a monitoring challenge: readable agent activity may still go unnoticed or overwhelm developers.

2.1 Managing Concurrent Coding Tasks and Coordination Challenges

  • Concurrent coding is associated with productivity gains, but managing concurrent tasks and AI tools requires effective coordination and continuous monitoring.Reports include doubled weekly PR throughput and four agents completing projects in half the time of a linear workflow [2].Source: §2.1 · p. 3
  • Coordination requires decomposing and sequencing parallelizable work, tracking dependencies and context, and adapting as capacity changes.Prior work discusses orchestration [9] [38] [54], dependency-aware tools [51], and trace artifacts for switching contexts [43].Source: §2.1 · pp. 3–4

2.2 The Monitoring Challenges of AI Coding Assistants: Legibility and Human Factors

  • AI assistants produce code, logs, and explanations at volumes and speeds that create a legibility problem for human monitoring.Reported generation rates exceed human reading rates, including 33.9–46.8 tokens per second versus roughly 5.3 tokens per second [55].Source: §2.2 · p. 4
  • Readable execution traces do not ensure developers notice or understand agent activity, while missed intervention points can accompany insufficient monitoring.A study of over 100 developers found 94% failed to detect agent-inserted sabotage, and 56% accepted malicious code even when monitor warnings were present [53].Source: §2.2 · p. 4
  • Parallel agents compound oversight demands, including prioritizing or interrupting sessions, and prior deployments describe overwhelming information and review effort.A six-week deployment of three research agents reported overwhelming information; DoubleAgents deployments found monitoring support reduced review effort and saved time.Source: §2.2 · p. 5

3 Formative Study: Understanding How Developers Supervise Parallel AI Coding

The formative study examined experienced developers’ parallel coding workflows and the practices they used to supervise concurrent sessions. Participants described using parallel sessions during downtime, while also reporting substantial coordination and monitoring costs that informed the PILOT framework.

3.1 Overview; 3.3 Procedure

  • The 60-minute formative interview study asked 14 developers why they used parallel coding and how they coordinated and monitored sessions.Interviews included workflow walkthroughs and questions about tracking, attention cues, output judgment, and completion.Source: §3.1 · p. 5, §3.3 · p. 5

3.2 Participants

  • Participants were experienced coders and frequent AI-assistant users, recruited for extensive experience running more than two sessions in parallel.All used AI coding assistants more than three times daily; ten had run parallel sessions more than 30 times.Source: §3.2 · p. 5

3.4 Data Collection and Analysis

  • Researchers analyzed survey responses descriptively and used inductive affinity diagramming across transcripts, notes, and screen-shared observations.Repeated rounds of co-author feedback refined the codes and themes into a preliminary framework.Source: §3.4 · p. 6

3.5.1 RQ1: Why, when, and how often do developers turn to parallel AI coding?

  • Three concurrent sessions was the most common setup, reported by 8 of 14 participants, and most participants used two to four sessions.CLI interfaces were used by 13 of 14 participants (92.9%); IDE-integrated chat and standalone applications were each used by 11 (78.6%).Source: §3.5.1 · p. 6
  • Participants commonly started parallel sessions during workflow downtime, such as waiting for an agent, build, or test to finish.They described replacing sequential waiting with active monitoring, answering, and redirecting across concurrent sessions.Source: §3.5.1 · p. 6
  • 45.3% of coding time was spent with parallel multi-session AI, compared with 48.6% with single-session AI; Figure 2 depicts the participant-level distribution.Only 6.1% of coding time was reported as occurring without AI.Source: §3.5.1 · p. 6, Figure 2 · p. 7

3.5.2 RQ2: How Do Developers Coordinate and Monitor Parallel AI Coding?

  • All 14 participants described coordination and monitoring overhead, including recall costs, missed alerts, tiring multitasking, and overwhelming logs.Participants used summaries and constrained their screen setups to keep track of sessions.Source: §3.5.2 · p. 8
  • Participants identified five recurring strategies: Planning, Isolating, Logging, Observing, and Triaging parallel sessions.PILOT organizes practices for deciding what runs in parallel, preventing interference, preserving context, observing state, and identifying intervention needs.Source: §3.5.2 · p. 8

4 The PILOT Framework

PILOT describes five complementary practices for coordinating and monitoring parallel AI coding, with no fixed sequence. Across these practices, developers prepare and separate work, preserve context, observe agent activity, and prioritize interventions.

4.1 P — Planning: Scoping and Preparing the Work

  • Participants prepared parallel work by scoping manageable tasks, prioritizing what to check first, and equipping agents with relevant context and success criteria.Nine participants also developed reusable artifacts to improve consistency across sessions.Source: §4.1 · p. 9

4.2 I — Isolating: Managing Separability

  • Eleven of 14 participants modularized code and tasks to avoid interference, while misjudging separability could make reconciliation take longer than sequential work.Participants used task boundaries, branches, worktrees, and other forms of isolation.Source: §4.2 · p. 9

4.3 L — Logging: Externalizing Memory

  • Seven participants kept durable session logs that supported later context recovery, verification, and steering, reducing the working-memory cost of switching between sessions.Logs recorded decisions and outcomes and could be fed back into later sessions.Source: §4.3 · pp. 9–10

4.4 O — Observing: Assembling a Centralized View

  • Ten of 14 participants arranged active sessions for a single-glance view, but turning away from the current task often meant missing agent updates.A centralized point of contact can lower manual screen-switching costs and focus attention.Source: §4.4 · p. 10

4.5 T — Triaging: Prioritizing Intervention Cues

  • Triage meant detecting completion, clarification requests, errors, or unexpected delays and prioritizing which sessions needed intervention.Clarification requests and errors required immediate intervention but were among the signals participants most reliably missed.Source: §4.5 · pp. 10–11

5 ParallelPilot: A Design Probe for the PILOT Framework

ParallelPilot is a design probe that adds a coordination and monitoring layer alongside existing coding tools. Its planning interface, run-logger, and ambient dashboard instantiate PILOT across task preparation, context preservation, and agent monitoring.

5 ParallelPilot: A Design Probe for the PILOT Framework

  • ParallelPilot combines dependency-aware planning, session logging, and an ambient dashboard to structure work, preserve context, and surface agent status and intervention cues.It runs alongside developers’ existing coding CLIs, editors, and workspaces.Source: §5 · p. 11, Figure 5 · p. 11

5.1 System Design

  • The planning interface externalizes task dependencies and supports editable plans that separate potentially conflicting work.In the walkthrough, Amelia retains three agent windows rather than four to keep supervision manageable.Source: §5.1 · pp. 12–13, Figure 6 · p. 12

5.1.2 Run-Logger: Preserving Session Context.

  • The run-logger links agent sessions to tasks and preserves activity as raw records, session memory, and brief tracking summaries for monitoring and context recovery.Users can inspect session memory and cross-check CLI output when a ticket needs closer attention.Source: §5.1.2 · p. 13

5.1 System Design

  • The ambient dashboard maps tasks into Done, Running Now, and Next, surfacing progress, completion, and attention cues alongside session memory and terminal access.Amelia uses it to review completed work and answer an agent’s question directly in its CLI session.Source: §5.1.2 · pp. 13–14, Figure 7 · p. 14

5.2 System Implementation

  • ParallelPilot is a local-first web application whose planning, logging, and dashboard components use local records while model-assisted processing uses remote APIs.The dashboard refreshes approximately every 2.5 seconds, and developers retain direct access to their CLI sessions.Source: §5.2 · p. 14

6 ParallelPilot User Study

The user study evaluated ParallelPilot’s effects on task outcomes, user experience, coordination, and monitoring in an 80-minute counterbalanced within-subjects design with 16 developers. Participants used ParallelPilot for one project and a no-ParallelPilot baseline for the other.

6.1 Overview

  • The 80-minute, in-person, counterbalanced within-subjects study examined task outcomes, user experience, coordination, monitoring, perceived control, intervention effectiveness, and trust.Each participant used ParallelPilot for one project and the no-ParallelPilot baseline for the other.Source: §6.1 · p. 15, §6.3 · p. 15

6.2 Participants

  • All 16 participants had prior parallel AI coding experience, and 15 described themselves as Beginners or Somewhat Experienced.Fifteen reported using AI coding assistants at least daily.Source: §6.2 · p. 15

6.3 Study Design and Procedures

  • Participants completed two counterbalanced coding blocks, with 20 minutes for assigned tasks in each block and a post-condition survey afterward.The baseline allowed multiple sessions, planning with the coding assistant, worktrees, and notes.Source: §6.3 · pp. 15–16

6.4 Task Design

  • Each project had six tickets, including same-file changes, a two-task dependency chain, independent tasks, and a product or policy decision.The tasks were designed to create opportunities for coordination and design choices with coding agents.Source: §6.4 · p. 16

6.5 Data Collection and Analysis

  • The researchers compared conditions using paired t-tests with Benjamini–Hochberg correction and analyzed interviews and notes through inductive affinity diagramming.Statistical significance required unadjusted p < .05 and BH-adjusted q < .05.Source: §6.5 · p. 16

7 ParallelPilot User Study Results

In a 16-developer within-subjects study, ParallelPilot improved short-task completion, throughput, and supervision capacity while reducing tracking effort and improving coordination and monitoring ratings. These gains did not significantly improve perceived control, intervention success, trust, or delegation confidence.

7.1 RQ1 (Overall Effectiveness & User Experience): Does ParallelPilot improve task completionH1a, throughputH1b, supervision capacityH1c, and user experienceH1d?

  • 63% higher throughput (0.445 vs. 0.272 tickets per minute) and 1.50 more tickets completed (5.69 vs. 4.19 of 6) with ParallelPilot than without it.Fourteen of 16 participants completed all six tickets with ParallelPilot, compared with eight of 16 without it; total task time was also 2.57 minutes lower.Source: §7.1 · p. 16, Table 1 · p. 17, §7.1.1 · p. 18

7.1.2 [H1c & H1d] Improved perceived efficiency, parallel supervision capacity, and UX. Self-reported measures

  • Participants used about one more agent at peak with ParallelPilot (3.25 vs. 2.31) and rated perceived efficiency 1.69 points higher (3.75 to 5.44 on a 7-point scale).Fourteen of 16 participants preferred ParallelPilot; participants anticipated supervising 1.44 more agents in future use.Source: §7.1 · p. 16, §7.1.2 · p. 18

7.2.1 [H2a & H2b] Improved coordination: clearer decomposition and dependency awareness. ParallelPilot

  • Dependency understanding rose from 3.44 to 5.50 and plan clarity from 3.63 to 5.00, while participants rated the planning interface 6.63/7 for usefulness.Six of eight participants who used ParallelPilot first later applied its planning lessons in the baseline condition, particularly for file-sharing conflicts and sequencing dependencies.Source: §7.2.1 · pp. 18–19, §7.2 · p. 18

7.2.2 [H2c & H2d] Improved monitoring: faster status awareness with less tracking effort. ParallelPilot also

  • Tracking effort fell from 4.63 to 2.75, while awareness of agents finishing, stalling, or needing input rose from 3.63 to 6.19.Awareness of overall progress increased from 3.44 to 6.06, and participants rated the live dashboard 6.88/7 for usefulness.Source: §7.2 · p. 18, §7.2.2 · p. 19

7.3 RQ3 (Control & Intervention Dynamics): Does Does ParallelPilot support greater perceived control and intervention effectivenessH3a, and trust and delegation confidenceH3b?

  • Despite improved intervention-cue awareness, perceived control (3.94 to 4.31) and intervention success (3.94 to 4.13) did not significantly improve.Confidence in interventions, output trust, and delegation confidence also did not improve significantly.Source: §7.3 · p. 19
  • Progress summaries and plans helped participants coordinate and spot agents needing attention, but did not necessarily provide evidence to judge code correctness or an agent’s approach.Some participants described inspecting implementation details and reconstructing session context less often, leaving re-engagement necessary when intervention required deeper evaluation.Source: §7.3 · pp. 19–20

8 Discussion

The discussion connects parallel-agent supervision to human management practices and presents PILOT as a starting point for interface support and possible training. It argues that tools should reduce bookkeeping while preserving visible, task-sensitive paths back to implementation evidence for judgment and intervention.

8.1 Learning from Human Management Practices

  • Participants drew on human management practices, such as checking whether work was progressing and whether an agent’s approach seemed appropriate, and matching agents to tasks by relevant expertise.The paper presents prior supervisory experience as a possible source of strategies for managing parallel AI coding.Source: §8.1 · p. 20
  • Whether training in human management practices improves agent supervision remains an open empirical question, including which practices transfer, need adaptation, or create misleading expectations.The discussion also calls for examining where the human-management analogy breaks down and how its social dynamics relate to agent supervision.Source: §8.1 · pp. 20–21

8.2 The Abstraction Tension: Designing Future Human-AI Tools for Re-engagement

  • ParallelPilot’s high-level overview can reduce bookkeeping, but status alone does not establish whether code is correct or an agent’s approach is appropriate.The discussion recommends a clear path from summarized status to code, decisions, and evidence, with abstraction level specified per task and revisited over time.Source: §8.2 · p. 21
  • The design challenge is to distinguish avoidable effort from engagement that supports informed decisions, including opportunities to understand, judge, and shape results.The discussion connects this concern to co-creative tools and visual analytics or clinical decision-support, where reducing effort should preserve interpretation and judgment.Source: §8.2 · p. 21

9 Limitations and Future Work

The evaluation is bounded by its participant pool, design-probe implementation, short controlled tasks, and rapidly evolving practice. The authors call for broader populations, alternative designs and models, component-level study, and repeated in-the-wild evaluation.

9 Limitations and Future Work

  • The formative study involved 14 participants, primarily researchers and research interns, so broader industry populations and development constraints remain to be examined.The authors specifically identify speed-first MVP development and open-ended research engineering as settings for future study.Source: §9 · p. 22
  • ParallelPilot is a design probe, not an exhaustive design-space exploration, and its four intervention cues may not cover all real-world intervention needs.Findings also depend on the specific models and tool configurations; alternative abstractions, information displays, models, and their effects remain to be explored.Source: §9 · p. 22
  • The 16-person study used 20-minute blocks and six seed tasks, which may underestimate context-recovery costs and create a completion ceiling.It measured throughput rather than verification accuracy or implementation-level understanding, and its integrated-package comparison cannot isolate component or automation effects.Source: §9 · p. 22
  • The studies captured practices in mid-June and mid-August 2026, so their specific challenges may change as models, tools, and organizational norms evolve.The authors call for examining how challenges and developer strategies develop over time.Source: §9 · p. 22

10 Conclusion

ParallelPilot operationalizes PILOT as a supervision layer and improved task performance and supervision efficiency in the study. Participants still did not always know how to steer agents, and some felt less familiar with the code.

10 Conclusion

  • ParallelPilot translates PILOT into a supervision layer, and the study found more tickets completed, more concurrent agents supervised, and less tracking effort.The conclusion also reports reduced context switching.Source: §10 · p. 22
  • PILOT offers tool designers a scaffold for identifying where parallel supervision breaks down and what interface support can carry that load.Source: §10 · p. 22
  • Participants knew when agents needed attention but did not always know how to steer them, and some felt less familiar with the code.The conclusion recommends low-cost paths from status back to implementation evidence for judging and redirecting agent work.Source: §10 · p. 23

A.1 Planning Interface Implementation Details

ParallelPilot links reviewed task plans to isolated agent sessions, persistent logs and session memory, and a dashboard for status and intervention cues.

A.1 Planning Interface Implementation Details

  • The planning interface analyzes task breakdowns, dependencies, and overlapping edits, then presents an editable dependency graph, Gantt chart, and execution instructions.Users can revise the proposed plan; launch generates per-agent commands and steering files and assigns each agent an isolated repository directory.Source: §A.1 · p. 25

A.2 Run-Logger Implementation Details

  • The run-logger stores raw activity and conversation records alongside generated session memory and short progress summaries, keeping context available without interrupting agents.Raw logs, cross-session Markdown memory, and UI-card summaries are stored locally; memory captures decisions, progress, and key events.Source: §A.2 · pp. 25–26

A.3 Ambient Dashboard Implementation Details

  • The dashboard organizes task cards by agent and execution stage, while triage flags inactivity, terminal errors, and input requests for attention.Completion cues prompt developers to verify the work before marking a task done; terminal links and Markdown history support inspection.Source: §A.3 · p. 26

B User Study Method Details

The study used two six-ticket projects designed to exercise parallel-work coordination, with counterbalanced within-subjects sessions in a multi-monitor coding setup.

B.1 Task Design Details

  • Sparkmatch and Kart each supplied six coding tickets, with tasks spanning features such as matching or shopping, profiles, and recommendations.Source: §B.1 · pp. 26–27
  • The projects included independent tasks, dependencies, a shared-file task pair, and a product or policy decision to exercise coordination and monitoring.Participants were not required to manage pull requests, review code, or merge changes.Source: §B.1 · p. 27

B.2 Procedure Details

  • Each 80-minute session used two counterbalanced coding blocks crossing tool condition with project, followed by a survey and interview.The study involved 16 participants divided into four groups of four.Source: Figure 8 · p. 27

B.3 Apparatus Details

  • Participants used VS Code with GitHub Copilot on a three-screen workstation, and each session used a newly authenticated Copilot instance without persisted history or context.ParallelPilot's planning interface and monitoring dashboard ran locally in that condition.Source: §B.3 · pp. 27–28

C.1 Study Design Checks: Task Equivalence

This section describes checks on task and session comparability and the study instruments used to assess participants’ parallel-coding experiences with ParallelPilot and the comparison condition. Survey, interview, and think-aloud prompts covered agents’ work and progress, which sessions needed attention, intervention, and context recovery.

C.1 Study Design Checks: Task Equivalence

  • Four of five task composites met equivalence under TOST with a ±1-point margin, while supervision-specific load was inconclusive because its confidence interval was too wide.Nine of 16 participants rated the projects similarly hard; the remaining seven split between Sparkmatch (3) and Kart (4).Source: Table 2 · p. 28, §C.1 · p. 28

C.2 Study Design Checks: Session-Order

  • None of five session-order composite comparisons was significant (all p> .05; |d_z| ≤0.29), though the small sample does not rule out learning or carryover effects.The comparisons used paired tests of first- and second-session composites.Source: Table 3 · p. 28, §C.2 · p. 28

C.3 Task-Phase Time Allocation

  • Dual completers spent 12.43 minutes per task with ParallelPilot versus 15.87 minutes without, while Plan & Isolate accounted for 25% versus 27% of task time.Both phases were shorter with ParallelPilot: Plan & Isolate by 1.27 minutes and Launch + Monitoring by 2.17 minutes.Source: Figure 9 · p. 29, §C.3 · p. 29

C.4 Participant Interactions with ParallelPilot’s Three Components

  • Participants used the planning interface to review dependencies, the run-logger to launch sessions with automatic capture, and the ambient dashboard to monitor activity and investigate stalls.They kept the dashboard visible alongside existing coding tools, inspected completion or stall notifications, and held dependent work for later execution waves.Source: §C.4 · p. 29, Figure 10 · p. 30

C.5 [RQ2 →RQ1] Exploratory Associations Between Supervisory Support and Efficiency Gains

  • Coordination-composite gains correlated with more tickets completed (ρ= .55, p< 0.05) and higher tickets completed per minute (ρ= .62, p< 0.05).Participants described clearer assignment and dependency isolation as reducing conflict risk and agent collisions, potentially reducing rework.Source: §C.5 · p. 31
  • Monitoring-composite gains correlated with perceived efficiency gains (ρ= .62, p< 0.05), but not with significant objective productivity gains.Participants described reduced effort checking progress and greater certainty about agent status; the authors suggest monitoring support improved supervision experience rather than task output.Source: §C.5 · p. 31

D.3 ParallelPilot User Study – Pre-Survey Questions

  • The pre-survey asked about participants’ parallel-coding experience, workflow challenges, and active coding-screen setups.Items covered planning and parallelization, conflicts, monitoring, context switching, recall, and intervention; screen options distinguished laptop and monitor configurations.Source: §D.3 · pp. 34–35

D.4 ParallelPilot User Study – Post-Condition Survey Questions

  • The survey asked participants to rate mental effort tracking agents, awareness of each agent’s work, clarity of plans for dividing work in parallel, and manual bookkeeping needed to stay on top of things.Responses used a 1–7 agreement scale unless otherwise specified.Source: §D.4 · pp. 35–36

D.5 ParallelPilot User Study – Final Comparative Survey Questions

  • The final comparative survey assessed ParallelPilot’s overall evaluation and feature usefulness, setup preferences, perceived task differences, and comparative work quality and quantity.Preference questions covered awareness, planning, verification, mental effort, and control.Source: §D.5 · pp. 36–37

D.6.1 Post-task interview.

  • Post-task interviews asked what the prototype changed, whether it helped participants track sessions and notice risks, and how it affected intervention and workflow preferences.Participants were also asked whether they would use a similar tool and what should change first.Source: §D.6.1 · pp. 37–38

D.6.2 Think-aloud prompts during the tasks.

  • During tasks, think-aloud prompts asked what each AI session was doing, how participants judged whether it was on track, and which session needed attention next..Source: §D.6.2 · p. 38
  • Participants were asked what would prompt them to intervene, redirect, or stop a session, and what they would inspect first to recover context after a few minutes away.Source: §D.6.2 · p. 38
Loading 2609.33113v1…