How it works
An agentic dev system doesn't require a new kind of environment. It requires the same environment — set up so that either a human or an agent can operate it, from anywhere.
The core idea
Every dev loop has the same three moving parts. What changes when you add agents is who's at the controls and where the environment is running.
A human developer or an autonomous agent. The environment doesn't care which — it just needs an operator with the right credentials and context.
A local machine or a remote/cloud runtime. The environment is portable — it runs the same way regardless of where it's hosted.
During active development, in CI, or on-demand. The environment can be spun up at any phase of the loop — interactively or programmatically.
Side by side
The steps are the same. The operator changes.
Human Developer
Local machine
Read the spec or ticket
Human reads, interprets, asks questions
Set up the environment
git pull, docker compose up, install deps
Reproduce the issue
Open the app, click around, confirm the bug exists
Write the code
Editor, terminal, browser — the inner loop
Verify it works
Run tests, check the UI, manual QA
Open a PR
Push, write a description, request review
Autonomous Agent
Remote runtime
Read the spec or ticket
Agent parses structured spec, extracts constraints
Set up the environment
Same image, same deps — spun up in an ephemeral cloud runtime
Reproduce the issue
Agent runs repro steps, captures screenshots as proof
Write the code
Agent edits files, runs the dev server, iterates
Verify it works
Agent runs tests, captures demo artifacts, checks acceptance criteria
Open a PR
Agent pushes, writes a description, attaches evidence
The steps are identical.
The environment is the same. The toolchain is the same. The only thing that changes is who's driving and where the runtime lives.
The environment
Whether a human is running it locally or an agent is running it in the cloud, these layers are identical.
git clone / git checkoutSame repo, same branch, same commit
package-lock.json / go.sumSame lockfile, same versions, deterministic install
Dockerfile / devcontainer.jsonSame container image or nix shell, identical toolchain
docker-compose.ymlSame database, same queues, same external services
.env / vaultSame env vars, same feature flags, same secrets (scoped)
npm run dev / make serveSame start command, same port, same hot-reload behavior
What's different
This is the only layer that changes. Everything below it stays the same.
Human operator
Agent operator
The handoff
Because the environment is the same, switching who operates it becomes straightforward. The handoff is a context transfer, not a rebuild.
human
You're coding, debugging, have the app running. You've got context about what you're doing and why.
handoff
Your code, your branch, your spec — all captured in the repo. The state is portable.
agent
Same branch, same deps, same dev server command. The agent reads the spec, sets up the environment, and continues where you left off.
agent
Writes code, runs tests, captures artifacts. The inner loop is the same — just running in the cloud instead of on your laptop.
handoff
The agent's work product looks the same as yours would: a branch, a diff, a description, and evidence.
human
Pull the branch, spin up the env, check the work. If it needs more, you pick up where the agent left off. Same environment. Same loop.
What this means
The dev environment must be fully reproducible so it runs identically on a laptop and in the cloud.
Agents need their own scoped identities, not your SSH keys.
Agents can't read your mind. They need specs they can parse and execute against.
Switching from human to agent (or back) needs to be a context transfer, not a full rebuild.
Agents in remote runtimes need to reach the running service — for testing, verification, screenshots.
Every run — human or agent — should produce evidence: screenshots, test results, diffs.
The guides cover each of these problems in detail — with patterns, anti-patterns, and real examples.