Hand over one task before bed, and by morning it is sitting on a branch. Since I folded Antigravity into my solo development, that nightly hand-off has become part of daily life. Days go to design and direction; a slice of the hands-on work is entrusted to the night agent. That is the rhythm.
But night-shift operation breaks the moment you get sloppy. I have woken up to hours of misguided changes piled onto a branch because I handed over a vague task before going to bed. To make Antigravity into a real "second engineer," you have to draw lines as deliberately as you would when onboarding a new human teammate.
What follows is the operating model I have built up to make this style sustainable. None of it is in the official Antigravity documentation — it is the lived reality of running an agent overnight as a one-person operation.
Why the "second engineer at night" framing matters
If you look at Antigravity purely as a feature surface — agent manager, hooks, settings — it gets overwhelming fast. At some point I switched lenses: I decided to design as if I were hiring a person. Specifically, I treat Antigravity as a junior engineer who will work the night shift, and I draw the lines accordingly.
The reason this framing works is that every operational question becomes intuitive. You wouldn't hand a brand-new night-shift engineer permission to deploy to production on day one. You wouldn't, either, with Antigravity. For the first few weeks I used it, the agreed-upon rule was: Antigravity may commit to branches, but pushing to main is something morning-me does manually after review.
Just by adopting this lens, the operational decisions around Antigravity become surprisingly intuitive. Before any technical configuration, I strongly recommend you adopt the same lens.
Drawing the line on what can be handed over at night
After roughly six months of running this model, the shape of "tasks I can hand over overnight" has settled into something concrete.
Tasks safe to hand over at night:
- Tasks where the spec is fully expressible in words
- Tasks where rolling back is cheap if it goes wrong
- Tasks with an observable completion condition (tests pass, a specific file is generated, etc.)
Tasks not safe to hand over at night:
- Tasks where the spec is "roughly something like this"
- Wide-impact refactoring
- Tasks with side effects on production data
The important nuance here is that the dividing line is not "complex vs simple." It is "ambiguous vs precise." A complex task with a fixed entry and exit point is fine. A simple task framed as "try it and tidy it up if it works" is almost guaranteed to bite you in the morning.
When I'm preparing a night-shift task, I ask myself one question:
Can I, in 30 seconds the next morning, decide whether this task is done?
If I can't answer "yes" instantly, the task isn't ready to hand over.
The minimum task brief
When I hand a night-shift task to Antigravity, I write a brief in this minimum format:
## Goal
Why are we doing this task? (1–2 lines)
## Done condition
- An observable condition I can check in 30 seconds in the morning
- e.g. these tests pass / this file is generated
## In-scope surface
- Directories and files the agent may touch
- Areas that must not be touched (production code, billing, auth, etc.)
## Failure behavior
- Do not stop in a half-done state. Branch off, save the work, then stop.
- Do not touch main / production.
## Context to read first
- Related docs, location of existing implementations
It is just five sections, but writing them with care is what makes overnight operation stable. In particular, "in-scope surface" and "failure behavior" — make these explicit and the probability of unpleasant surprises in the morning drops sharply.
For a while I skipped this and just wrote one-liner tasks. After enough mornings of misguided changes, I converged on this five-line template. Even when it feels redundant, filling in all five is faster overall.
A real night task I handed over
Abstractions are hard to picture, so here is one task I handed over recently.
The job was to organize onboarding copy into locales/ JSON across three languages (Japanese, English, Chinese) and fill in the missing keys. The brief: the goal is "line up i18n keys across three languages"; the done condition is "pnpm test:i18n goes green"; the in-scope surface is locales/ and the matching type-definition files only, with no touching of implementation code under src/; on failure, branch off and stop.
In the morning I opened only the worklog and the diff. Fourteen files changed, tests green, and everything touched stayed inside the scope I named. I confirmed all of that in 30 seconds and moved on without reading a single line in detail.
Had I instead handed it over as "make the onboarding copy multilingual, nicely," the agent would have reached into implementation code, and morning-me would have been re-reading the entire diff. Same feature — whether you can fix the entry and exit points in words is what decides if it is a night-safe task.
Pre-set the stop conditions
Something easy to miss is that you should pre-set stop conditions. Antigravity will try to run a task to completion, but on long sessions the precision of its judgment can drift. I bake stop conditions in, like:
- More than 30 changed files? Commit what's there and stop.
- Same test failing three times in a row? Stop and leave the log.
- About to touch a directory that's out of scope? Stop immediately.
These are written into the task brief, or pinned in the agent's rules. Saying "do your best" is far weaker than saying "stop the moment you cross this threshold." The latter actually produces a calmer night.
It is the same lesson that applies to a junior teammate. "Tell me if anything is unclear" works less well than "if you cross this specific threshold, ping me." Defined edges are what make the night shift run smoothly.
A five-minute morning review
For night-shift operation to remain sustainable, the morning review has to be light. If reviewing takes 30 minutes every morning, the model collapses. Here's the structure I use to keep it under five minutes.
The first thing I open in the morning is the agent's worklog and the branch diff. Before I read any code, I look at three things:
- Is the done condition satisfied? (the 30-second check from the brief)
- Did the touched files stay inside the in-scope surface?
- Did any stop condition fire?
If all three are clean, I move to the next step without reading the code in detail. If any of them is off, I either drop the branch entirely or step in to manually fix.
The order — "judge by metadata first, then read code" — is what compresses the morning. It is not because I distrust Antigravity. It is because I do not want to re-validate trust from zero every single morning.
Hand the three-point check to a script, not to your eyes
There was a stretch when I ran those three checks by eye every morning. The trouble is that a half-awake eye is most lenient on exactly the second check, the scope. I once missed a single file in src/i18n/, right next door to locales/ — and I only learned about it midweek, when a user pointed out the layout it had broken.
Since then, the three-point check lives in a short shell script. The brief's "done condition," "in-scope surface," and "stop conditions" become the script's arguments, more or less verbatim.
#!/usr/bin/env bash
# morning-check.sh — the morning three-point check for a night task
# Usage: ./morning-check.sh <branch> <worklog> "<done-condition command>" <allowed paths...>
# e.g.: ./morning-check.sh agent/i18n-keys .agent/worklog.md "pnpm test:i18n" locales/ types/i18n.d.ts
set -u
BRANCH="$1"; WORKLOG="$2"; DONE_CMD="$3"; shift 3
ALLOWED=("$@")
NG=0
# 1. Done condition (run the 30-second command from the brief, as written)
if git checkout -q "$BRANCH" && bash -c "$DONE_CMD" >/dev/null 2>&1; then
echo "✅ 1. done condition: $DONE_CMD"
else
echo "❌ 1. done condition not met: $DONE_CMD"; NG=1
fi
# 2. Scope (every file changed since main must start with an allowed path)
while IFS= read -r f; do
ok=0
for p in "${ALLOWED[@]}"; do [[ "$f" == "$p"* ]] && ok=1 && break; done
if [ "$ok" -eq 0 ]; then echo "❌ 2. out-of-scope change: $f"; NG=1; fi
done < <(git diff --name-only "main...$BRANCH")
[ "$NG" -eq 0 ] && echo "✅ 2. all changes inside allowed paths ($(git diff --name-only "main...$BRANCH" | wc -l | tr -d ' ') files)"
# 3. Stop conditions (a STOP: line in the worklog means the agent halted on purpose)
if grep -q '^STOP:' "$WORKLOG" 2>/dev/null; then
echo "⚠️ 3. a stop condition fired:"; grep '^STOP:' "$WORKLOG"; NG=1
else
echo "✅ 3. no stop condition recorded"
fi
exit "$NG"The STOP: line in check three only works if you ask for it. Add one sentence to the brief's "failure behavior" — "when you stop, write STOP: <reason> as a line of its own at the start of the worklog" — and the agent will keep to it. It is not prose for a human to read; it is one line for grep to find. Whether that sentence is in the brief is what moves the morning verdict from eyeballs to a machine.
When the script exits 0, I move on without reading the diff. Only on a morning that ends in 1 do I sit down and read properly. What I read in the morning is not the code; it is the exit code. Since drawing that line, a review that runs past five minutes has become rare.
One more note: the scope check leans on git diff --name-only rather than on the list of files the agent says it touched. Logs get forgotten. Diffs do not.
Version updates changed how I hand off the night
Night-shift operation has been helped along by Antigravity's own updates. Three that mattered:
First, message queueing (2.3.0). You can now stack the next instruction while the agent is still working, so a night-time queue of "second task after the first finishes" can be loaded up before bed. Anything urgent jumps in with Send Now. It fits naturally when you want several tasks worked through in order overnight.
Second, how transient errors are handled. Running unattended for hours, I used to discover in the morning that a temporary error had quietly stopped things. Automatic retry on backend overload made those mornings rarer, and 2.14.0 (2026-09-15) went further: a single service error used to end the session outright, and it now retries with roughly twelve minutes of backoff. A "silently stalled" morning has become unusual for me.
Third — unglamorous but real — the fix to the token-accounting bug. Long runs used to hit the ceiling earlier than expected, which was one reason a night queue would stall midway. With that corrected, consumption estimates are more honest, so it is worth re-measuring how many tasks you can stack in a night.
And one change that anyone driving night tasks from the CLI should not skip: with CLI 1.2.6 (2026-09-18), the default timeout for headless runs (-p) went from five minutes to unlimited, and the exit code on failure changed from 1 to 3. If your night pipeline branches on $? -eq 1, a failed night may greet you in the morning looking like a success until that line is fixed.
None of these are flashy features, but under a "run it unattended" assumption they matter more than their size suggests. Before you build out a night queue, it is worth confirming your environment is on the latest build.
Naming the line you do not let the agent cross
What makes Antigravity sustainable as a long-term partner is being explicit about the line you do not let the agent cross. In my case, those lines are:
- Decisions that shape product direction (pricing, audience, concept)
- Reviewing code that touches billing, auth, or personal data
- Pulling the trigger on releases and production deploys
- Writing down the project's domain knowledge (the act of putting it into words has value in itself)
I deliberately keep these out of agent territory, even though some are technically delegable. The reason is that doing them myself preserves my "eye" as an indie developer. I want Antigravity as a partner, and I want to keep the distance that stops me from being absorbed by the partner. That distance, I have come to feel, is the long-term key.
Inversely, anything that does not fall on this list, I hand over to Antigravity without hesitation. When the boundary is sharp, both sides — the one delegating and the one being delegated to — can act with confidence. It is no different from how good human collaborations work.
What changed after six months
What has changed for me after six months of this model is the rhythm of building things. Days are for design and direction. Nights are for Antigravity's hands. Mornings are a short review where we re-converge. Once that rhythm settled, the feeling that "I can run multiple products in parallel as a solo dev" stopped being aspirational and started being real.
Another thing changed too: I now articulate what I am building, more often, to myself. To hand a night task to Antigravity, I have to write a brief. To write a brief, I have to pin down the goal. Doing that every day, the resolution of my own creative direction sharpens. That was an unexpected side effect.
If you want to try night-shift operation, I'd suggest not handing over a big task first. Take one small task that is cheap to undo, distill it into the five-line brief, and entrust it for a single night. Once you have seen morning-check.sh above exit 0 for you, the shape of what you can hand over starts to come into focus in your own hands.
I am still refining the model myself, but the quiet reassurance of a night hand-off clicking into place has changed the landscape of solo development for me in a real way. If it lightens even one of your nights, I will be glad you stayed with me this far.