Untethered Development

I don’t code at my desk anymore. And on the days I do sit at my desk, I still don’t touch a keyboard.

I might be standing in line, or walking, or sitting somewhere with my phone in one hand. I talk — out loud, in full sentences — and a server at home picks up the work and runs with it. By the time I get back to a screen, a real chunk of it is done.

That’s not a productivity hack I read about. It’s a system I built piece by piece over the last few months, because the tools finally got good enough to make it real. This is how it works.

What actually changed

When people talk about AI and coding, they talk about what you can build now — faster, more, with less typing. That’s real, but it’s not the part that changed my day-to-day. What changed for me is where I work, how I work, and whether I even have to be there.

Three shifts, specifically:

• Desk-bound → cloud. The work doesn’t run on the device in my hand. It runs on an always-on machine, and whatever I’m holding is just a way to reach it.
• Keyboard → voice. This is the big one. I talk instead of type — and not just on the phone. Even at my desk, the keyboard is gone.
• Babysitting → autonomous. I’m not sitting there approving each step. I set the work up properly and walk away.

That middle one surprises people, so let me be concrete. On the days I do sit down to code, I drive the whole thing with a mouse — a Logitech MX Master with its buttons reprogrammed: one for voice-to-text, one for Enter, and the scroll wheel for moving up and down the terminal. Voice does the talking, the mouse does the clicking, and I almost never reach for a key. The no-keyboard thing isn’t a mobile compromise I settle for when I’m out; it’s just how I work now, desk included.

My main tool for this is Claude Code — not because it writes the best code in some benchmark, but because it has a mobile app with remote sessions, and I’ve built a whole workflow around that one capability. (I still use Codex too, but it’s the system around the tool that matters here, not the tool.)

The method: four phases

Before any of the untethered stuff, there’s how I actually approach a piece of work. For anything non-trivial — and these days my work is less “add a button” and more “design how these two systems talk to each other” — I run four phases.

1. Investigation

This is where I spend most of my time. By a lot. It’s the longest phase and the most important one, because everything downstream depends on it.

And I do almost all of it by talking. I start with a monologue — ten, fifteen, sometimes twenty minutes — laying out the whole umbrella of what I want to build. The AI listens, then reads back a summary of what I said. I check it: if it captured everything, I move to the next topic and monologue again; if it missed something, I correct it first. Topic by topic, summary by summary, until I’ve run out of things to say. It’s less a conversation than a series of brain-dumps, each one confirmed before the next.

When I’m out of monologues, I hand it all over with a particular kind of ask — not “build this,” but “find the holes”: where’s my logic thin, what are we still missing, what should we go research. For that to work, the AI needs the right tools in hand before it starts — read-only access to the database, the way to talk to the APIs it’ll touch, the packages and commands I use day to day, pointers to how the code fits together. On every project I keep a file listing those tools and point it there. Give it those, and it can actually investigate instead of guess — and, just as important, it won’t stall later asking for them mid-build.

I don’t chase 100% understanding. When I’m around 90%, I move on — the last 10% is usually fine detail that resolves itself once the work starts. The goal is to get the shape right, not to be perfect.

2. Documentation

Before any code, everything I dumped in those monologues gets organized into a written plan: what I explored, what I’m building, how I’ll build it, and the acceptance criteria that define “done.” If it’s a small thing, that’s one file. If we covered a lot, it’s a folder named after the topic — a README to land on, and a series of files underneath for the detail.

This matters more than it looks. If I lose my session or my context, these documents let me pick right back up. And future-me can come back and ask “why did I decide it this way?” — the docs are the answer. Over time they become a record of how my thinking has evolved.

3. Execution

Execution runs on a loop, and the loop is the whole point.

Here’s what I learned the hard way. Without a loop, the AI does a good-enough job: on a long to-do list it’ll knock out the first task, then the second, and then — right around the third — stop and ask, “are you sure you want to keep going?” Yes. Obviously. But now I’m tethered again, babysitting it past every checkpoint. So instead I give it a loop with a clear finish line — “do tasks one through five” — and when that “are you sure?” moment comes, the loop just answers it and keeps moving. It’s the only real guarantee the work will run to completion while I’m gone, and it tells me roughly how long that’ll take.

The one thing that still breaks a loop is a bad investigation. If it keeps stopping for a login, a permission, or a tool that isn’t installed, that’s not an execution problem — it’s a sign I didn’t set up the prerequisites back in phase one. A loop that breaks is a symptom; the fix is always upstream.

So before I start a loop, I do a quick pre-flight: I ask it to confirm it’s actually used every tool it’ll need, and then point-blank — “any blockers you expect to hit?” If yes, we clear them now, not mid-loop. If no, I have it write a loop whose finish line is the acceptance criteria from phase two, and say go. Then I leave.

4. Validation

This is the lightest phase, and that’s the payoff of front-loading everything else. By now the problem is defined, the plan is written, the code is built — so validation comes down to a single question: did it actually fix the problem? The AI takes a step back and checks the work against the acceptance criteria I wrote back in phase two — running the tests, screenshotting the UI, inspecting the database, whatever proves it. When those check out, it’s done for real.

