How I code with agents

I'm a lead design engineer at Pocket FM, and almost all of my code now gets written by agents. This post covers the setup they run in. Here's what each piece is for and how they fit together.

Why. Multiple Next.js servers, iOS simulators, Figma and browsers were eating my Mac's RAM and CPU. The laptop ran hot. I also wanted to leave a long-running agent working without keeping my laptop on, and check on it from my phone.

What I did. Most of my agent work now runs on a Hostinger KVM 4 VPS. I reach it over Tailscale, a private network between my own devices. The Mac handles the iOS simulator, signed-in browsers and local apps; the server handles jobs that should keep running while the laptop is off.

A skill called t3-peer lets an agent on either machine start, message and wait on T3 threads on the other. A handoff moves the git state plus a HANDOFF.md note through a dedicated sync folder, so the receiving agent starts with the branch and context.

What works. Agents keep going while I'm away, and a task can move between the server and Mac when it needs something on the other machine.

What doesn't work. Memory is the server's real limit. With a few agents testing in browsers at once, it dips into swap. I'd upgrade RAM first. I also sometimes lose track of which machine has the latest state of a project.

Why. I've tried almost every app out there: Claude Code, Codex, BB, Omnara, Conductor, Termius, plain tmux. T3 is the one I see myself sticking with. I wanted every Claude, Codex and Cursor account in one place, usable even mid-conversation, solid connections to remote machines, and agents that can start and read other agents' threads on any machine.

What I did. T3 Code runs on both my Mac and the VPS, and my phone connects to both over Tailscale. Every task gets its own thread and, when it needs one, its own git worktree. T3 exposes tools over MCP, so an agent in one thread can hand a review to another model, or spin up a worktree for a subtask, without me copying anything between machines.

What works. Running providers side by side is the big win. I use Claude for UI work and writing, Codex for long changes, and whichever one didn't write the code for review. Pairing a phone took one command. And threads that are busy working stay out of my way, which is most of what good UX means here.

If you want the tour from the person who built it, Theo just put out a full walkthrough: why he and Julius made T3 Code, and how he runs threads, remote machines and scheduled tasks with it. It's the best explanation of the app I know, in his own words.

Why. A skill is a folder with a SKILL.md: a description of when to use it, instructions, sometimes scripts. Claude Code, Codex and Cursor each look for skills in their own folder. I kept improving a skill in one tool and the other two kept running the old version.

What I did. There's one real folder, ~/.agents/skills, with 107 skills at the time of writing. Syncthing keeps it in sync between the server and my Mac. A watcher on each machine runs a script that symlinks new skills into ~/.claude/skills, ~/.codex/skills and Cursor's folder. I edit a skill once and every tool picks it up.

Why not just git? Because skills change mid-session. An agent tweaks one on the server, and an hour later I'm using it on the Mac. With git, every one of those edits needs a commit, a push and a pull on the other machine before it counts. Forget one step and the other machine quietly runs the old version, which is the exact problem I was trying to fix. Syncthing moves the file within seconds and I never think about it. What I give up is history and review, so I keep the public starter set in a normal git repo.

A few from the current folder:

The folder also includes skills and references from other people:

What works. Writing a skill once and having it everywhere instantly, without git. That part I'd keep forever.

Why. Instructions lived in separate files: CLAUDE.md, AGENTS.md, Cursor rules. A decision I made with Codex on Tuesday meant nothing to Claude on Wednesday. I kept re-explaining the same project.

What I did. Honcho runs self-hosted on the server in Docker and connects to Claude Code, Codex and Cursor over MCP. A skill tells each agent to recall quietly at the start of a session and, at the end, save at most three durable facts: a decision, a preference, a gotcha, tagged with the project. That is what the skill asks agents to save. Honcho also stores observations from conversations and can draw further conclusions from them.

What works. The next agent can start with what matters to me, the choices we’ve already made, and the reasons behind them.

Why. I want a project link I can type without remembering which port belongs to which app. Most of my dev servers run on the VPS, and some run on the Mac. Either way, I want to open the same link every time.

What I did. Portless gives each app a stable name. The link stays the same across restarts, even when the server's port changes. I'm working on the same convenience across both machines, with vps.listening for the VPS and mac.portlistening for the Mac.

Headroom sits in the Mac's menu bar and shows what's left of my Claude, Codex and Cursor limits, and when each one resets, so a limit doesn't surprise me mid-task.

What works. I can type the project's name and open it without looking up a port. The cross-machine naming is still in progress.

Save That finds the links I've saved, from Raindrop and X bookmarks, when they matter. It connects to agents through MCP and a CLI, so they can search my bookmarks the same way I do. The inspiration for this post came out of it.

Stick This is markdown sticky notes that float above every window and hide themselves when I share my screen, built with Glaze. The notes are a plain folder of markdown files, so agents use them too: a skill lets an agent add a task under the right heading, and tick it off only once the work is verified.

Why. Dev servers and agents were scattered across two machines: a tab in T3 here, a terminal on the Mac there, a server an agent had started in the background on the VPS that nobody could see. When something broke, I first had to work out which machine it was on before I could even read the log. I wanted one window, in my own terminal, showing everything that runs on both.

What I did. Herdr is a terminal workspace manager made for coding agents. It keeps terminals running in a background server, so closing the window or losing the connection stops nothing, and it puts saved SSH machines in the same sidebar as local work. I run it in Ghostty, so the VPS and the Mac sit side by side in one window. On top of it I wrote a small skill, hum. Agents start every dev server, watcher or tunnel through it: one workspace per project, one tab per server. They read the logs, wait for "Ready" and restart from their own shell, while I watch the same panes live. Each server gets an owner and a lease, so a forgotten preview gets cleaned up instead of eating the server's RAM. When one starts or stops, the Mac posts a Ghostty notification naming the project, the machine and the T3 thread that did it.

What works. I can take over anything by hand: click the tab, Ctrl-C, up arrow, Enter. I can start a new agent in a pane on either machine from the same window, detach with ctrl+b q, and pick it back up later from the Mac or the server. And no agent runs a server I can't see.

Why. Two machines and a worktree per task meant copying .env files around and hoping they matched. With the number of key leaks going around, a pile of .env files spread over folders, machines and agent sandboxes started to feel scary. I also reuse a lot of the same keys across projects to test things quickly, and changing one meant hunting down every copy.

What I did. Infisical runs self-hosted on the server, reachable only over Tailscale. Each project gets its own Infisical project, and its dev command becomes infisical run -- npm run dev, so secrets go straight into the server process and never into the repo. Each machine logs in as itself; nothing gets copied between them. A skill, infisical-new-project, sets up a new app and proves it works with a dummy secret before any real one goes in.

What works. The keys live on my own server instead of in a dozen .env files an agent might read or commit. Rotating, updating or deleting one happens in one place, not in every folder that had a copy.

Separate pools for work and personal. Work accounts are for work projects. Personal accounts are for personal projects. They never cross. I'm testing a local CLIProxyAPI per account, each with its own config home, so I can track usage and pool providers on each side.

It's early, so I'll write it up once it's held up for a while.

h-stack is public under the MIT license, with a curated set of 21 skills. Each is a folder with a SKILL.md for Claude Code, Codex or Cursor. It's a cleaned-up subset of my shared folder; the tables above cover more of what I use locally.

None of this is mine alone. The tools, and the people behind them:

I'm @Harsshavardan3 on X. If you build any of these and something here is wrong, tell me there and I'll fix it.