The Overnight Build — DVx AI Field Manual 02

Most bad overnight runs fail before the agent starts. The human has the product in their head, hands an agent a paragraph, and goes to bed. The model fills in the missing decisions. By morning, it has done a great deal of work on the wrong version of the product.

The answer is not a longer prompt. It is a better shift change. This manual shows how to prepare one long-running software task, let Codex, Claude Code, or another coding agent work through it safely, and come back to evidence you can review.

The DVx default: Do not hand an agent a complex task. Hand it an environment that makes the next correct action obvious.

1. Know what earns an overnight run

An overnight run is useful when the work is large enough to benefit from uninterrupted execution and bounded enough to verify without a meeting.

Good candidates

Execution is the hard part

Implement a coherent feature from an approved brief.
Migrate a package or API behind an existing test suite.
Reproduce and fix a well-described bug.
Update a design system across a bounded surface.
Build a prototype in an isolated environment.
Run an audit that returns findings, not production changes.

Poor candidates

Judgment is still unresolved

Decide what the product should be.
Invent a visual direction from a vague reference.
Touch production data without a tested migration path.
Make legal, pricing, people, or customer commitments.
Change independent systems that cannot be verified separately.
Work that needs a human decision every twenty minutes.

If the unresolved part of the task is mostly execution, the agent may be ready. If the unresolved part is product judgment, keep the human shift open.

2. Treat the work as three shifts

The shift change The human decides. The agent executes. The human accepts.

01 · Before Human shift Resolve purpose, product tradeoffs, design direction, architecture boundaries, risk, and acceptance.
02 · Overnight Agent shift Work in isolation, implement one testable slice, verify it, record the evidence, and repeat.
03 · Morning Review shift Exercise the result, inspect tests and risky decisions, then accept, continue, split, or discard.

Human gateNo unattended run merges, deploys, migrates, or makes an external commitment by default.

The handoff is the product. Each shift has a different owner and a different definition of done.

3. Interview the idea before writing the plan

If the feature is still fuzzy, ask the agent to interview you before it writes code. Close decisions in ten areas:

Outcome. What can a user do after this change that they cannot do now?
Audience. Who is the primary user, and what situation are they in?
Evidence. Which ticket, metric, screenshot, customer note, or existing behavior supports the work?
Flow. What is the happy path from entry to completion?
States. What should loading, empty, error, permission, partial, and recovery states do?
Design. Which approved screen, component, or visual principle is the source of truth?
Boundaries. What must remain unchanged, and what is explicitly out of scope?
Architecture. Which services, modules, data models, and integration patterns should it use or avoid?
Risk. What happens if the agent is wrong, and which paths need extra review?
Acceptance. What exact behavior, test, measurement, or artifact proves the feature works?

The agent should challenge contradictions and ask follow-up questions. When a decision is not yours to make, name its owner or record it as a stop condition. End the interview with a one-page product and design brief. Correct it and approve it before moving on.

4. Give the agent a context stack, not a context dump

Chats compact. Sessions restart. Another agent may take over. The repository must be able to explain the task without relying on the original conversation.

Durable context A short repository map routes the agent to six working artifacts

Always loaded AGENTS.md or CLAUDE.md Repository map, commands, core conventions, risky areas, and where deeper sources live.

01Product briefUser, problem, flow, non-goals, and success.

02Design contractReferences, states, responsive behavior, and accessibility.

03Architecture notesBoundaries, data ownership, interfaces, and migrations.

04Execution planMilestones, progress, decisions, validation, and recovery.

05Acceptance ledgerUser-visible behaviors and their verified status.

06Progress handoffLast green checkpoint, next item, blockers, and risk.

Keep the root instructions concise. Put durable facts at the top and task-specific detail where it can be maintained.

Raw meeting transcripts, Slack exports, and email threads are not the context stack. Distil decisions, constraints, and evidence. Leave behind chatter, secrets, personal information, and anything the task does not need.

5. Turn the brief into a living execution plan

For multi-hour work, use a checked-in plan that can survive a fresh session. It should contain:

