In the Agent Era, Branches Are No Longer the Default
Branches became the default under particular conditions. They name a line of commit history and gradually took on isolation, parallel development, and waiting for review. Once tools and team rules grew around those duties, “create a branch first” largely stopped being questioned.
Coding Agents change one of those conditions. When every task is developed and verified in its own remote environment, a branch no longer has to provide execution isolation. Agent work can go directly to main when the change is small, checks are reliable, the commit is easy to revert, and no mandatory approval applies.
The scope matters. Large migrations, external contributions, long-running collaboration, and repositories governed by compliance or required review still need branches and PRs. The default should change only for low-risk Agent tasks.
Branches Once Combined Isolation and Governance
In Git, a branch is a pointer that advances with commits; it does not itself copy code or create a working directory. Developers use checkout to switch versions in one directory, or worktrees to keep several versions available at once.
The same Git repository
repo/ working directory for main
feature-a/ worktree for feature-a
bugfix-b/ worktree for bugfix-bPR workflows added review, automated checks, and approval records on top. A branch came to represent a development line, the basis for a separate working directory, and a change awaiting integration. Those duties are related, but distinct.
Coding Agents inherited the “one Agent, one branch, one worktree” pattern. It separates file versions, but processes still compete for CPU, memory, and ports on the same machine. People must coordinate dependencies, browsers, and background services.
Orbs Move Execution Isolation into the Environment
Amp released Orbs in June 2026. An Orb is an independent remote execution environment: each Orb thread has its own code copy, dependencies, processes, ports, and browser, where an Agent can develop and verify its work without contending with other tasks on one local machine.
People can still inspect the diff, test results, and runtime, enter a shared terminal, or sync changes locally. Each task now has a complete development and verification site without relying on a branch and worktree for file-level isolation.
Branches, checkout, worktrees, Orbs, and PRs solve different problems. A branch represents a development line; checkout expands a version into the current directory; a worktree adds another directory; an Orb supplies a complete remote environment; and a PR handles review, approval, and audit. Orbs remove only the old need to create an isolated place for a task. They do not replace governance.
Going Directly to Main Still Has Conditions
Several Agents may start from the same main. After one pushes, those finishing later can rebase onto the latest main, resolve conflicts, and rerun checks. The thread still contains the intent needed to resolve ordinary conflicts; ambiguous choices can go back to the user. Concurrency remains, but a branch need not wait around for integration.
This works only when all four conditions hold:
- The change is small and its diff is quick to understand.
- Automated checks are reliable and rerun after rebase.
- Each commit can be reverted independently so failures are contained quickly.
- The repository has no mandatory approval, compliance record, or long-running collaboration requirement.
Review still happens against the diff and test evidence in the Orb; it simply does not need a branch as a waiting room. If any condition fails, keep the branch-and-PR workflow.
Change the Default
When the conditions hold, an Agent can develop and verify in isolation, rebase onto current main, rerun checks, and push directly. The next Agent starts from that new main. Earlier integration also reduces conflicts from long-lived divergence.
A team can begin with low-risk documentation, tests, and local fixes. Track conflict rates, check results, and time to revert; expand the scope only if the evidence shows that main remains stable. If review or recovery cannot keep up, retain the existing branch process.