【要約】C-3PO、その名を返上する ── PO 廃止完遂と DX 整理 (v1.10 〜 v2.3) [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、Claude Codeのサブエージェント並列実行時に発生するrace conditionを回避するため、独自に3,700 LOC規模のPOレイヤを構築・運用していた。この運用は以下の課題を抱えていた。
- ・race conditionにより、tool呼び出しの76%が失敗する深刻な欠陥。
- ・独自実装（subprocess、SQLite、worktree管理）に伴う膨大な保守コスト。
- ・公式のdepth 1制限により、TDDエージェントが並列実行の対象外となる構造的制約。
// Approach
開発チームが、公式機能のアップデートを確認し、リスクを最小化する段階的な機能分離廃止アプローチを採用した。
- ・PoCによるrace condition解消の検証。15並列・101回の成功を確認。
- ・5段階のリリースによるPOの段階的削除。計-11,305 LOCを削減。
- ・TDDをRed/Green/Confirmの3つのWaveに分解する設計への変更。
- ・wt_*エージェントの新設。worktree内限定でpermission bypassを適用。
// Result
開発チームが、コードベースの劇的な軽量化と、公式仕様に準拠した安定的な並列実行環境を実現した。
- ・PO関連のコードおよび関連資産を計11,305 LOC削減。
- ・全エージェントが並列起動可能な設計への移行。
- ・F-XXX形式の内部IDを機能名へ置換し、ユーザーの可読性を向上。
Senior Engineer Insight
> 独自実装の「負債化」を、外部仕様の変化をトリガーに、PoCに基づき迅速に解消した判断が極めて実践的である。単なる削除ではなく、機能分離による段階的移行と、公式機能への「持ち上げ」によって、保守コストを最小化しつつ機能を維持している。特に、permission問題に対し「worktree限定のbypass」という限定的な権限付与で解決する設計は、セキュリティと利便性のバランスとして非常に優れている。