The thread through all four: readiness

At every phase boundary I ask one question: on a scale to 100%, how ready are you to move on?

The number isn’t a grade. It’s a thinking budget. If it comes back low — say 70% — that means there’s still stuff to explore, so instead of advancing I let it keep going and make sure it has the tools to dig deeper. Around 90%, we move. I’m not aiming for perfect; I’m aiming for ready enough that the next phase won’t fall apart.

The system that makes “walk away” actually work

Autonomy sounds nice until you try it and realize all the ways it quietly breaks. Here’s the infrastructure that closes those gaps.

An always-on machine

A loop only runs while the machine running it is on. Close the laptop and the session dies; shut down the desktop and it’s gone. So everything runs on a box that stays on 24/7 — either my desktop left running or a more powerful server. Every device I own is just a client to it. This is the same model I’ve worked in for years with remote dev containers: the work lives on a capable machine somewhere else, and I reach it from wherever I am.

Starting sessions from anywhere

I wanted to kick off the investigation phase while I was out — waiting somewhere, a question in my head, nowhere near my desk. So I built a small app, Claude Launcher. On my phone I pick a machine and a repo, tap launch, and it handles the rest.

Under the hood it fires the real thing: it builds the claude command in remote-control mode and starts it inside a tmux session on the machine I picked — whether that’s the host or a container. Running it in tmux means the session is detached (it keeps going when I close the app) and still attachable from a desktop terminal later, which is what makes one session feel like the same thing whether I’m on my phone or back at my desk. But the part I care about most is the setup it does before handing me the session: it marks the repo as trusted and pre-installs the auto-approve permission hook, so the session is born already cleared to act — no “do you trust this folder?” and no “can I run this command?” waiting for me on a phone screen. Then it watches the output for the remote-control link Claude prints and grabs it. By the time I switch to the mobile app, a live, already-autonomous session is just sitting there. I never touch a session ID or type a command.

Knowing when it’s done

This was the missing piece nobody talks about: when you walk away from an autonomous loop, how do you know when it’s finished? Out of the box, you don’t — and before I fixed it, I caught myself doing the most unproductive thing imaginable. I’d sit and stare at the terminal, watching it work, waiting for it to be done. It felt like working. It wasn’t. It was just me, tethered to a screen, burning time.

So I wired up a notification system. Now something buzzes whenever there’s an event — a task finishes, a loop moves to the next step, it needs permission, or it has a question — and each notification carries a one-line summary of what just happened, so the buzz itself tells me the state. Better still, it escalates to my watch: a tap on the wrist means “go look.” Which means the phone can stay in my pocket until then. That one change is what let me stop staring and reclaim the time.

Never clicking “yes”

The fastest way to kill the whole thing is to sit there approving every action — are you sure? yes. are you sure? yes. That defeats the entire point. So I removed those interruptions: permissions are auto-approved at the tool level, and I’ve told the AI to stop presenting me menus of options and waiting — pick the best one, say why in a line, and keep going. I only want to be stopped for genuinely architectural decisions, not paper cuts.

Where this actually happens

Two scenes from the last month, so this doesn’t stay abstract.

An hour-long walk. I put on my Meta glasses — the microphone sits right on my face, so I don’t have to raise the phone to talk. I start with the monologue, talking through everything I want to investigate, then hit send and put the phone in my pocket. Then I just walk. I don’t look at it again until my watch buzzes. When it does, I glance at my wrist to check it’s the one I’m waiting for; if it is, the phone comes out, I read what it’s been doing, answer its follow-up questions or steer it where it should go next, talk out my reply, hit send, and pocket it again. Investigation is really a string of monologues — one topic at a time, more as I remember them — so this repeats, but each round the phone is only out for a moment. By the time I’m home, a real chunk of design work is done, and I spent the hour walking, not staring at a screen.

A stop-and-go commute. Here’s how I start almost every new session anyway: I hit the microphone and just talk — ten, fifteen, sometimes twenty minutes straight — dumping everything I know about the problem so the AI has everything to work with. Crawling along in commute traffic turns out to be the perfect container for that opening monologue. The phone sits in a holder, I start the mic, and I talk. You’re allowed to talk; it asks nothing of your hands. By the time the traffic clears, the investigation phase is already underway. Time that used to be pure frustration is now the most natural part of my process.

The pieces that make this work are small and unglamorous: a microphone near your face, a ring for when your hands aren’t free, a buzz on your wrist when something needs you, a server that stays on. But together they’re what take “untethered” from a nice idea to something I actually do on a Wednesday.

The philosophy

Strip it all back and it comes down to one idea: design the work so you can walk away from it.

Everything else falls out of that. The long investigation phase exists so the loop won’t break. The notifications exist so walking away is safe. The always-on server exists so walking away doesn’t kill the work. The no-questions rule exists so walking away doesn’t mean coming back to a prompt that’s been waiting for an hour.

I’m not tied to a desk. I’m not tied to a keyboard. I set the work up well, I let it run, and I go live my life. That’s untethered development — at least as of June 2026. Ask me again next year; the tools will have moved, and so will this.