Can an AI Coding Agent Work Overnight? A Plain Guide

Can an AI coding agent work overnight while nobody is watching? Yes. Tools like Claude Code can carry a long task through on their own. But an unattended run is only as good as the setup you leave behind, because when you are asleep nobody notices a wrong turn and nobody corrects it.

This guide explains, without code, what changes when you are not in the room, and the five questions to answer before you leave an agent running.

Why is an unattended run different?

When you watch an agent work, a missing piece of context is cheap. It misreads your request, you see it within a message or two, and you say so.

Claude Code's own best-practice guide describes the difference well. In a run you started before going to bed, nobody tells the agent, and you find out the next morning that it spent the whole night building on the wrong assumption.

So the goal is not to make the agent smarter. It is to move the checking from your eyes to something that keeps working while you are away. The same guide lists five questions to go through before you leave a task running on its own. They make a good checklist for any manager, not only engineers.

What are the five questions before you walk away?

1. Does it know what "done" looks like?

"Improve the checkout" is not a finish line. "A customer can pay with a saved card, and these three test cases pass" is.

Claude Code's guide suggests a written goal, a spec file (a short document describing what to build), or a failing test the agent has to turn green. OpenAI's Codex guide says the same in other words: state what should be true before the task is complete, such as tests passing or a bug no longer reproducing. For complex or unclear work it advises asking for a plan before any code is written.

If you are not sure what to write, you can ask the agent to interview you first. Claude Code's guide shows a prompt that asks it to question you until it could write a spec, then save it to a file. A fresh session can then build from that written definition of done.

2. Can it check its own work?

The guide puts it plainly: Claude stops when the work looks done. If it has nothing to run that says whether the work really is done, "looks done" is all it has. In practice that makes you the test suite.

Give it something that comes back pass or fail. That can be automated tests, a build that must succeed, or a screenshot compared with the design mockup. Then the agent can make a change, run the check, read what broke and fix it, without you.

Checks come in different strengths:

• The agent decides for itself when it is satisfied. Easy, but the weakest.
• A written goal that a separate model checks after every turn.
• A rule enforced by the tool itself, so the agent cannot end its turn until a check passes.
• A reviewer who did not write the code, such as a fresh review pass that never saw the original conversation.

Ask for evidence, not reassurance. "All tests pass" on its own tells you very little. The command that was run and its output, or a screenshot, tells you much more. For a session you were not watching, the guide notes, it is the only evidence you have.

3. What is it allowed to touch?

An agent working alone should be fenced in. The guide names permission rules, a sandbox (a restricted area the agent works inside), a separate copy of the code to work in, and a single branch (a separate line of changes) that it may push to.

For a non-coder, the question to ask your engineer is simple: if this run goes wrong, what is the worst thing it can reach? Production data and live customer systems should not be on that list.

4. What stops it?

Every unattended run needs a ceiling. The guide names a limit on the number of turns and a limit on spend. Without one, a confused agent has no reason to stop. Think of it as a budget for a contractor: not because you expect trouble, but because "open-ended" is not a plan.

5. Where does the result go, and who signs off?

The result should land somewhere a person can read it: a proposed change awaiting review, a comment, or a summary. Then a person approves the merge (adding the change to the main code), the release, or anything else you cannot take back. OpenAI's guide likewise advises reviewing the diff, meaning the exact lines changed, and checking it for bugs, regressions and risky patterns before you accept it.

Claude Code's guide sums up the split. Once a run is going, the agent will carry a long task through on its own. What stays with you is starting it, deciding what "done" means this time, and approving the merge at the end.

Does it have to be overnight?

No. "Unattended" just means you are not watching each step. It might be a lunch break, a long weekend, or a task that starts on a timer or when something happens, such as a failed check on a proposed change.

The guide has a warning for scheduled tasks that applies to everyone. Before you leave one running in the cloud, protect your main code line with a rule the task cannot bypass. And watch the first few runs of anything new before you trust it alone.

What can go wrong, and what does it look like?

Here are common failures, in plain terms:

• A wrong assumption carried all night. The agent guessed what you meant and built a lot on it. A clear definition of done and a written spec reduce this.
• A check that checks nothing. If the test is weak, "pass" means little. Ask what the check actually covers.
• A run that never stops. A turn or spend limit addresses this.
• Reaching too far. Limiting what the agent can touch addresses this.
• Work nobody reads. A pile of changes merged in the morning without review is the same risk as before, only faster.

One more point from Claude Code's guide: a "never do X" line in an instruction file is a guideline, and the agent is allowed to decide a guideline does not apply. The guide says such lines are followed almost every time, not every time. If something must happen every time, it should be enforced by the tool's settings rather than left to the agent's judgment. Ask your engineer which of your rules are enforced and which are only requested.

Try it small first

The guide's advice for scripted runs applies to managers too: try it on a few items first, see what goes wrong, fix the prompt, then run the rest. Do not make your first unattended run the one that matters most.

A sensible first overnight task has a clear finish line, touches little, and is easy to undo. A small bug with a written test is a good candidate. A change to payments is not.

How does Atlas handle unattended work?

Atlas is a team of AI engineers built on Claude Code, and several of these questions are built into how it works. "Done" is enforced: a task cannot be completed until the work is on the main code line or queued to land there, a screen has its test cases and screenshots, and the product's rules pass. An optional daily budget warns at 50% and 80% and pauses the team at 100%. Production go-lives, spending, deleting data and sending anything outside are never decided for you. On a company server, the team keeps working with the laptop closed. You can read more on the Atlas home page.

A single checklist that shows all five answers before you leave is coming to Atlas, built in, so it needs no setup on your side. Until then, you can ask PA, your project assistant, the five questions above in plain words before you step away.

Conclusion

An AI agent can work while you are away, and that is where much of the time saving comes from. But "unattended" is a setup you design, not a switch you flip. Before you leave, make sure it knows what done means, can check itself, has a fenced area, has a ceiling, and hands its result to a person. Start with a small, reversible task, read the evidence the next morning, and widen the scope only as trust is earned.