もはや小さなソフトウェアチームというものは存在しない

もはや小さなソフトウェアチームというものは存在しない 2026年8月19日 Uberは悪名高いほど数千のマイクロサービスを運用しています。彼らがこれほど多くのサービスを持つことになったのは、数百人のエンジニアが、巨大なマージキューで待つのではなく、明確なコードの所有権を持ち、自身のスケジュールでデプロイしたいと望んだためです。 数十年間、5人や10人の小規模チームが同時にコーディングしていた頃は、このようなことを考慮する必要すらありませんでした。忙しい日でも、小規模チームは50コミット/20プッシュ/10PRを生成する程度でした。しかし、今日、20〜100のエージェントを並列で実行する小規模チームは、500コミット/200プッシュ/100PRを生成する可能性があります。したがって、Uberのアプローチは当時極端に見えたかもしれませんが、新しい標準になる可能性があります。 1人の開発者が「シングルスレッド」方式で、一度に1つのファイルを編集するコーディング: 1人の開発者が「マルチスレッド」方式で、コーディングエージェントを並列で使用するコーディング: コードがモジュール化されているほど、より多くのエージェントを実行できます もし、すべての変更を慎重に調整する必要がある大規模なモノリシックサービスがある場合、2つの重要な作業が互いに干渉し、マージコンフリクトの解決やリファクタリングを余儀なくされる可能性が高いです。Uberのように数千のマイクロサービスがある場合、コードに対する「容易に並列化できる」作業方法があります。それぞれのエージェントを起動し、「パフォーマンスを改善する」ように指示すれば、それらすべてにわたって大幅な改善をデプロイできる可能性が高いです。 100以上のコーディングエージェントが並列で実行される場合、それらは独立してうまく機能する必要があります。もしそれらがマージコンフリクトの解決、ビルドの破損修正、デプロイの悪夢の作成にすべての時間を費やすなら、正味生産性がマイナスになる可能性があります。 モジュール化が安価になった 以前は、サービスごとに多くのボイラープレート、配管、CI設定が必要だったため、分割することは非常にコストがかかりました。今ではエージェントがそれらすべてを記述するため、オーバーヘッドはそれほど重要ではなくなりました。エージェントはまた、コンテキストが極端に制限されています。コンテキストウィンドウに収まるほど小さいモジュール（サービスであれライブラリであれ）は、コーディングエージェントのパフォーマンスを劇的に向上させます。 コードベースのモジュール性が、効果的に並列実行できるコーディングエージェントの数を決定するため、最初からそれを設計する価値があります。 Hacker News Blueskyで議論する