How I've changed my vibecoding workflow this summer

Remove the small annoyances that break your productiviry

💡 Remember you can get free copies of my books here.

I’m a pretty decent programmer. It’s been a solid 25 years since I hacked my highschool admin password so I could play games at school, and about 15 years since I started charging decent sums of money for the code I write.

Most of the code I create is no longer written by me.

There are two kinds of programmers:

1. those that love writing code

2. those that like to create products

I am type 2. Code was the price of admission for convincing the computer to do what I want it to do.

The past 3 months I have moved from using AIs as an assistant, to using them as my employee. Unless I run the risk of losing money or sensitive data, I barely read the code the robots make in details anymore.

This spring and summer I created a bunch of side projects I actually use, and would not have the time for without robot support:

• A calculator for how long to sunbathe to get my vitamin d

• A travel video snippet app

• A self-hosted audio diary

• An Oura ring dashboard with standard deviation support

• And more nerdy stuff like adding memory64 support to the wllama package

I’d like to tell my fellow programmers a few of my learnings of the past months.

1. Don’t trust the robot to instruct itself

There is still real value in you designing workflows and guardrails. When the Astra and Fable models came out, the internet was abuzz with peopel saying that you should “ask the LLM to rewrite your skills” because they understand themselves better than you do.

If you are a competent programmer, this probably not true. I asked them to do the above, and the results cost me an entire day of productive work.

You can trust the robots with suggestions, but for the love of Linus, write your `AGENTS.md` and skills files yourself. You can always default to using skills other people moade, but I’d recommend reading them and checking if they actually do what you want them to do.

The best analog for this is that feeling you used to get when another programmer starts working in your codebase. They suddenly ignore your eslint rules, start making helpers like `is_odd`, and other shennanigans. The AIs do that, only in `.md` files. Their code is a lot better than their knowledge of how you like to work and what your priorities are.

2. Run your agents remotely 100% of the time

If you are like me, you used to run your claude/codex/opencode on your laptop. It really limits you in what you can do. If only because the laptop gets closed when you move around.

Another factor is that Mac’s OSX sucks for agents. The file system is slow as hell, and the process guardrails the system has slows things down. The hardware in Apple’s devices is amazing, but a 4 core 8gb home server outperforms my M chip 32GB Macbook Pro. It’s a discrace, but it is what we have to work with.

Get a little home server or a VPS. Run the agents there. It’s hard to fully put into words how much nicer this is. Just try it for a day. You won’t go back.

I still use babysit for remote sandboxing, but that is optional.

3. Use Mosh instead of SSH

Mosh is a UDP based drop-in replacement for SSH. It handles flaky connections.

When connected through Mosh your shell connection can “buffer” like a youtube video. Losing connectivity or your laptop going to sleep doesn’t close the connection.

It’s epic. Just try it. The only downside is that it does not support agent forwarding, but you probably aren’t using that anyway.

4. Let the models review eachother

My `AGENTS.md` is set up so that any OpenAI model is task to ask the Anthropic model for a review of its plans and commits and vice versa.

You can literally just tell it “If you are codex, ask Claude, if you are claude, vice versa. Use the CLI to ask for a review of your work”. Put it in your workflow, and you will enjoy it.

💡 Remember you can get free copies of my books here.