# how to use coding agents overnight without waking up to a mess

2026-10-01, updated 2026-10-01

By Jawad Jalal. Founder of Wayari. Builds the desktop app and its coding-agent workflow.

A practical way to give a coding agent work for the night, with a clear finish line, safe boundaries and a pull request you can review in the morning.


give an agent a job that can finish without you. that means a reproducible starting point, a boundary it cannot guess and a check that tells you whether the change held.

leaving work running overnight is not the same as asking for a large change before bed. the useful job is small enough to review in the morning and complete enough that the agent does not need to make product decisions on your behalf.

## what should run overnight?

pick work with a known shape. a failing test, a repetitive migration, a well-scoped UI bug or a feature whose acceptance check already exists are good candidates.

"investigate why the invoice export fails for empty reports, make the smallest fix and add a regression test" is a night job. "make billing better" is not. the first request gives the agent a route through the repository. the second asks it to choose the destination.

if a job needs a policy decision, make the decision first or ask for an investigation only. an agent can find where proration is calculated. it should not decide your proration policy while you are asleep.

## what needs to be in the request?

include three things:

1. the observed failure or desired behaviour
2. the boundary around the change
3. the evidence you expect back

for example:

> On the report page, exporting an empty filtered result should download a valid CSV with headers. Keep the current export library and response shape. Reproduce the old failure, add a regression test and open the page to download the file.

the boundary matters because it prevents a plausible fix from becoming a replacement project. the evidence matters because a green summary is not the same as proof that the person-facing flow works.

## where should the agent work?

give the job its own branch and worktree. that keeps an overnight formatter, dependency install or partial edit away from the files you are using during the day.

Wayari creates isolated work for each builder, then brings the result through one channel branch. that makes the morning review simpler: you read one pull request at a known commit instead of reconstructing several terminal sessions.

the isolation does not remove design conflicts. if two agents both need the same central type or route registry, let one own that seam. a quiet dependency is still a dependency at midnight.

## when should the agent stop?

set a time or cost cap, but set a finish condition too. a useful finish condition is not "keep trying." it is "the gate passes, a separate reviewer has read the diff and the pull request is ready."

if the build, tests or browser check fail repeatedly, the job should leave a note with the failure and stop. a stopped job with evidence is easier to continue than a job that has spent the night changing unrelated code to satisfy a broken environment.

## what should be waiting in the morning?

you want a pull request with the goal, the changed files, what ran and any remaining uncertainty. read the acceptance check beside the diff. then repeat the most important person-facing action in the running app.

the point of overnight work is not to remove your judgement. it is to move the slow, mechanical part of the loop while you are away, so your morning begins with a concrete decision.

For a runnable starting point, use [the coding-agent brief guide](/blog/how-to-write-a-brief-for-a-coding-agent). Review the result with [the pull request checklist](/blog/how-to-review-an-ai-generated-pull-request). Read [the workflow documentation](/docs) before starting a job.


[HTML version](https://wayari.com/blog/how-to-use-coding-agents-overnight)