Skip to content
The Software Mansion Agentic Engineering GuideThe Software Mansion Agentic Engineering GuideSoftware Mansion Agentic Engineering Guide

Going 10x

Agentic engineering is like multicore CPUs. Agents aren’t always faster than humans (sometimes they are, for sure). But a single human can control several agents in parallel, and that’s where the productivity speedup comes from. This page explains how to handle that effectively.

Conflict management

Section titled “Conflict management”

There are several ways to give parallel agents their own writable workspaces.

Cloud agents

Section titled “Cloud agents”

Cloud agents run on machines managed by the provider, usually from a fresh clone on a dedicated branch. Examples include Cloud Agents Cursor and Orbs Amp.

Cloud agents are easy to scale because each one gets its own compute, filesystem, and processes. You can start several tasks without tying up your laptop, leave them running, and review the branches or pull requests later.

A new remote machine starts without your tools, dependencies, secrets, services, or local data. Keep the setup in the repository so that the agent can build and test the code. Cursor uses .cursor/environment.json for install and startup commands and saves prepared environments as reusable Builds (Cloud Environment Setup Cursor). Amp uses .agents/setup to prepare a fresh orb, .agents/resume to repair its state after waking up, and .amp/services.yaml for development services that should keep running (Orbs Amp).

Cloud agents can still reach private infrastructure. For example, Cursor Cloud Agents can connect through Tailscale, Cloudflare Tunnel, and similar tools (Secrets & Network Cursor). For mobile agents, Argent Cloud provides hosted iOS simulators, and EAS CLI reference Expo provides a similar service for iOS and Android.

Use a local agent when a task depends on hardware or local state that you cannot expose remotely. For cloud agents, keep credentials narrowly scoped and check what the provider stores in images, snapshots, logs, and environment configuration.

Git worktrees

Section titled “Git worktrees”

A Git worktree is an extra working directory attached to the same repository. Worktrees share Git’s object database, so they are usually the cheapest local option.

Each worktree must use a different HEAD (branch, commit, or ref). A new worktree contains only tracked files, so you may need to restore dependencies, generated files, and ignored configuration before the agent can work. This approach works best when the app can boot with a blank or seeded state from a fresh checkout.

Agent harnesses can automate some of the setup:

Editors and IDEs can manage them too:

Some tools make it easier to move changes between an agent worktree and the checkout where you run or test the app:

Without built-in support, you can usually tell a model to do this in a /tmp worktree.

Separate checkouts

Section titled “Separate checkouts”

You can give each agent a complete Git clone instead. Each clone has its own Git metadata, so several clones can use the same HEAD and work with tools that do not understand worktrees. Full clones are simple, but they duplicate repository data and dependencies. Each clone also needs its own setup and must be kept in sync.

Shared checkout

Section titled “Shared checkout”

You can also go YOLO and let several agents operate in one working directory. This only works when the tasks touch clearly separate parts of the repository.

Tell agents to commit frequently and atomically, and to stage only changes from their own task. Put that rule in AGENTS.md so every agent sees it. Do not run formatters, generators, dependency installers, or other commands that rewrite shared files at the same time.

…

Help! My agents are writing spaghetti!!!

Section titled “Help! My agents are writing spaghetti!!!”

This is where vibe coding starts to diverge from agentic engineering. You, as a human, do serious work, and you must be held responsible for it. Models can make a mess because they are rewarded for task completion during training, not long-term architecture. This is (still) a human’s job.

  1. Organize the code in rather small modules with strict boundaries, predictable structure, and well-defined input/output.
  2. Enforce invariants in code, not only in documentation. Strict types, assertions, and tons of tests are your friend here.
  3. Enforce code patterns mechanically. Tell agents to write dedicated linters and CI jobs.
  4. What an agent doesn’t see doesn’t exist. Unlike humans, agents have no memory. Make sure all knowledge is either kept in the repository as files or easily reachable through MCP. Periodically verify that agents actually read this knowledge.

Sounds familiar, doesn’t it? These are standard practices of large-scale engineering. Agentic engineering just amplifies problems. Only one tip is specific to working with agents, and you’d be unlikely to adopt it in a 100% human team:

Read more:

…

Automated code reviews

Section titled “Automated code reviews”

Once several agents are producing diffs in parallel, review becomes the bottleneck. Automated reviewers help by filtering obvious bugs, missing context, and risky assumptions before the work reaches a human.

Context quality

Section titled “Context quality”

Automated review can run in parallel with implementation and catch obvious issues before a human reviewer spends time on them.

At first, these tools may produce low-quality feedback. That is expected, just as newly hired engineers need ramp-up time before they can review effectively. High-quality review depends on context: familiarity with the codebase, its history, and the team’s rules.

To make automated review agents useful, capture that context in artifacts they can read. There is no shared standard across tools yet, so you need to learn how your chosen review tool is configured and provide context in the format it expects.

Adversarial review

Section titled “Adversarial review”

A stronger version is adversarial review. Run the reviewer in a separate context and tell it to assume the change is wrong. The point is to find concrete failure modes, not to summarize the implementation.

Bun used this pattern during its Rust rewrite at a much larger scale: one implementer, multiple adversarial reviewers, and a fixer pass before changes were accepted (Rewriting Bun in Rust Jarred Sumner. 2026-07-08).

Tools

Section titled “Tools”

In-editor / local review workflows:

PR review bots:

Ownership

Section titled “Ownership”

Use these tools to reduce toil, not to skip ownership. Don’t ask teammates to review code you haven’t reviewed yourself.

…

Attribution

Authors