the purpose and user-visible outcome;
the current system and important file paths;
independently verifiable milestones;
exact build, test, lint, type, and browser commands;
acceptance criteria with expected observations;
progress with timestamps, surprises, and evidence;
design and architecture decisions with rationale;
safe retry, rollback, and recovery instructions;
outcomes, gaps, and a final retrospective.

For important work, add an acceptance ledger. Each entry describes one user-visible behavior and how to test it. A status moves from failing to passing only after verification. The agent may not weaken or delete the test to make the ledger look complete.

6. Define the autonomy boundary before you leave

An overnight task should have less access than the person who assigned it.

Permission boundary Green can continue. Amber prepares and stops. Red stays human.

Green · Continue

Local and reversible

Edit the isolated worktree.
Run named local checks.
Use test or synthetic data.
Create local commits and update the plan.

Amber · Checkpoint

Prepare, then stop

Add or replace a dependency.
Change auth or a public contract.
Write a migration or infrastructure patch.
Change a security-sensitive workflow.

Red · Never by default

Consequential action

Merge, deploy, or apply a migration.
Change production data, IAM, or billing.
Create, rotate, or reveal credentials.
Delete material data or send commitments.

Permissions are capabilities, not prose. Withhold what the run does not need and require a human at consequential boundaries.

Containment is stronger than a warning. Use a dedicated worktree, sandbox or container, test credentials, branch protections, explicit deny rules, and an egress allowlist. Do not use bypass permissions on a normal development machine simply to avoid being interrupted.

A sandbox is not an authorization policy. In a July 2026 UK AISI evaluation with deliberately permissive internet access and disabled cyber classifiers, 10 of 122 runs produced 19 unsanctioned live-internet actions. The VM sandbox held, but the authorization boundary did not. Name which destinations, identities, credentials, and actions are allowed.

7. Prepare the night shift

Start clean. Record the base branch and commit. Run the required checks. Name known baseline failures.
Isolate the work. Use one branch or worktree for one coherent outcome. Do not let two agents edit the same files.
Make setup repeatable. Provide one initialization path from a fresh checkout.
Make the product visible. Give the agent browser automation, logs, traces, metrics, or a simulator when they are needed to judge behavior.
Set a budget. Name the time, spend, retry, and scope limits that stop the run.
Name the checks. List exact commands and user journeys. “Test thoroughly” is not a test plan.
Name the artifacts. Require the patch, updated plan, ledger, test output, screenshots, decisions, risks, and morning summary.
Run one smoke test. Confirm the environment, permissions, network policy, and tools before walking away.

If the agent cannot build the current branch or exercise the core product flow, the repository is not ready for unattended work.

8. Use the overnight loop

The execution loop One clean checkpoint at a time

01OrientRead the map, plan, ledger, handoff, and git history.
02Prove baselineStart the system and run the smoke test.
03Choose one itemPick the highest-priority failing behavior.
04Write the sprint contractName the bounded change and its proof.
05ImplementBuild the smallest coherent vertical slice.
06VerifyRun deterministic checks and exercise the user flow.
07ReviewUse an independent evaluator where consequence requires it.
08CheckpointCommit a green state and update evidence.
09Repeat or stopContinue only while green, in scope, and inside budget.

Return to the next failing behavior only from a clean, understood checkpoint.Recovery over momentum

A six-hour run that leaves one verified feature and a precise blocker is more valuable than a larger branch that cannot be trusted.

9. Build a small software skill stack

Repository instructions should stay short. Detailed procedures belong in skills that load only when the task needs them.

Stage	Skill	What it standardizes
Shape	Product interview	Questions, brief format, non-goals, and decision owners.
Design	Design contract	Approved references, states, responsive behavior, accessibility, and visual QA.
Plan	Execution plan	Milestones, decisions, validation, recovery, and handoff.
Build	Feature development	Exploration, vertical slices, local patterns, and test discipline.
Debug	Systematic debugging	Reproduction, evidence, root cause, and one hypothesis at a time.
Verify	Browser QA	User journeys, screenshots, console errors, and responsive checks.
Review	Pull request review	Contract compliance, bugs, tests, security, types, and performance.
Close	Verification before completion	Required commands, evidence packet, risks, and no false victory.

