How to Get AI Solving Problems For You While You Sleep
July 15, 2026 · Ryan X. Charles
You write down what “solved” means. You walk away. In the morning the issue has a plan commit, a result commit, tests that ran, and a second agent that tried to kill the work before it landed.
That is the product of a habit, not a vibe session.
We run that habit at Astrohacker as Issues and Experiments (InE). It is how we ship small brand fixes in an afternoon and how we keep multi-day engine and release work coherent when no human is mid-loop. This is not a pitch for a new coding model. It is a way to get the agents you already use—Codex, Claude Code, Grok, Cursor, and friends—to keep solving defined problems without you babysitting the chat.
If you want the original lifecycle manifesto, read Building Software While You Sleep. This post is the field guide: same loop, different diameters, any harness, and a workbench that matches the idea.
The only job that is still yours
You do not “prompt harder.” You specify.
An issue that can run overnight needs three things written down before anyone types code:
- Goal — one coherent outcome, not a wish list.
- Verification — commands and observations that would convince a skeptic the goal is met.
- Guardrails — what is out of scope, what must stay honest, what must not be rewritten.
Once that exists, solving becomes mechanical enough that an agent can own the middle of the loop. You are not the implementer. You are the person who made “done” falsifiable.
Issues and Experiments, one screen
Issue — a folder with a README: goal, verification, constraints, status. Durable. In git. Not a Discord message.
Experiment — one decision-complete step toward the goal. Design it. Get it reviewed. Commit the plan. Implement only then. Verify. Record Pass / Partial / Fail. Get the result reviewed. Commit the result. Then design the next one.
You never list experiment 1 through 12 up front. Experiment N’s result is what tells you what N+1 should be. Failure is not drama. It is information.
Adversarial review — a second agent, cold context, preferably a different harness when you can. Design review before implementation. Completion review before the result commit. Marking your own homework is how slop ships overnight.
InE is not a coding tool. It does not replace Codex, Claude Code, Grok, or Cursor. It is the honesty and progress layer those tools plug into. The agents write the code and run the tests. The issue file owns the truth.
Same loop, different diameter
The machine does not change when the problem shrinks or grows. Only the diameter does.
Hours. Restore a slogan, fix a CLI identity leak, close a one-surface copy
mistake. One experiment. Still: design review, plan commit, implement,
test:whatever that actually gates the claim, completion review, result commit.
Small work with real positioning risk does not get a free pass because it is
“just marketing.”
Days. Multi-engine parity, release restoration, long host work. The issue
stays open. Experiments stack. Sessions end and restart. What survives the night
is not a 40-turn chat transcript—it is the issue README, the experiment files,
and the commits that mark plan vs result. Morning context is git log and a
markdown notebook, not “remind the model what we were doing.”
That is why sleep works. Resume is reading the record, not re-explaining the universe.
Two receipts
Multi-day: work that refuses to fit in one sitting
We have used InE on terminal and engine work that spans multiple days: open
issue, clear “done,” experiments that cannot all be designed on day one because
day one’s failures rewrite day two. Orthogonal review keeps implementers from
drifting when the human is offline. The proof is in the issues/ tree and the
commit history—not in a slide about “AI productivity.”
What would break without the loop: scope expands every time an agent hits a wall; “almost works” gets declared done; the chat that held the plan dies with the session.
Small: still specify, still review
We have also used the same shape on problems that take a single afternoon—brand and site copy, install surface honesty, slogan and title lines that must match what we actually market. One decision-complete experiment. Same dual review. Same two commits.
What would break without the loop: a “quick” agent edit that leaves canon, homepage, and CI disagreeing—or a short slogan that sounded fine until you remembered why the long form existed.
Tiny diameter. Same machine.
Use any coding harness
InE does not care who wrote the patch.
- Implementer — Codex, Claude Code, Grok, Cursor, whatever is sharp today.
- Reviewer — a cold second look; a different harness when you can (orthogonal review). Fresh context matters more than brand loyalty.
- System of record — the issue and experiment files in the repo.
Swap models next month. The issue still closes the same way: verification passes, reviews pass, commits exist, status flips to closed.
If your process only works inside one vendor’s chat product, you do not have a process. You have a subscription.
Anti-patterns (steal these as rules)
- Designing a long experiment list before the first result exists.
- Skipping design review “because it’s small.”
- Treating chat as the system of record.
- Combining plan and result into one commit.
- Expanding scope when an experiment fails instead of writing what you learned.
- Declaring victory without the verification commands you wrote when you were sober.
When not to bother
Do not open an issue for a typo with no risk.
Do not automate pure exploration until you can say what “done” means. First write the goal. Then open the issue. Then sleep—or don’t, but at least the machine knows the target.
The workbench we run it in
If the loop is harness-agnostic, the host should not lock you to one chat window and a separate browser.
Astrohacker Terminal is the native app we use for that work: a serious terminal host with multiple real browser engines and multiple profiles in the same window, plus the shell, editor, and web tools that ship in the same install. Run the coding agents you already use—Codex, Grok, Claude Code, Cursor, and friends—next to real web panes, not in a pile of unrelated apps.
InE is still the method. The Terminal is the place the method lives when agents need a shell and a browser at the same time.
Apple silicon, Homebrew:
brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker
Steal the process even if you never install us. Install us if you want the workbench built for the same idea.
Set the goal. Let the agents iterate. Wake up to receipts.