"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.
In this article I want to share the operating model I have built up to make this style sustainable. None of this 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.
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, automatic retry on backend overload. Running unattended for hours, I used to discover in the morning that a transient error had quietly stopped things. Since intermittent overloads started retrying automatically, those "silently stalled" mornings have grown rarer.
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.
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. Use Antigravity as a partner, but maintain the distance that keeps you from being absorbed by the partner. That distance 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 feel a morning review finish in 30 seconds, 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. Thank you for reading.