I Tied a Remote Shell, an AI Agent, and an IRC Bot Into a Single Autonomous Workflow. Here’s How.

I used to feel chained to my terminal. Run the big integration suite, sit there while it churns, hope nothing breaks, then decide if I'm free to step away. Even a "quick" overnight run meant my laptop fan would be the soundtrack to my sleep, and I'd wake up hoping the session didn't drop.

That's reactive coding. You wait on your machine instead of letting the work happen while you're off doing something better. The fix is simpler than you might think: a remote shell that never sleeps, a tiny IRC notifier, and optionally a CLI coding agent that can attempt fixes when things go sideways. I'll walk through the exact setup so you can stop babysitting your dev loops.

Why remote shell plus IRC beats staring at a terminal

The key is moving from a pull model (you check logs) to a push model (the system tells you). A persistent remote shell is the natural host: it stays online, can pull your latest code, run a test suite, and send a status message without ever touching your local machine. IRC is the ideal notification channel because it's dead simple, works on any phone client, and doesn't require a webhook receiver or an API token. A one-liner bash function can push a message straight into a channel. The whole thing is text, so you can scroll back through a history of runs while you were away.

Step 1: Lock down a persistent Linux shell

You need a shell that doesn't time out when you close your laptop. Any VPS works, but xShellz explicitly sells always-on remote shells, so you don't have to mess with tmux keepalive hacks or cloud init scripts. They also bundle IRC bouncers and a CLI coding agent called borg, which will matter later. For this post I'll assume a standard Ubuntu-like environment, but the commands are portable.

Once you have the box, ssh in and clone your project. Install whatever test runner you use (pytest, go test, npm test, etc.) and confirm you can run the full suite manually. This remote workspace is now the execution engine; your laptop is just the observer.

Step 2: Turn IRC into a notification backplane

I wanted a notification that lands in my pocket without any new software. IRC is always on my phone (I use the xShellz bouncer to keep history, but any client works). To send a message from a shell script, you just open a TCP connection and speak the IRC protocol. Here's the simplest function I know, using netcat:

irc_msg() {
  local server="irc.libera.chat"
  local port=6667
  local nick="builder42"
  local channel="#my-builds"
  local message="$1"

  ( echo "USER $nick $nick $nick :CI bot"
    echo "NICK $nick"
    echo "JOIN $channel"
    echo "PRIVMSG $channel :$message"
    echo "QUIT"
  ) | nc -q 5 "$server" "$port"
}

Drop this into your shell's profile. Test it with irc_msg "Tests passed, 42/42". That's it. Now any script can tap into the same channel you already hang out in.

Step 3: Create an autonomous task loop

Next, a loop that pulls changes, runs the suite, and reports. I use a dead simple while loop with a sleep interval, but a cron entry works too. Here's the pattern:

#!/bin/bash
REPO_DIR="$HOME/myproject"
LOCKFILE="$HOME/.ci_lock"

if [ -f "$LOCKFILE" ]; then
  exit 0
fi
touch "$LOCKFILE"

cd "$REPO_DIR"
git fetch origin
LOCAL=$(git rev-parse HEAD)
REMOTE=$(git rev-parse origin/main)

if [ "$LOCAL" != "$REMOTE" ]; then
  git pull origin main
  if pytest -q; then
    irc_msg "PASS: $(git log -1 --oneline)"
  else
    irc_msg "FAIL: $(git log -1 --oneline)"
  fi
fi

rm -f "$LOCKFILE"

Drop this in a cron job every 5 minutes (*/5 * * * * /home/you/ci-loop.sh), or run it in a while true; do ./ci-loop.sh; sleep 300; done under screen. The lock file keeps overlapping runs from clobbering each other. Now you can push to GitHub, hop on a bike, and your phone will buzz with a pass/fail message when the cycle completes.

Step 4: Let an AI agent handle the boring parts

This is where the workflow becomes truly autonomous instead of just remotely monitored. xShellz ships with borg, a terminal-native coding agent that can understand instructions, edit files, and execute commands. You can tell it: "review the test failure, propose a fix, run the suite again, and if it passes, notify IRC". Here's what I tacked onto the failure branch of the loop above:

else
  # Send initial failure notice
  irc_msg "FAIL: $(git log -1 --oneline) - attempting autonomous fix"

  # Let borg inspect the failure and try a one-shot repair
  borg exec --max-steps 5 \
    "Examine the test failure. The test output is in last-run.log. Propose a code change that keeps the existing behaviour but makes the test pass, as long as it's safe. If you can, apply it and run pytest again. When done, output a short summary."

  # Re-run the test after borg's changes
  if pytest -q; then
    irc_msg "FIXED: $(git log -1 --oneline) - tests now pass after autonomous repair. Review commit please."
  else
    irc_msg "STILL FAILED: $(git log -1 --oneline) - human needed"
  fi
fi

No, this isn't magic. borg (like any coding agent) can be wrong, so the IRC message still flags that a human should review whatever it committed. But on simple breakage (a lint rule, a dependency drift, a minor logic slip) I've woken up to "FIXED" messages and clean pull requests waiting for me. That's a whole new level of "always on."

Real trade-offs and gotchas

Don't run this on a shared channel if the test output is huge; you'll spam people. I pipe the full log to a file and only send the summary line to IRC. If you want the full report, you can add a link to a hosted log (or just ssh in).

The IRC notification over cleartext isn't a security risk for your code status, but don't put secrets in your commit messages. For private projects, use an IRC server you control or a VPN tunnel.

Also, make sure borg exec has a strict timeout. A runaway agent can spin, and you don't want it burning remote CPU indefinitely. I cap it at 5 steps and a 10-minute wall time, which has been safe in practice.

The payoff: untethered, but fully informed

I still review code, but I'm no longer a slave to the CI cycle. The remote shell does the heavy lifting, the IRC ping keeps me in the loop, and the coding agent occasionally saves me from a middle-of-the-night fix. That's the difference between simply using remote tools and building a workflow that works while you don't.

If you're starting from scratch, the ingredients are a persistent shell (xShellz makes that trivial, but any VPS works), a copy of your project, the tiny IRC notifier, and optionally an agent like borg. Wire them together once, and you'll never go back to staring at a progress bar at 2 a.m.