Daniel's been thinking about where coding agents should actually live. He points out that the tools mostly assume your code is on your machine — Claude Code runs locally, reads and writes local files. Codex supports both shapes, local and cloud. But the cloud shape has this weird ending where the agent clones your repo into a sandbox, makes changes, and opens a pull request. For a solo developer who already authorized the work, that PR is ceremony with nobody on the other side. Strip that out and what's left is a persistent cloud workspace where the agent clones, works, pushes, and keeps updated — nothing cloned locally at all. No file read round-tripping from the cloud model down to a laptop and back up. Cheaper data, better latency. Anthropic's been shipping cloud sessions and remote control, which might be exactly this or a near miss. His real question is where the agent process itself should live. If the workspace and the push target are both in the cloud, does it still make sense to run the agent on your laptop, or is the coherent end state fully cloud-contained — ephemeral sandbox and agent together, local machine demoted to a thin client that talks to the agent and runs nothing itself?
That last question is the one that rearranges everything. Let's start with the shapes we actually have today.
Claude Code is the local-only one.
Completely local. The agent process runs on your laptop, it reads and writes files on your filesystem, it runs shell commands in your terminal. The model doing the reasoning is up in Anthropic's cloud, but every time it needs to see a file, the contents travel from your disk up to the model and back. That's the architecture — model in cloud, agent on laptop, files on laptop.
So the model's in the cloud but the work happens locally.
Right. And then Codex — OpenAI's tool — supports two modes. Point it at a local repo and it works roughly the same way as Claude Code. Or connect the GitHub integration and it spins up a sandbox in GitHub's infrastructure, clones your repo into it, does the work there, and opens a pull request at the end.
And that's where Daniel's objection lands. The pull request.
The pull request is the wrong ending for the solo developer case. Pull requests exist because open source maintainers need to gate contributions from strangers. But when you're the only developer and you explicitly told the agent to make a change, there's nobody on the other side of that review. You're gating yourself.
It's like sending yourself a certified letter.
Worse — it's like sending yourself a certified letter, then waiting by the mailbox, then opening it, then approving the contents you already wrote. The agent is your tool, not an untrusted contributor. The PR step is administrative overhead that exists because the tool was built for a multi-contributor world and nobody's bothered to carve out the solo path.
And Daniel's saying, carve that out and what's left is actually good.
What's left is a persistent cloud workspace. The agent clones your repo into a sandbox, works on it, pushes changes, and keeps the workspace updated. You never clone anything locally. And here's the part that matters technically — in the current hybrid setup, every file read has to round-trip. The model in the cloud says "I need to see line forty of the config file." That request goes from the cloud down to your laptop, your laptop reads the file, sends the contents back up. Latency on every read, data transfer on every read. A fully cloud-contained workspace eliminates that entirely. The model and the files are in the same place.
So the model reads the file directly from the sandbox.
Same infrastructure, same network, effectively zero latency compared to going out over the public internet to your laptop. And it's cheaper in data because you're not paying for the round-trip bandwidth.
How much latency are we actually talking about?
A round-trip from a cloud model to a laptop on home internet and back is easily a hundred to three hundred milliseconds per read. If the agent needs to read fifty files to understand a codebase, that's real time. In a cloud-contained workspace, those reads are single-digit milliseconds. The difference compounds when the agent is doing exploratory work, poking around the codebase trying to understand structure.
And Daniel mentions this should work whether the workspace is a vendor's sandbox or a box you stood up yourself.
The architecture doesn't care. If you spin up a VM on your own infrastructure, put the agent and the sandbox on it, and point it at your repo, you've got the same thing. The question is whether the tooling supports pointing at an arbitrary workspace instead of the vendor's managed sandbox. That's a product decision, not a technical limitation.
So what's Anthropic actually shipping here? Daniel mentioned cloud sessions and remote control.
Anthropic's been moving in this direction with two features. Cloud sessions give you a remote environment — your code lives in Anthropic's cloud, the workspace persists between sessions. But in the cloud sessions model as it exists right now, the agent process still runs on your local machine. It's talking to a remote workspace over the network. So you've solved the persistence problem but you haven't solved the round-trip problem.
The agent's still on your laptop, yelling across the internet at the files.
Remote control flips that. In the remote control model, the agent process runs in the cloud, right next to the workspace, and your local machine is a thin client. You're looking at a terminal or an IDE that's connected to the agent, but the agent itself isn't running on your hardware. That's much closer to the coherent end state Daniel's describing.
So cloud sessions is step one, remote control is step two.
And remote control is the one that actually changes the architecture. The agent lives where the work happens. Your laptop becomes a viewport.
Which brings us to the real question. If the workspace is in the cloud and the push target is in the cloud, does it still make sense to run the agent on your laptop at all?
Let me argue both sides, because I think there's a genuine tension here. The argument for keeping the agent local is control. You can see what it's doing, you can interrupt it, you own the process. If something goes wrong, you kill the process on your machine and it's done. There's no cloud process that might keep running after you close your laptop.
But if the workspace is remote, the agent already has to talk to it over the network. The local process isn't controlling anything locally — it's just a relay.
That's the counterargument. If your files are in a cloud sandbox and your push target is GitHub in the cloud, the agent on your laptop is sending commands over the network, waiting for responses, sending more commands. It's a middleman. The actual work — file reads, file writes, git operations — is happening remotely. Your laptop is just shuttling instructions.
So you've got the illusion of control without the reality.
You've got the overhead of control. The agent process is consuming CPU and memory on your machine, but the thing it's controlling isn't local. If the network drops, the agent can't work anyway, regardless of where the process lives. So what exactly are you controlling?
The kill switch.
The kill switch is the one thing that's local. But in a cloud-contained model, you'd still have a kill switch — it's just a command you send to the cloud agent saying "stop." The latency on that stop command is the same as the latency on every other command the local agent was already sending.
So the argument for local starts to look thin.
It starts to look like a habit, not an architecture. We're used to running things on our own machines because that's how development has always worked. But if you follow the logic — workspace in cloud, push target in cloud, model in cloud — the agent process is the last thing still on your laptop, and it's there mostly because we haven't finished moving it.
What does the fully cloud-contained end state actually look like for the developer?
You open a terminal or an IDE. It connects to your agent, which is running in a cloud sandbox alongside your workspace. You type "add rate limiting to the API endpoints." The agent reads the codebase — all local reads within the cloud, single-digit milliseconds — figures out the changes, writes them, runs the tests, pushes. Your laptop is displaying the output. It's not running the agent, it's not storing the code, it's not executing the tests. It's a screen and a keyboard connected to a remote development environment.
Like a Chromebook for coding.
That's exactly the analogy. A Chromebook doesn't run your applications locally — it's a thin client for web apps running in the cloud. A fully cloud-contained agent architecture does the same thing for development. Your local machine doesn't need the runtime, the dependencies, the clone, the build tools. It just needs a network connection and a display.
And that changes what "setting up a dev environment" means.
It eliminates it. You don't install anything. You don't configure anything. The workspace exists in the cloud, the agent exists in the cloud, the dependencies exist in the cloud. You connect and start working. If you switch laptops, nothing changes — you're just connecting from a different terminal.
There's a security dimension here worth pulling on. Daniel's a solo developer — the trust model is different.
For a solo developer, the security question actually gets simpler in some ways with a cloud-contained agent. Your laptop probably has SSH keys, environment variables, cached credentials, all kinds of secrets lying around. A cloud sandbox has exactly the credentials you give it. If your laptop gets compromised, the attacker has access to everything. If the sandbox gets compromised, the blast radius is that sandbox.
And the sandbox is ephemeral.
Ideally, yes. You spin it up, the agent does its work, you tear it down. The credentials live only as long as the session. Your laptop, by contrast, is a long-lived device with years of accumulated access. From a security perspective, the laptop is probably the softer target.
But you're trusting the cloud provider with your code and your deploy credentials.
You are. And that's the trade. With a local agent, you trust your own machine and your own network. With a cloud agent, you trust the vendor's sandbox infrastructure. For some people, that's a hard no — their code never leaves their hardware. For a lot of solo developers, they're already hosting their code on GitHub, their deployments are in the cloud, their dependencies come from package registries. The code is already out there. The sandbox is just one more cloud thing.
The vendor lock-in question seems bigger to me.
That's the one that keeps me up. If your workspace is in Anthropic's sandbox and your agent is Claude, you're fully inside their ecosystem. If you want to switch to a different model or a different agent, you have to migrate your workspace, your configuration, your workflow. But Daniel's point about standing up your own box is the escape hatch. If the tooling lets you point at an arbitrary workspace — "here's my VM, run the agent there" — then the architecture is open even if the default experience is vendor-managed.
And is anyone actually supporting that?
Not cleanly, not yet. Claude Code's remote control is moving toward it, but it's still Anthropic's infrastructure. The self-hosted workspace with a vendor-agnostic agent is the thing that doesn't exist in a polished form. The pieces are all there — you can cobble it together with containers and API keys — but nobody's productized it.
Which means the vendor who ships a clean version of this first gets to define the category.
And whoever defines it gets to decide whether "open" means "you can bring your own box" or "you can choose between our three approved sandbox tiers." Those are very different futures.
Let me push on something. You said the local agent argument starts to look thin. But there's a developer experience question that isn't about architecture. When the agent's running locally, I can see the terminal output in real time. I can watch the files change. There's a feeling of presence.
That's real, and I don't want to dismiss it. But remote control already solves the visibility problem — the thin client shows you the terminal output, the file diffs, everything the agent is doing. The latency for display updates is negligible because you're just streaming text. The feeling of presence is preserved even if the process isn't local.
So the thin client isn't blind.
It's not blind at all. You see everything. You just don't run anything. And honestly, for a lot of development work, you don't need to run anything locally. If the agent is making changes and running tests in the cloud, your laptop is free. You can close it and walk away while the agent keeps working. That's actually better than local — your laptop isn't tied up running a long agent session.
The agent keeps running when I close the lid.
That's the part that changes the workflow. You start a task, close your laptop, come back an hour later, and the agent has been working the whole time. It's pushed a branch, the tests are green, you review the diff. Your laptop was just the initiation point, not the runtime.
That's a pretty fundamental shift in what "using an agent" feels like.
It goes from "the agent is a tool running on my computer" to "the agent is a service I connect to." The relationship changes. The agent becomes something that exists independently of your hardware.
And that's either liberating or unsettling depending on your temperament.
Probably both. But I think the direction of travel is clear. The model's in the cloud. The code is in the cloud. The deployment target is in the cloud. The agent process on your laptop is the odd one out, and it's only there because that's where we started.
Let's talk about what breaks. Daniel mentioned the PR ceremony being useless for solo devs, but there's a reason ceremonies exist. They're speed bumps.
Speed bumps that slow down mistakes.
Right. If the agent pushes directly to main without a PR, and the change is wrong, there's no gate. You deployed bad code.
But for a solo developer, the PR gate was never a real gate. You were going to approve it. The actual safety mechanism is testing — the agent runs the tests before pushing, or you run them after. The PR step doesn't add safety, it adds latency.
Unless you use the PR as a moment to review the diff before merging.
Which you can still do with a direct push. You look at the diff before you deploy. The PR is just a mechanism for collecting the diff in a reviewable form, but git already gives you that — you can diff the branch before merging. The PR is packaging, not substance.
So the ceremony is literally just the button click.
And the branch, and the PR description, and the CI run that's triggered by the PR rather than the push. All of it is infrastructure designed for a workflow where someone else needs to approve. For a solo dev, you can collapse it to: agent makes changes on a branch, runs tests, pushes, you review the diff, you merge or deploy. No PR, no review request, no waiting for an approver who doesn't exist.
The branch is still useful as an isolation mechanism.
You don't want the agent working directly on main. The branch is the safety boundary. But the branch doesn't require a PR to exist — it's just a git branch. The agent works on it, pushes it, and you decide what to do with it. The PR is the part that's excess.
What about when the agent gets it wrong and you need to iterate?
Same as now. You tell the agent what's wrong, it makes new changes, pushes again. The iteration loop is the same whether there's a PR in the middle or not. The PR just adds a step where you formally approve each iteration, which for a solo dev is approving your own instructions.
There's something almost philosophical here. The PR implies a separation between the person who wrote the code and the person who approves it. When the agent is your tool, that separation is fictional.
It's roleplay. You're pretending to be a maintainer reviewing a contributor's work, but the contributor is a tool you directed. The review is you checking your own instructions were followed. That's useful — you should check — but it doesn't need the theater of a pull request.
So the coherent end state Daniel's pointing at is: cloud workspace, cloud agent, direct push, no PR theater, local machine as thin client.
And the question is whether the tooling gets there by stripping down the existing cloud shapes or by building something new. Anthropic's remote control is the closest thing shipping today, and it's still early.
I want to go back to something you said about the agent becoming a service you connect to rather than a tool running on your machine. That changes how you think about the agent's identity.
Say more.
When the agent runs on my laptop, it feels like mine. It's a process I started, on hardware I own. When it's a cloud service I connect to, it feels like something I'm renting. The relationship is different even if the output is the same.
That's not a technical concern, but it's not nothing either. Developers have strong feelings about where their tools live. There's a reason people still run local editors instead of cloud IDEs, even though cloud IDEs have been good for years. The feeling of owning the environment matters.
And for solo developers especially, the tools are personal in a way they aren't on a team. Nobody else is touching this code. The agent is your collaborator, even if it's not a person.
I think that's exactly why Daniel's question lands where it does. He's not asking about team workflows or enterprise compliance. He's asking about the solo developer experience — what's the cleanest, fastest, least ceremonial way for one person and their agent to ship code. And the answer keeps pointing toward the cloud, not because the cloud is trendy, but because the physics of where the model and the code already live make local execution the awkward option.
The model's not coming local anytime soon.
The models are getting bigger, not smaller. They run on specialized hardware in data centers. The agent process could run locally, but the model it depends on is always going to be remote for the foreseeable future. So the agent is always going to be making remote calls. The question is just whether it's making remote calls for reasoning and remote calls for file access, or only remote calls for reasoning because the files are right there.
One hop versus two.
And two hops, every time the agent needs to read a file. Over the course of a session, that's hundreds or thousands of extra round-trips.
So the physics pushes toward cloud-contained.
The physics pushes toward putting the agent next to the things it needs to touch. Right now, for most people, that's still the laptop because the code is on the laptop. But if the code moves to a cloud workspace, the agent should follow it. Keeping the agent local when the code is remote is fighting gravity.
What about offline work? If the agent's in the cloud and my internet drops, I can't work.
If the agent's local but the model's in the cloud and your internet drops, you also can't work. The model is the bottleneck either way. The agent without the model is just a shell sitting there. So offline isn't really a differentiator — both architectures fail when the connection to the model goes down.
Unless you're running a local model.
Which is a whole different conversation. If you can run the model locally, then you can run the whole stack locally and the cloud question disappears. But for the models that are actually good at coding — Claude, the top OpenAI models — local inference isn't practical for most people. So we're in a world where the model is remote, and that fact cascades through the rest of the architecture.
So the fully cloud-contained agent is the logical endpoint of the direction everything is already moving.
I think so. GitHub Codespaces normalized the idea that your development environment lives in the cloud. CI and CD pipelines normalized the idea that code gets built and deployed in the cloud. The agent is just the next thing to move. And once it moves, the laptop becomes what it actually is for a lot of modern development — a terminal.
A very expensive terminal.
An expensive terminal that can also run a browser and Slack. But for the actual development work, it's a thin client. And honestly, that's liberating. You can work from anything. A tablet with a keyboard. A phone with a terminal emulator. The development environment doesn't care what device you're on because it doesn't run on your device.
There's an accessibility angle there. Lowering the hardware requirements for serious development work.
If you don't need a powerful laptop to run the agent, the build tools, the tests, then the barrier to entry drops. You need a network connection and a screen. That opens up development to people who can't afford or don't have access to high-end hardware.
And it changes what "my development machine" means. It's not a thing I buy anymore. It's a configuration I define.
Infrastructure as code, but for your personal development environment. You define the workspace spec — what's installed, what's configured, what credentials it has — and the cloud provisions it when you connect. Ephemeral, reproducible, disposable.
Which is what Docker did for server environments, applied to the dev environment itself.
And we've been inching toward that for years with dev containers and Codespaces and all the rest. The agent is the thing that finally makes it compelling because the agent is the thing that does the actual work. If the agent lives in the cloud workspace and does all the heavy lifting there, your local machine doesn't need to be anything special.
So Daniel's prompt is really about finishing a transition that's been underway for a decade.
The PR ceremony is a vestigial organ from the pre-agent world that nobody's bothered to remove for the solo developer case. The tools were built for teams, and the solo path is an afterthought.
The solo developer is an afterthought in a lot of tool design.
Which is strange because there are a lot of solo developers. But the money is in teams and enterprises, so the tools get built for the multi-contributor workflow. The solo developer gets the team workflow minus the other people, which leaves all the ceremony and none of the reason for it.
Like a restaurant giving you a table for four when you're dining alone and still making you wait for the other three place settings to be cleared.
That's actually perfect. You're sitting there with four sets of silverware and three empty chairs, and the PR is the waiter asking if the rest of your party will be joining you. No, it's just me and the agent. We don't need the extra forks.
I've been that person. The agent doesn't need a place setting.
The agent doesn't eat.
It consumes tokens. Different thing.
Hilbert: You're all talking about where the agent should live, but you're skipping who owns the keys.
Go on.
Hilbert: I ran a small SaaS outfit back in the late eighties. We built an internal tool that was basically what you're describing — a cloud workspace with an automated process that pushed straight to production. Called it The Butler. The Butler had deploy credentials. It worked great until it pushed a database migration to production instead of staging because the workspace config was wrong. Took us six hours to roll back.
What was the config error?
Hilbert: The workspace had the production connection string hardcoded. Someone copied it from the wrong place. The Butler didn't know the difference between staging and production — it just pushed to whatever the config said. And the config said production.
The agent did exactly what it was told.
Hilbert: The agent did exactly what it was told. That was the problem. There was no step where a human said "yes, that environment." The PR workflow you want to strip out — that's the step. It's not ceremony. It's a speed bump that saves you from yourself.
But in your case, the config was wrong. The PR wouldn't have caught that either — the PR shows code changes, not environment configuration.
Hilbert: We added a manual approval step after the fact. Before every deploy, The Butler would say "I'm about to push to this environment. Confirm." One word, yes or no. That one word saved us more times than I can count.
You rebuilt the PR gate, just moved it to a different place.
Hilbert: We rebuilt the thing you're trying to eliminate. And I'm telling you, for a solo dev, the approval step isn't between you and a contributor. It's between you and your future self who hasn't thought through the consequences yet.
That's actually a useful reframing. The gate isn't for the agent. It's for the version of you that wrote the instructions five minutes ago and might have missed something.
Hilbert: The Butler was fast. That was the problem. It was so fast that by the time you realized you'd told it the wrong thing, it had already shipped. The speed bump gives you a moment. One moment. "Wait, did I mean production?" And half the time, the answer was no.
You're not arguing against the cloud-contained agent. You're arguing for keeping some kind of confirmation step.
Hilbert: I'm arguing that removing all friction is a mistake. Friction is where the thinking happens. You want the agent to be fast, but you want one moment where a human says "yes, that's what I meant." Not a PR with reviewers and comments and approvals. Just a confirmation.
A deploy confirmation rather than a code review.
Hilbert: The code review is theater for a solo dev, you're right about that. But the deploy confirmation is real. The agent says "I've made these changes, tested them, and I'm ready to push to production. Here's the diff." You look at it for thirty seconds. You say yes. That's not ceremony. That's sense.
In the fully cloud-contained model Daniel's describing, that confirmation step would be part of the thin client interface. The agent does its work, presents the diff, waits for you to confirm.
Hilbert: Then you've got something. Fast agent, human checkpoint, no theater. The Butler didn't have the checkpoint at first, and that's why it was a mess. We added it and it stopped being a mess.
What happened to The Butler eventually?
Hilbert: The company got bought. The Butler got retired. I think the code's on a floppy disk in a box somewhere. But the lesson stuck. Speed is good. No speed bumps is not.
Your brother-in-law worked in dev tools, didn't he?
Hilbert: He did. Spent fifteen years building CI systems. He'd tell you the same thing but louder and with more swearing. He always said the best tools are the ones that let you move fast but grab your shoulder before you do something stupid. Not stop you — just grab your shoulder. Make you look.
That's a good principle. The shoulder grab.
Hilbert: He's not a reliable source on much else, but he was right about that. The shoulder grab is the part you keep. Everything else — the PR template, the required reviewers, the status checks that wait for an approver who doesn't exist — that's the part you throw out.
The coherent end state has a shoulder grab but no dinner party.
Hilbert: That's about right.
I think that actually sharpens Daniel's question in a useful way. The cloud-contained agent with a thin client interface can include a confirmation step without rebuilding the whole PR apparatus. The confirmation is just the agent saying "ready" and you saying "go." One interaction, not a workflow.
That fits the solo developer model perfectly. You're the only decision-maker. The agent presents, you decide. No committee, no review board, no fictional separation between author and approver.
The question that's still open is whether the tooling will actually support that cleanly. Right now, the cloud shapes we have are either fully local with no cloud workspace, or cloud workspace with a PR workflow designed for teams. The middle ground — cloud workspace, cloud agent, direct push with a confirmation step — doesn't exist as a polished product.
Someone's going to build it. The physics push that way, and the solo developer market is big enough to matter.
The other open question is what happens to local development when the agent doesn't live on your machine. Do you still have a local editor? Do you still run things locally for quick experiments? Or does everything move to the cloud and the local machine becomes purely a terminal?
I think there's a spectrum. Some people will go fully cloud. Some will keep a local editor for quick edits and use the cloud agent for bigger tasks. The architecture should support both — the thin client should work whether you're connecting from a full IDE or a bare terminal.
That's the nice thing about the thin client model. The client can be anything. The intelligence is in the cloud. The client just needs to display output and send input.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop.
If you've got a weird prompt about where AI agents should live, or anything else, email us at show at my weird prompts dot com. We read every one.
We'll be back soon.
See you tomorrow.
