From Vibe Coding to Agentic Tools: These Are The Tools I Use To Code From the Road

I started "vibe coding" last fall, and it was fun and exciting and I learned a lot. Since then the entire world has gone a little crazy with "yeah, I can code that in an afternoon" ideas, and that turns out to be far less achievable than it looks. Over the past year I moved off vibe coding as my focus and onto agentic tools that create, optimize, refine, and fix other people's code, most of it from a laptop in a hotel room. Here is the stack and the handful of habits that made that work.

Most of the advice floating around right now assumes you are at a desk, on a fast connection, on one machine. Mine gets built in hotel rooms and on phone hotspots, on the kind of WiFi you get at a rental cabin on a guys trip rather than the kind you have at home. That constraint is useful, because it exposes every part of a setup that only ever worked from your own desk. These are the four things I would tell anyone starting now.

Your Stack Is the First Thing You Build

The stack is not one thing and it does not hold still. Mine has turned over more than once since last fall, and it will turn over again. Budget for that. Test tools against each other, keep whatever survives contact with real work, and stay on top of what is new instead of defending what you already paid for.

Start with the network layer, because it is cheap to sort out now and expensive to sort out later. Proxies are the piece most people skip. Testing from your own connection only tells you how your app behaves from your desk, and routing traffic through a service like Proxy-Seller lets you see what a user somewhere else sees: whether geo-gated content resolves, whether currency and language detection fire correctly, whether your own rate limiting triggers the way you wrote it, and whether a signup flow flags an IP it does not recognize.

A VPN covers the other half by protecting the connection you're using, and I have written before about what to look for in a travel VPN.

The third leg is model access. Paying for more than one provider is not about loyalty to any of them. It lets you assign the same task to two different models and see which one returns something usable.

Know What You Are Building Before You Start

This works a lot like blogging. There is no reason you cannot say "I want to build this silly little thing" or "I wonder what would happen if I do this," and that is a perfectly good reason to open the laptop. But if you think that is the pathway to riches, you are going to be disappointed.

I have coded more than 100 apps at this point, and they fall into three groups. Some are vibe-coded things that started as an idea and stayed there. Others are critical infrastructure I depend on every day. The third group is older GPL software that stopped being supported, where I was forced to fork it because there were security issues nobody was going to fix, or because my own workflow had outgrown what it did.

Those three groups have nothing in common except the tools, and the trouble starts when you stop being able to tell them apart. I made the same argument about prototypes in a very different context, and it holds here too.

Skip the $10,000 AI Box for Now

Local AI is the future for a lot of things, and it is not there yet. Open-weight models are incredible and improving fast, but unless your actual goal is learning homelab hardware, do not go spend $5,000 to $10,000 on an AI appliance for your house. The business case does not work when you are starting out, because you are buying infrastructure and a maintenance job at the same time.

Claude Max at $100 a month is honestly the best money I spend, and it flexes up to $200 for the stretches when I need the extra quota. OpenAI Codex sits in the same category, and an OpenRouter account lets you try a dozen models without committing to any of them.

None of them replace an API account, though, and that catches people out. A subscription powers you working. An API key powers the app you ship to somebody else. If what you are building is meant for public consumption, budget for both.

Security and Testing Are the Unglamorous Half

Security does not give you the dopamine hit of coming back to your terminal and finding a nearly built app or a finished build plan waiting for you. It is the difference between something you can put in front of other people and something you cannot.

It applies to the app, and it applies just as much to the environment you build in. Check the security settings on your GitHub repo, including default visibility, who holds write access, and whether a secret ever got committed. Use a VPN. Keep backups you have restored from at least once. These are the things you already know you need and probably are not paying attention to, and they matter more here because an agent can commit a mistake faster than you can read it.

If you are handing the result to work colleagues or to friends and family, the bar moves again. So does reaching back to your own hardware while you travel, which is a problem worth solving before you need it.

The Shift From Writing Code to Directing It

The most useful change of the past year had nothing to do with building things faster. It was moving off vibe coding as the point and onto agentic tools pointed at code that already exists: other people's projects, abandoned extensions, my own older work that needed fixing rather than replacing. That is where the leverage sits now, and it is a different skill than prompting something into existence from nothing.

The habit worth copying is smaller than any of that. Before you point an agent at any repo, make sure that repo is under version control and committed clean. Not because the agent will break something, but because when it does, the gap between a five-second revert and a lost evening is one commit you made before you started.