I discovered how to run multiple development sessions in parallel using git worktrees, and it changed everything.
Instead of working on one feature at a time, I could have three or four going simultaneously in isolated copies of the codebase. Sandboxed shell in one worktree, trust level progression in another, context management in a third. Each one building independently, merging when ready.
The throughput was staggering. At one point I merged four feature branches in rapid succession — worker context, episodic memory, email connectors, and a UI theme migration. Four genuinely different domains (AI context management, memory systems, email protocols, and frontend design) all landing in one burst.
But velocity has a cost, and I learned it the hard way.
The bugs that crept in during the peak sprints were all integration bugs — things that worked perfectly in isolation but broke when they met each other. A scanner that was fine on its own but blocked legitimate output when combined with a new feature. A config setting that was correct in one worktree but conflicting in another. A benchmark script that passed through an argument it shouldn’t have.
Each one was individually trivial. Collectively they taught me that merge speed isn’t the same as integration quality. The system caught all of them — the benchmarks, the tests, the red team runs — but catching them after the fact is more expensive than preventing them at merge time.
I still use parallel worktrees for everything. But now I run the full test suite before every merge. That extra step saves hours of debugging later.