Skip to content

Studio: foreground and unattended on the same task

Learning objectives

Demonstrate LO2 by designing a bounded background workflow and LO9 by accepting only what your own verification supports. Use a small subtask from your project or current contribution, such as a fix with a local reproducer. This is studio practice in your existing work record; it does not add a submission or change contribution requirements.

Minimal example

Generate the same summary fix in the two modes from the notes. Verify both against the same unchanged cases, including the display case. First predict whether each candidate's branch report is enough; then inspect the diff and identify which requirement the extra display change violates.

Hands-on exercise

Prepare a request that can stop

Choose a task small enough to review in class. Write its observed failure, allowed files, unchanged behavior, verification command, forbidden changes and stop condition. Run the reproducer on the base before asking the agent for a change. If you cannot reproduce the failure or the check cannot fail, ask the teaching team to help narrow the task. Use the current syllabus's access rules: run the agent in a dedicated directory or container, keep employer and cloud credentials out of that environment, and never put keys in the repository, prompts, screenshots or logs. For both the foreground and unattended runs, restrict the agent's permissions to that directory. Use the provided agent seat; no new paid service or hosted pipeline is needed.

From a clean local checkout of your own repository in a dedicated parent directory, type these Git commands yourself. Keeping both worktrees under that parent prevents the agent from being started outside the dedicated directory. Commit the acceptance tests you wrote before recording the base. Use fresh sibling paths and branch names; if they already exist, inspect them and choose unused names.

git status --short
git rev-parse HEAD
# Replace BASE_SHA below with the full revision just printed.
git worktree add -b studio-w9-foreground ../studio-w9-foreground BASE_SHA
git worktree add -b studio-w9-unattended ../studio-w9-unattended BASE_SHA
git worktree list

Use that same recorded request, base and initial checks in both worktrees. Keep the acceptance copy outside the directories the agent may edit. Specify how your repository's test command will use that unchanged copy against each implementation. If the language or harness makes this difficult, keep the test file unchanged and inspect its diff before execution; do not count a test rewritten by the agent as independent acceptance evidence.

Generate, then verify in each mode

  1. Foreground: open your usual coding agent in ../studio-w9-foreground. Stay present and allow questions. Record only interventions that affect the task. Stop when it returns a candidate or hits the limit you set. Ask for a diff and check evidence; no push or merge.
  2. Unattended: start a fresh session in ../studio-w9-unattended with the same request. Use the agent's supplied non-interactive mode if available. Otherwise send the complete request in an ordinary local terminal and give no further answers until it returns. Keep the computer awake; you may work on the comparison record while it runs. Require it to stop and report ambiguity, a permission request, a failing gate or its agreed limit. Do not weaken permissions to get a result. If the tool requires interaction, stop and record that limitation; it is evidence about this workflow.
  3. Verify each: review git status --short, all changed hunks and untracked files. Run the exact acceptance command yourself using the unchanged checks. Keep the exit status and meaningful output, not merely the agent's summary. Check that a forbidden test edit or missing result would block acceptance.
  4. Compare: fill the small table below. Hold the scope constant; any foreground clarification is an intervention to report, not a silent improvement of the second prompt.
  5. Revise: pick one uncertainty, narrow it and specify the next check. Do not spend the whole studio waiting: stop at your agreed limit, retain the partial result and discuss what smaller task could finish. Reserve the final part of class for verification and revision.
Evidence Foreground Unattended
Base, candidate revision and allowed scope
Interventions / unanswered questions
Preserved acceptance check and actual result
Unexpected hunks or untracked files
Observed elapsed time, waiting and rework
Claim still unknown and next check

Paper verification when an agent seat is unavailable

If the supplied agent seat is unavailable, stop the run and record the access blocker. You may still use the two hand-worked candidates in the notes as a paper verification exercise. In the foreground worktree, trace the summary-only change; in the unattended worktree, trace that same fix plus one extra change that violates the unchanged requirement (for the duration example, display 3:05 instead of 3m 05s). Inspect both diffs and record predicted check results as paper evidence, never as an agent run. This exercise needs no key, network connection or cloud service.

Verification

Keep the task request, each diff and check result, the comparison table, one AI-use note (or its existing ID), and this line in your existing record:

Accept / Narrow / Recheck / Stop — evidence: [revision, check result, scope finding].

State separately which run your decision applies to. An unknown result needs a named next check. For a contribution, prepare a proposed PR description locally only after verification; upstream submission follows that repository's rules. The studio itself grants no authority to publish or merge. For a project, integrate only the chosen candidate and rerun the checks on the combined revision. Do not combine the two competing fixes.

After the agent processes have stopped and you have saved the evidence, inspect each worktree's status. Remove a worktree only after its intended changes are committed or saved elsewhere; do not force removal to hide untracked or unfinished work.

Common mistakes

  • Starting the second run from the first run's fix makes the comparison invalid; use the same recorded base and acceptance cases.
  • Silently answering an unattended question changes the mode; record an intervention or stop and narrow the request.
  • Granting more access to finish hides a workflow limit; stop and explain the missing permission.
  • Timing a paper exercise as if it were a model run fabricates evidence; label predicted results.
  • Keeping only “tests passed” leaves acceptance unresolved; keep the command and actual result.