I am Masaki Hirokawa, a solo indie developer running multiple products and side businesses. The biggest change since I started using Antigravity is that I now have a coworker who is awake while I sleep. I go to bed, and by morning either an implementation has progressed or a review-ready candidate is sitting on a branch. As a one-person operation, that change has been quietly transformative.
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 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 company.
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.
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.
Naming the line you do not let the agent cross
Finally, 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.
Antigravity Lab publishes premium articles that go deeper into "operating models for solo developers" with specific case studies. Membership covers an ad-free reading environment and helps fund the running costs across our four labs (Cloudflare, Stripe, domains). If this article was useful and you would like to support more like it, the membership invitation at the end of the page is the best place to start. It really keeps me writing.