AI shouldn't think for the first time while you sleep

Cover Image for AI shouldn't think for the first time while you sleep
OrcDev

OrcDev

AI shouldn't think for the first time while you sleep

Last time I wrote about paying $400 for $157,143 worth of tokens at API rates.

Here's one of the ways I actually spend them: while I'm asleep.

Most people do this wrong. They type "build this while I sleep", go to bed, and wake up to 40 changed files, a broken app, and a summary that says "done" as if that means anything.

That isn't a workflow. That's gambling.

AI can work while you sleep. It should not think for the first time while you sleep.

If the task is vague at midnight, it's chaos by morning. Everything that matters happens before you go to bed.

Here's the whole system.

1. Write plans, not prompts

I open Obsidian and make a separate note per piece of work. Landing page. Onboarding. Test coverage. Docs.

Every note has the same shape:

# Plan

## Goal

## Current Problem

## Scope

## Success Criteria

## Do Not Touch

## Open Questions

That structure is doing real work. It's not decoration. Each heading is a decision I'd otherwise be making at 2am through an agent that can't ask me.

A plan is a container for decisions.

2. Grill the plan before you trust it

I don't hand a fresh plan straight to an executing agent. I run it through grill-me first and tell it to attack: find the vague parts, the missing decisions, the risky assumptions, anything that would confuse whoever executes this.

That skill is Matt Pocock's, not mine - you can grab it at aihero.dev/skills-grill-me.

What does "done" mean? Which files are in scope? What must never change? How do we test it? What's the rollback? What should the agent do when it gets stuck?

Most plans sound good right up until someone has to execute them.

If a plan can't survive being grilled, it shouldn't run overnight.

3. Rewrite it into something boring

The original plan is allowed to be messy. The execution plan has to be boring.

Not this:

Make onboarding better.

This - and be techy about it:

Change our entire onboarding flow. Use $this library, it needs to look like onboarding from $this app. Use buttons and cards like we did it on $this project.

Clear enough that the next agent doesn't have to make big calls on its own. Flexible enough that it can still solve the problem.

The execution plan should remove decisions, not create new ones.

4. Hand it to a different agent

One agent helps me think. A different one executes.

The separation is the point. The planning agent should be creative and a little annoying. The execution agent should be disciplined and boring. Asking one agent to be both, in one long session, is how you get something that argues itself into a rewrite at 3am.

The handoff carries the objective, the plan, the exact files, the constraints, the test command, the output I want, and a stop condition.

That last one matters most. If the agent hits something risky or bigger than expected, I don't want it improvising for six hours. I want it to stop and write a note.

5. Run the plan of plans

The last step isn't a new idea. It's one goal that points at everything you already prepared.

Not "work on this all night." Closer to:

Execute the approved plans in the Obsidian folder, in order. Each plan carries its own scope and its own do-not-touch list. Commit nothing unless a plan says otherwise. After each plan, write a summary with changed files, tests run, failures, and open questions.

Notice what isn't in there: no list of forbidden files, no constraints. Those already live in the plans. That is what the first four steps bought you.

Enough room to work. Not enough room to wreck the project.

Pick tasks that are easy to review

The best overnight tasks aren't the most ambitious ones. They're the ones where review is cheap.

Good overnight work: research a subsystem, add test coverage, build a prototype behind an experimental route, improve docs, audit UI states, prepare a refactor plan, hunt for duplicate code, generate examples.

Bad overnight work: production deploys, payment changes, auth rewrites, database migrations, anything touching secrets, huge refactors - anything that's hard to review in the morning.

Overnight AI should create reviewable progress, not irreversible consequences.

The morning is still your job

Read the summary. Check which files changed. Read the diff. Run the tests yourself. Check whether it touched anything you said was off limits. Look for new dependencies. Then decide what to keep, what to rewrite, and what to throw away.

If you can't review it quickly, the run wasn't scoped tightly enough.

The agent does the night shift. You still do the review.

One thing to actually do this week

Take the most boring, most reviewable task you have. Test coverage on one file. A report on where your codebase repeats itself.

Write the plan tonight. Grill it. Scope it. Set the goal before bed.

Then judge the whole thing by how fast you can review it in the morning - not by how much it changed.

This sounds like more work than just prompting. That's the point. The work you do before sleep is what decides whether the agent is useful while you're asleep.