Migrating an engineering team from local to cloud coding agents

Most teams start with coding agents on laptops: an engineer runs Claude Code or Codex in a terminal, pairs with it, and ships faster. The ceiling arrives quickly. The agent stops when the laptop sleeps, runs one task at a time, uses whatever is installed on that machine, and nobody else can see what it's doing.

Moving agents to the cloud lifts that ceiling. Moda, a Replicas customer, moved its entire engineering team from local IDEs to cloud agents. Their CEO, Pranav Bedi:

"Going from local to cloud coding agents was arguably as big of a jump as using coding agents in the first place."

Here's how to make the move without losing a sprint to it.

What actually changes

The agent itself can stay the same. Platforms such as Replicas run Claude Code, Codex, Cursor and OpenCode in the cloud, so engineers keep the agent and the instructions files they already know.

Step 1: Pick one repository and define its environment

Choose a repository with decent tests and active work. Write down what a new engineer needs to be productive in it: system packages, language versions, services (a database, a queue), seed data, environment variables. That becomes the cloud environment's setup hooks and secrets.

Get it right once, at the team level, and every agent run inherits it. This is the step that most determines whether cloud agents produce mergeable work.

Step 2: Sort out credentials

Decide how models are paid for:

• Engineers' own plans. Each person signs the agent in with their Claude or ChatGPT subscription.
• Team API keys. An Anthropic or OpenAI key, or AWS Bedrock or Microsoft Foundry, for shared channels and automations.
• Both. Personal plans for interactive work, a team key for automations.

Keep secrets in the platform's secret store or sync them from Doppler or Infisical, never in prompts. Scope what each environment can reach.

Step 3: Start where work already lives

Connect the places your team already hands work around: Slack, Linear, GitHub, GitLab. Then pick a first category of work that's easy to review:

• small bugs with clear reproduction steps,
• dependency bumps and lint or type fixes,
• test coverage for existing code,
• code review comments on every pull request.

Step 4: Keep review human

Agents open pull requests; people merge them. Turn on policies that stop agents from merging their own work, and have commits carry the identity of the person who started the run. Ask agents for evidence (test output, screenshots or a recording) so reviewers aren't guessing.

Step 5: Add automations

Once interactive use is working, add runs that start without anyone asking: a nightly maintenance pass, a fix attempt on every failed CI run, a triage run on new Sentry errors, a review on every pull request. Parrot, a Replicas customer, ran 23.5k automated cloud-agent jobs in July alone this way.

The first 30 days

• Week 1: one repository, one environment, three volunteers.
• Week 2: connect Slack and your tracker; start routing small bugs.
• Week 3: open it to the whole team; add a review automation.
• Week 4: look at the numbers: pull requests by source and engineer, cost per merged PR, the runs that went sideways. Fix the environment where agents struggled.

What not to move

Cloud agents are for delegation. Engineers who like pairing with an agent in their editor should keep doing that locally; the two coexist. If your team's work is almost entirely hands-on pairing, a local-first tool such as Cursor or Claude Code in the terminal may be the better primary choice, and the chooser will tell you so.

For the cost side of the move, see per-run agent cost attribution.