Execution Environments

For most developers, the best execution environment is still local. The laptop delivers the tightest possible feedback loop: save a file, hot reload fires, you see the change. No network hop. No cold start. The inner loop is measured in milliseconds.

Remote development environments emerged to solve different problems: onboarding complexity, dependency drift, and machine variability. Instead of every engineer curating a fragile local setup, teams run code in shared or managed environments provisioned in the cloud. Tools like Coder, GitHub Codespaces, and Telepresence made this viable by narrowing the latency gap and improving reproducibility.

Remote dev was optimized for human collaboration and environment parity, not high-frequency context switching. When a single developer spends most of the day in one workspace, a small amount of startup latency is tolerable.

Agents change the constraint. In an agentic workflow, developers aren’t just working in one environment; they’re supervising many. The cost of switching environments stops being an occasional annoyance and becomes a core productivity variable.

This is the new version of the xkcd "compiling" comic. Instead of sword-fighting while waiting for the build, developers are scrolling social media while waiting for environments to spin up or agents to finish.

The solution isn't to accept slow switching. We can make switching instant if we design and plan for it.

• Local container caching. Don't pull from a remote registry every time. Keep warm images locally.
• Pre-warmed environments. If you know you'll need to check on Agent A's work, have its environment ready before you need it.
• Shared base layers. All your environments should share a common base so switching is just the diff.
• Instant snapshots. Pause an environment and resume it later without cold start.

The goal: switching to any agent's context should take seconds, not minutes. If it doesn't, agents become a coordination tax instead of a productivity multiplier.

Agents don't have laptops. They need an execution environment provisioned for them — typically a cloud VM, a container, or an ephemeral runtime. The agent connects to this environment, runs commands, and reads output.

This introduces a fundamental asymmetry: the agent is remote to its execution environment. There's a network hop between the agent's "brain" (the LLM) and the machine where code runs. This has implications:

• Latency matters. Every command the agent runs requires a round-trip. Fast local SSDs become slow network file systems. The inner loop stretches.
• State is less visible. The agent can't"see" the dev server in a browser tab. It needs explicit verification — screenshots, API calls, test results.
• Environments must be self-describing. The agent can't ask "hey, what version of Node is this?" and interpret a puzzled look. Everything must be introspectable via commands.

This isn't a binary choice. Most teams end up with a spectrum:

The key insight: the operator determines the location, not the task. If a human needs to see what's happening in real-time, you want low latency. If an agent is grinding through a task list overnight, latency matters less than isolation and reproducibility.

If agents run remotely but humans value local speed, you have a coordination problem: how does a developer step into an agent’s environment without friction?

There are two viable architectural approaches. Both work. What matters is that you choose one deliberately and optimize it.

If you want developers to keep their normal local debugging ergonomics, a strong default is to pull the agent context local. If you want the simplest possible handoff and maximum parity, treat the laptop as a thin client.

The critical point is not which model you choose. The critical point is that switching into an agent’s context must feel cheap.

Agents increase parallel work. Parallel work increases supervision overhead. If stepping into an agent environment takes 90 seconds, developers will do it less often. Bugs accumulate. Trust erodes.

If stepping in takes 5 seconds, supervision becomes natural. Developers check progress casually. They fix small issues early. Agents become collaborators instead of background processes.

Design target: 10 seconds or less to enter any agent context.

You must design for this transition. If you don’t, the friction of environment switching will quietly cap the effectiveness of your entire agent system.

Here's the uncomfortable truth: if your dev environment doesn't match CI, agents will fail in ways that are hard to debug.

When a human hits a "works on my machine" problem, they can investigate. They notice the error, google it, realize their Node version is wrong, fix it. An agent can't do that kind of open-ended debugging — at least not reliably. It will thrash, retry, and eventually give up or produce garbage.

The solution is deterministic environments. Same container image, same lockfiles, same versions — everywhere. This is covered in depth in Guide 03: Reproducible Toolchains, but the principle applies here: execution environments must be identical, whether the operator is a human on their laptop, an agent in the cloud, or a CI runner in GitHub Actions.