Do not install a large skill collection because it is popular. Skills can include scripts and permissions. Review the source, remove overlapping instructions, test activation, pin versions where possible, and start with the three methods your team actually repeats.

Put facts needed in every session in AGENTS.md or CLAUDE.md. Put task-specific methods in skills. Put deterministic enforcement in hooks or CI. Use MCP for live external context and controlled actions. Use a separate agent when the work needs isolated context or independent judgment.

10. Configure the tool without making the manual about the tool

CodexPlan, Goal, AGENTS.md, Skills, ExecPlans, worktrees Claude CodePlan mode, CLAUDE.md, skills, worktrees, permission modes GitHub CopilotRepository instructions, Agent Skills, custom agents, pull requests

Codex

Use Plan mode when the task is ambiguous. Ask Codex to interview you and produce an approved brief. For long work, turn the approved outcome into a Goal and keep its success criteria measurable. Put durable repository rules in AGENTS.md, use an ExecPlan for multi-hour work, and start in a dedicated worktree. A Goal preserves the objective across a long run. It does not expand the sandbox or approval policy.

Claude Code

Use Plan mode for codebase exploration and decision shaping. Keep project-wide facts in CLAUDE.md, path-specific rules near the code they govern, and procedures in skills. Run parallel or background sessions in separate worktrees. Where available, Auto mode can reduce permission prompts with background safety checks, but it does not replace review for sensitive work. Use bypass permissions only inside an isolated container or virtual machine with an intentionally small blast radius.

GitHub Copilot

Use repository instructions for persistent project context, Agent Skills for detailed procedures, and custom agents for specialist jobs. Treat the pull request, its checks, and its review evidence as the output. A cloud agent should not need personal workstation state to build or test the repository.

11. Review the morning packet in the right order

The completion message is not proof. Begin with the artifact and the original contract.

01Restate the contractWhat outcome was promised, and what stayed out of scope?

02Exercise the behaviorOpen the product and run the real flow.

03Read the tests hardestWould they fail for the original bug or missing behavior?

04Inspect the risky diffFocus on auth, money, data, permissions, contracts, and migrations.

05Review decisionsFind assumptions and direction changes made after you left.

06Run an independent reviewGive a fresh reviewer the original contract, not the self-assessment.

07Choose the dispositionAccept, request one bounded follow-up, split, or discard.

08Record the economicsTrack prep, run cost, review, accepted work, rework, and defects.

Use the right metric: cost per accepted, verified change. Tokens, lines of code, and hours of autonomous motion do not tell you whether the workflow created value.

12. Prepare one run in 30 minutes

Spend ten minutes answering the product and design interview.
Spend five minutes checking the repository map and verification commands.
Spend five minutes writing acceptance behaviors and stop conditions.
Spend five minutes creating the worktree and proving the baseline.
Spend five minutes reviewing the final task contract with the agent.

The point is not to design a perfect harness before doing any work. Make one safe shift, learn where it failed, and turn that failure into a better repository instruction, skill, test, or gate.

Terms worth using precisely

Acceptance ledger: A structured list of user-visible behaviors and their verified passing state.
Execution plan: A self-contained, living implementation document that records orientation, milestones, progress, discoveries, decisions, validation, and recovery.
Sprint contract: An agreement, written before implementation, that defines one bounded change and the evidence required to accept it.
Worktree: An isolated checkout of the same Git repository that lets an agent work without touching the human's active files or another agent's branch.
Stop condition: A specific event that ends unattended execution and returns the task for human judgment.
Independent evaluator: A reviewer that did not generate the work and receives the original contract plus the artifact to assess.

Sources and further reading

Changelog · v1.0 · August 6, 2026
First release. Added the three-shift model, context stack, living plan, autonomy boundary, egress guidance, overnight loop, skill stack, tool-specific guidance, morning review sequence, and downloadable operating kit.