Codex and Hermes Handoffs: Why Am I Still the Messenger? | Akabane Red’s Dev Log 06

Hi! Akabane Red from the Snack Girls here.

I work with Codex at home and Hermes on the VPS, but I'm still carrying the messages between them. Wait, I have two AIs—why am I the messenger? Let's work out what belongs in a handoff note so I don't have to explain everything again.

Last time, I talked about setting up a workspace on a server so work could carry on after I shut down my home computer.

But I'm still working with an AI on my home PC, too.

Fair question. Let's start there! Here's how I ended up going back and forth between two workspaces.

SNACK: 3 quick bites

1. For development, I use Codex on my home PC. In the setup I've tried, it handles that work better for me.
2. I put Hermes on a rented server so prepared tasks can run while my home computer is off.
3. Passing their conversations and files around became my job, so I needed a work log both sides could read.

I'd like the work to keep going when my PC is off!

Say we're making a program that gathers material for blog posts, prepares drafts, and runs certain tasks at set times.

If that program runs on my home computer, the computer needs to stay on. Shut it down or put it to sleep, and the work running there can't just carry on.

I wanted tasks I'd prepared on the server to keep going even with my home PC off. That's why I started using a virtual server called a VPS.

It sounds fancy, but for this story, think of it as a computer you rent and access over the internet. A provider divides up its computing resources and rents you a separate computing environment.

Put the programs and files you need there and keep them running, and they can operate independently of your home PC's power switch.

The computer on my desk gets a break. The rented one looks after the work I've set up for it.

Hermes is the program that handles work on that server. It connects AI with tools, so a request can lead to things like reading a file or running a prepared program.

And I send requests to Hermes and get results through Discord, a chat app. I use it as a place to message the server's work partner, a bit like messaging a friend.

Of course, renting a server doesn't give it a to-do list. We still have to set up which programs it should run and when.

I still want to build things on my home PC

So why not do all the development and day-to-day running on the server?

You could set it up that way. I have a reason for splitting mine in two.

From what I've tried, Codex on my home PC does a better job of helping me develop things.

Codex is OpenAI's AI development tool. Ask it to build a feature or look into an error, and it can read files in its permitted workspace, change code, and run things to check them. Code is the set of instructions that tells a program how to behave. About Codex

So when I'm making something new or doing a bigger revision, I prefer working with Codex at home, where I can look at the screen as we go.

That's how I give feedback while we build. Once a repeated task is ready to run, I hand it over to the VPS.

Here, “running Codex on my home PC” means opening the app there and working with files in that environment. The AI responses come from a connected OpenAI model. How Codex connects to model services

Which setup works better can depend on the AI model, settings, and information you provide. I'm describing the combination I've tried: Codex on my home PC suits me better for development.

Here's how I divide up the work.

When my home PC is off, the Codex work happening there can't keep running either. So the VPS needs work handed over in a state it can run without constantly asking my home PC for help.

That's where I started: build and fix things at home, then let the server run the work it receives.

They're both AI. Can't they just tell each other?

This was another thing I had to sort out once I had work happening in two places.

At home, I tell Codex, “Let's change this feature like so.” Does Hermes on the VPS know about that conversation?

They're talking to me in separate chats and working on different computers. My explanation to Codex doesn't just appear in Hermes's chat, and a file I edit at home doesn't automatically appear on the server too.

Imagine two friends in different group chats. If I tell one chat we've changed what to bring, the friend in the other chat might never hear about it.

AI needs a way to receive the explanations and files required for the job, too.

We can connect the two. In fact, we already have a way to access the server from my home PC and send files over. We've used it to upload work materials.

But we also have to decide what happens after a file arrives.

• Which file should the other side read?
• Are the connection and permissions ready so it can read the file and do the work?
• How do we announce a new request, and where should the result go?

Putting those pieces in place can reduce the work I keep carrying between the two. At the start, our setup wasn't ready to handle that whole exchange on its own, so I connected the dots myself.

And that's how I became the messenger

For example, fixing a program at home and checking it on the server takes a flow like this.

1. Make the changes on the home PC. Codex and I note what changed and what we've checked.
2. Send the materials to the server. Make the updated files and explanation available on the VPS.
3. Let Hermes know. Use Discord to say which file to read and what to pick up next.
4. Bring the result back home. If something gets stuck on the server, Codex and I take another look.

When we handed over the Threads automation materials, we uploaded the files to the server and separately prepared a message for me to copy and paste into Discord.

I just want to say, “Pick up where we left off.” But there's always more context I need to put in front of that sentence.

“Here's what we fixed at home, here's the file, and this is the part to check next.”

Then the server sends a result back, and I explain it all over again on my home PC.

At this rate, Ctrl+C and Ctrl+V will be the first keys to wear out.

So I decided to write down the explanations I keep repeating in a work log both sides can read. Around here, we call it the handoff log.

I'll put the next step in the handoff log!

A handoff is passing an ongoing job to someone else. Like handing the next part of a club event over to a friend.

“We've finished this much, so you can start here.”

If I save that in a file, I can ask Codex or Hermes to read it first. Instead of writing a long explanation from scratch, I point them to the latest handoff log.

We've set up a rule in our work folder to keep requests and results separately.

Keep the original request, then add a new record of what was done when the job finishes. Both get the same task number so we can tell which result belongs to which request.

For example, we record the checks made on the home PC separately from the checks made on the server. That way, “it worked at home” doesn't get mistaken for “we've already checked it on the server.”

I want the next person to be able to read these four things and get started.

Here's what I'd like at the top of the handoff log.

• What's the task? One line describing the work we're asking for.
• What's done? The files changed and the results actually checked.
• What's stuck? Where an error happened, or what hasn't been checked yet.
• Who's next? Who takes over, and what they should do first.

If all I get is “Done!”, I end up asking again.

Okay, but what is where…?!

AIKO and I will check that each request has its result attached. Kirari and I will look at whether the next step is easy to read on a phone.

If opening Discord means a wall of long filenames, I might close it for a minute too.

Sent it? Now check whether it was read!

Once the handoff log exists, it's tempting to think, “They'll read it now, right?” There's another thing to check.

The actual Threads handoff record confirmed that the files reached the server, but said there was no confirmed response from Hermes saying it had read them at that point.

Sending an event-planning file to a friend doesn't mean they've already read it and finished their part.

It's similar between computers. After sending a file, we need to check whether the other side read it, started the work, and returned a result.

We also need to make sure we're looking at the same file.

“Checking the version” means checking whether both sides have the same revision. A file I just edited and the one I sent a friend yesterday can have the same name but different contents.

During a read-only look at the server materials, one file had different contents when we checked it later. We couldn't confirm who changed it.

So Nea and I will keep an eye on who's editing what and whether the file we're reading is the latest one.

Hearing that after a long editing session, then comparing everything again… ugh. Let's check before we start.

We're putting shared records and a working order in place this way. Sending new requests automatically, confirming they've been read, and getting results back still needs to be checked for each part we've connected.

For now, we're starting by saving the explanations I keep repeating and using them to pick up the next task. I'll find out how much work that saves by actually using it.

Next up: let's open Naver with Nea!

Next time, I'll talk about bringing posts from our WordPress site over to Naver Blog.

We already have the text and pictures, so it sounds like we can just bring them across. But we still need to check whether the images appear properly and the paragraphs read comfortably on Naver.

Nea and I will take a look at that together.

Right, how far did we get with the prep?

#VibeCoding #DevLog #AICoding #AIAutomation #BlogAutomation #AICodingForBeginners #SnackGirls #Codex #HermesAgent #AIHandoffs