Claude Code and other agents are great until you try running

I've been experimenting with a mix of Claude Code, Codex CLI, and a few others. The biggest lesson is that if you don't have a strict system for isolation, you spend more time fixing merge conflicts than actually coding.

Stop giving vague assignments

The biggest mistake I see is treating an agent like a general employee. Telling an agent to "improve the frontend" is a recipe for a 50-file diff that breaks everything. I've shifted to a "one agent, one outcome" rule.

Instead of a general area, I give a hard finish line. For example: "Make the checkout form preserve its state after a failed payment, add a regression check, and stop before you touch the payment API." This creates a boundary. If the agent hits a wall or needs to cross that boundary, it stops and reports back rather than hallucinating a solution across the whole repo.

Use git worktrees to prevent collisions

When we have two agents editing the same module, it's a nightmare. To solve this, I've started using git worktrees. This lets me give each agent its own physical directory and branch so they don't trip over each other's file changes.

git worktree add ../project-auth -b agent/auth
git worktree add ../project-billing -b agent/billing

Now, one agent can run tests and install dependencies in the auth folder while another is working on billing. If one is just reading logs and the other is writing code, a shared checkout is fine, but the moment two agents can write to the repo, I isolate them.

My internal control loop

To keep from losing my mind, I follow a rigid five-step AI workflow:

1. Outcome Definition: Set the behavior, constraints, and a clear stopping point.
2. Ownership: One task per agent. No shared ownership.
3. State Monitoring: I don't watch every token; I only care if the agent is working, blocked, or finished.
4. Diff Review: I ignore the agent's "confident summary" and go straight to the code and tests.
5. Deliberate Integration: Merge the smallest possible verified unit before moving to the next.

Routing by task shape

I don't believe in a permanent "best" model leaderboard because things change every two weeks. Instead, I route tasks based on the "shape" of the work. Cross-cutting refactors go to whichever agent is currently best at tracing long code paths. Tightly specified features go to the fastest, most predictable tool. I also occasionally use a second agent as a reviewer, but I never let it silently rewrite the first agent's work.

The key is separating the roles of builder, reviewer, and investigator. When every agent is allowed to do everything, nothing actually gets finished.