The best workflow is not the one that looks the most impressive while you are staring at it.
It is the one that keeps going when you stop staring at it.
If you run coding agents, research loops, remote servers, CI babysitting, training jobs, or data pipelines, you already know the pain: your laptop sleeps, your SSH session dies, your browser tab disappears, your remote machine becomes annoying to reach, and suddenly your “automation” turns back into manual labor.
That is the real productivity bug.
You should be able to get up, go outside, eat hotpot, and come back later without your whole workflow collapsing.
This post is about how to do that.
Unlock the Full Potential of Your Computer
For your computer to behave less like a fragile houseplant and more like a reliable coworker, you would need these:
- keep work alive by shamelessly forcing your laptop to stay awake
- let you reconnect from anywhere, including hotpot, the airport, and other places where productivity should not legally exist
- recover gracefully from failures like disconnects, server crashes, earthquakes, tsunamis, and whatever else the universe throws at your terminal
- reduce the amount of terminal babysitting you have to do before you become your computer’s full-time nanny
Once that foundation is in place, agents can stop acting like babies that need constant babysitting and start becoming reliable coworkers.
1. How to Build a Computer That Doesn’t Need Babysitting
A. Prevent Sleep / Interruptions
If you want your computer to keep running until it dies, the first cruel thing you have to do is stop it from sleeping.
You do not want your setup to be “mostly automated except when the laptop quietly naps.”
That is not automation. That is gambling.
caffeinate and pmset
On macOS, these are the two commands you want.
Use caffeinate when you want to keep the machine awake right now.
caffeinate
Use pmset when you want to disable sleep more permanently.
sudo pmset -a sleep 0
B. Keep Sessions Alive
If you are still running important remote work in a normal shell, you are living a little too dangerously.
tmux
tmux is what turns “my SSH session died” into “doesn’t matter.”
It lets your work keep running on the server even when your laptop sleeps, your Wi-Fi disappears, or you decide to go be a person for a while. Your coding agent, logs, training job, and shell session keep going without throwing a tantrum.
That means:
- your work lives on the server, not inside one fragile SSH window
- you can reconnect later from another laptop or your phone
- your jobs, logs, and shells keep going without drama
The commands you actually need are:
tmux new-session -t <SESSION_NAME> # create a named tmux session
adal --yolo # run AdaL autonomously so you can disconnect safely
tmux attach -t <SESSION_NAME> # come back later and reattach
C. Reach Your Machines from Anywhere
Unless you have already secretly built an army of superintelligence, you probably still want to check on the progress whenever and wherever. Remote access is essential for that.
Termius
Termius is extremely useful on Android and iOS when you just need to check something quickly.
You are outside. You are away from your laptop. A job may have failed. A process may need a restart. You want to reattach to tmux, inspect logs, or kick off one command.
That is where mobile SSH becomes surprisingly valuable.
You do not need to do full development from your phone. You just need enough reach to avoid being blocked by not having your laptop nearby.
And that alone saves a lot of friction.
Chrome Remote Desktop and RustDesk
Sometimes terminal access is not enough.
If you need a browser session, a GUI tool, or a full desktop, these are the two obvious options. Chrome Remote Desktop is the simpler “just get me in” choice. RustDesk is a good alternative if you want something lighter.
Both also work on Android, which makes them useful when you need to quickly poke at a machine from your phone.
2. How to Build Agents That Don’t Need Babysitting
Now that we’ve turned our computer into a 24/7 worker under constant surveillance, we can now set up the agents that are running on top of the computer.
A. CLI Tools That Agents Can Use
If you want agents to actually do things instead of just talking about them, CLI tools matter a lot.
gh CLI
This gives the agent a clean way to inspect PRs, check CI, read issues, review branches, trigger workflows, and manage GitHub without living in browser tabs.
brew install gh # install GitHub CLI
gh auth login # authenticate this machine with your GitHub account
gh pr status # show PRs tied to your current repo/account so you know GitHub access is working
gws-cli
This does the same thing for Google Workspace-style workflows like email, docs, sheets, and other operational chores that are annoying to keep doing by hand.
brew install googleworkspace-cli
gws auth setup # walks you through Google Cloud project config
gws auth login # authenticate with Google through OAuth
gws drive files list --params '{"pageSize": 5}' # list a few Drive files to confirm auth and Drive access are working
Normally, coding agents ask for permission before using tools like these. AdaL’s --yolo mode does not ask anything — it just runs with full autonomy, which means you do not have to keep pressing Enter every time the agent wants to do something. You can let it run and go out for dinner instead of babysitting it.
adal --yolo # runs with full autonomy and does not ask for anything
B. Cron Turns Agents Into Restless Workers
AdaL’s /cron feature is where things get fun.
Instead of asking the agent once and then babysitting it, you can tell it to keep checking, fixing, resuming, reporting, and updating things.
Here are some of the most fun examples.
a. PR babysitting, except you are no longer the babysitter
/cron 1m check github action CI build status of this PR.
if CI is running, do nothing.
if test failed, fix and push.
if test passed, merge PR.
This is for when you are spiritually done with refreshing GitHub Actions every 40 seconds like a lab rat hitting a button for food.
Instead of watching checks, waiting, fixing, pushing, and watching checks again, you let the agent do the whole miserable loop for you.
b. Training runs that refuse to die politely
/cron 30m check the training progress and checkpoint using wandb cli.
if there's a problem, fix it and resume training.
when the validation ckpt of epoch 3 has been saved, stop training and download checkpoint.
after you downloaded checkpoint, convert and upload to hf,
and evaluate the checkpoint with eval.sh simultaneously.
report eval result to my email
This is what you use when your training job behaves like a dramatic Victorian child and needs constant supervision.
Instead of checking W&B, resuming runs, downloading checkpoints, uploading to Hugging Face, and kicking off evals yourself, you let the agent suffer through all of that.
c. Literature review that keeps moving while you are eating
/cron 24h check recent research that is related to @PROBLEM_STATEMENT.md.
if there is something relevant and missing in @RELEVANT_RESEARCH.md,
add the research.
This one is for researchers who are tired of pretending they will “check recent papers later.”
The agent just keeps scanning for new work, compares it against what you already have, and adds what is missing — like a very obedient research assistant that never asks for coffee.
Final Thought
A good workflow should not collapse because you left your desk.
It should keep going when you go outside, switch devices, lose Wi-Fi, or sit down for dinner.
That is the standard.
First, build the environment that makes continuous work possible.
Then let agents sit on top of it and do the repetitive parts for you.
That is how you stop babysitting computers.
And that is how your computer keeps working while you eat hotpot.