ソフトウェアチームに「小規模」はもうない 並行エージェントが変える開発
There's no such thing as a small software team anymore
Uberが数千のマイクロサービスを運用しているのは、多数のエンジニアが独自のスケジュールでデプロイし、コードの所有権を明確にするためだった。従来、5〜10人の小規模チームは1日に50コミット程度だったが、現在は20〜100のエージェントを並行実行し、500コミットを生成することもある。コードのモジュール化が進むほど、エージェントを効率的に並行稼働でき、Uberの手法は新たな標準になり得る。モジュール化のコストはエージェントが配管を書くことで低下し、コンテキストウィンドウに収まるモジュール設計が重要になっている。
「コードベースのモジュール化度が、並行して効果的に実行できるコーディングエージェントの数を決めるため、最初からその設計に価値がある」
HNでの議論
175- kstenerud
何百ものボットが何千ものマイクロサービスを変更するというのは、表面上は良さそうに聞こえるかもしれないが、その何千ものマイクロサービスは、アーキテクチャと製品を構成している。エージェントはコンテキスト全体を保持するのが得意ではないので、コードの小さな断片について推論するとき、しばしばコードの他の部分を傷つけるようなものを思いつく（特にKLOCが積み重なるにつれて）。複雑さは置き換えられたのではなく、移動されただけだ。そして、これらのマイクロサービスがすべて、これまで以上に動く標的になったら、何が起こると思う？AIは生産性を向上させることができるが、このアプローチは、むしろ悪夢の始まりのように聞こえる。
- davepeck
賢いトロールがかつて言った：
> 複雑さの精霊に対する最良の武器は魔法の言葉「ノー」だ
それに対して、私は小規模なチームは小規模のままでいられると信じている。小規模なチームは、高いベロシティ、コミット数、品質でシンプルなモノリスを出荷できる。サービス指向がエージェントのおかげで突然低コストになったわけではない。独立してバージョン管理されデプロイされる複数のサービス間の境界は、今でも扱いにくい厄介なものだ。そして、「より多くのエージェントを実行する」ことが本質的に望ましい、あるいは影響力がある理由は明確ではない。私の小規模チームの（率直に言って事例的な）経験では、価値はすぐに飽和する。
- ulrikrasmussen
私はこれが長い間聞いた中で最悪のアドバイスだろうとすでにコメントしたが、この人には私が保守しなければならないコードベースに絶対に近づかせないだろう。
しかし、これは本質的にブログスパムでもある。著者は意図的に2つのスクリーンショットを含めているが、それらは彼の主張にまったく何も追加せず、読むには小さすぎる。2つ目をクリックしても、拡大版には移動せず、同じスクリーンショットが掲載されている彼の会社のウェブサイトのフロントページに移動する。
- whatever1
チーム内でシニア人材の離職が十分に起こるまで2年待て。そうすれば、すべてのサービスが毎日障害を起こすだろう。
今日、システムを稼働させているのは、自分のシステムを知っているシニアたちだけであり、彼らはクソコミットを除外している。
彼らが燃え尽きて辞めたら、LLMが何をしたのか、なぜサービスがダウンしているのか、誰もさっぱりわからなくなるだろう。
- _345
1人あたり1日約10件のPRを出荷できるとは本当に疑わしい。それらのPRが1つの機能の小さな断片であるか、すべてが即座にレビューできる3行の修正のような小さなバグでない限り。そうでなければ、AIが正しい修正や機能を正しく行ったことをどうやって確認できるのか？そもそもその機能をその方法で実装してほしかったとどうやって確認できるのか？
- zkmon
人々が自動化を「チーム」と呼ばないでほしい。それが「仕事をする」というだけでチームと呼ぶなら、CPUコアやスレッドもチームだ。ただし、それほど確率的（知的）ではないが。彼らも仕事をやり遂げる。
- pranavmalvawala
面白い見解だ。モノリスは、そのコンテキストを保持するため、実際にはマイクロサービスよりも優れている。結局、開発者は製品を実行することになっており、できるからといって無意味にエージェントを実行し続けるべきではない。
- franciscop
`require('gulp')`を見て、記憶が蘇ってきた。確かに、それは約10年前のコードのやり方だ。私はまだプロジェクトごとのマルチスレッドはあまり好きではない。2つのプロジェクトを持ってコンテキストウィンドウを切り替える方が好みだ。現在のツール（少なくとも私が知っているもの）は、マルチスレッドには少し物足りないと思う。しかし、知識をアップグレードしようともしている。
私が見つけた良い方法は、OSSを多くやっていて自分のライブラリを持っているので、それらのライブラリの1つでバグを見つけたとき、メインウィンドウで同じプロジェクトに取り組みながら、別のウィンドウでライブラリを修正できることだ。通常はメインのウィンドウに「これは今はスキップしよう、ライブラリを修正しているから」と伝える必要がある。