Twitter/X

@rockorager was the last AMP team member to go all‑in on orbs; the post was…

2026-08-05 · 19:04 UTC ·@rockorager ·1 min read

Brief

@rockorager, the last AMP team member to adopt orbs, forced themselves onto orbs despite a productive local dev flow and discovered subtle friction around parallelization — worktrees, model-driven worktree creation, and contention with "7 other agents" over CPU. They report orbs eliminate worktrees and let them focus on the application rather than resource orchestration.

Why it matters

@rockorager was the last AMP team member to go all‑in on orbs; the post was published 2026-08-05 and they say their previous local dev flow made them "incredibly productive".

Key details

  • After forcing themselves to adopt orbs they discovered subtle, hard-to-explain friction around parallelization — issues with worktrees, how to tell the model to create a new worktree, and agents fighting over CPU ("7 other agents").
  • Orbs remove the need for worktrees and, according to the author, let them focus more on the application and less on resource orchestration and the "how".
Source evidence

I was the last amp team member to go all in on orbs. I thought my local dev flow was good enough. It worked. I was incredibly productive. I didn't need a change.

But I forced myself into orbs. And I found there was a lot of friction that I can't even explain - subconscious stuff - like...I can't parallelize that because of some stupid reason. I don't want to parallelize that because how do I tell the model make a new worktree, but also it's going to suck running tests because you'll fight with 7 other agents over CPU so please run them only in your domain and some orchestrator will run the full thing?

Orbs eliminate the need for worktrees. They let me think more about my application and less about my resources...less about the "how".