AI時代に「小さな開発チームはもう存在しない」海外エンジニアの意見が割れる
「There’s no such thing as a small software team anymore(小さなソフトウェアチームというものはもう存在しない)」というブログ記事がHacker Newsで議論になった。AIエージェントで1人が大量のPRをさばけるようになった結果、Uberのようなマイクロサービス化が『新しい標準』になるという主張に対し、Uberが何千ものマイクロサービスを抱えたのは評価・昇進のための陣取り合戦が原因だったと暴露するコメントや、それよりしっかり設計されたモノリスの方がいいという反論が相次いだ。楽観派と「AIの冬」を予想する慎重派の間でも意見が割れている。
小さなソフトウェアチームというものはもう存在しない
出典: jacob.gold / 元記事はこちら
> 大規模なモノリシックサービスで、すべての変更を慎重に調整しなければならないなら… マイクロサービスはデプロイの調整という点ではむしろもっと大変だ。サービス間の機能依存が生まれて、結局同じ調整作業に戻ってくるのに、今度は下流の依存関係を見つけるのがさらに難しくなる。
1人あたり1日10件もPRを出せるなんて正直信じられない。それぞれが1つの機能のごく小さな断片か、3行で直せる小さなバグ修正でもない限り無理だろう。じゃないとAIが本当に正しい修正や機能を作ったのか、そもそもその実装のやり方でよかったのか、どうやって確認するんだ?
何千ものマイクロサービス＝何千ものデプロイが失敗しうるということだし、互換性を保ち続けなきゃいけないし、お互いを見つけられなきゃいけないし、監視もしなきゃいけない。これは単に痛みを下流に押し付けているだけだ。
> つまりUberのモジュール化へのアプローチは当時は極端に見えたかもしれないが、これが新しい標準になるかもしれない。 それはどうかな。これはコードのモジュール化とサービスのモジュール化を混同しているように見える。複雑さをコードベースから運用側に移すのは、少なくとも自分がLLMを使う感覚とは逆行している。
>>10
そんな環境で、LLMはどうやって適切にコンテキストを構築・管理するんだ?
そんな環境で、LLMはどうやって適切にコンテキストを構築・管理するんだ?
エージェントがあろうとなかろうと、1日100件のPRをこなす『小さなチーム』なんて存在しない。
Uberが何千ものマイクロサービスを抱えることになったのは、サービスを持つことが評価や昇進に直結する仕組みだったからで、しかも何年もかけてその数を減らそうとしていたはずだ。それを『意図的な選択』みたいに解釈しているのは笑える。
>>12
前に働いていた会社でまさにこれが起きた。各チームリーダーが自分たちの『秘密の花園』を持ちたがって、新しいものを誰が追加するかで揉めていた。秩序を保つためにKafkaのインスタンス管理が2人がかりのフルタイムの仕事になっていた。その会社は最近、二束三文で売られた。
前に働いていた会社でまさにこれが起きた。各チームリーダーが自分たちの『秘密の花園』を持ちたがって、新しいものを誰が追加するかで揉めていた。秩序を保つためにKafkaのインスタンス管理が2人がかりのフルタイムの仕事になっていた。その会社は最近、二束三文で売られた。
古臭いと言われるかもしれないが、人間がスロップの大砲に詰まってしまう問題の解決策は、AI生成コードがもっと人間らしく見えるようになることだと思う。つまり正しいだけでなく、その言語らしい書き方(イディオマティック)でもあるべきだということだ。
これは炭鉱のカナリアとして使える。制御不能係数＝並行で動くエージェントの数÷人間プログラマーの数。1. この係数がNを超えたら、制御を失いつつあり、組織としての知恵が受け継がれなくなる。2. チームがこの係数をN以下に保てないなら、あなたのアーキテクチャは複雑すぎる。自分の思い込みより係数の方を優先しろ。私のおすすめはN=1だ。
>>14
組織の知恵は、コードやコメント、markdownのドキュメントファイルという形で受け継がれる想定をしておくべきだ…それも、ケンタウロス型オーケストレーターを使う他のエージェント向けに。
組織の知恵は、コードやコメント、markdownのドキュメントファイルという形で受け継がれる想定をしておくべきだ…それも、ケンタウロス型オーケストレーターを使う他のエージェント向けに。
自分は1人チームで、エージェントは使っていない。
各サービスにエージェントを埋め込んで、それとチャットすればいいんじゃないか?少なくともその方が楽しそうだ。
自分は1人開発チームで、Reactより性能の良いフロントエンドコードを書いた。うまくいったのは、LLMの支援を一切使わなかったからだ。
>>18
それはすごいな。特定の開発目的に合わせたお手製のWebユーティリティは好きだよ。どういうアプローチを取ってるんだ?ちょうどmithril.jsのプロジェクトを始めようとしていて、それが一番効率的なやり方だとずっと思っていたんだけど。同じような方向性?それとも違う?もしかしてWASMの話をしてる?
それはすごいな。特定の開発目的に合わせたお手製のWebユーティリティは好きだよ。どういうアプローチを取ってるんだ?ちょうどmithril.jsのプロジェクトを始めようとしていて、それが一番効率的なやり方だとずっと思っていたんだけど。同じような方向性?それとも違う?もしかしてWASMの話をしてる?
マイクロサービスの面倒事なしに、この種の並列性を得る別の方法がある。しっかり設計されたモノリスを作り、単一責任を徹底してモジュール同士を分離しておくことだ。
>>2
エージェントはアリのようなものだ。アリは冬に資源が尽きるまで作りまくる。AIの冬がどうなるか、非常に興味深い。
エージェントはアリのようなものだ。アリは冬に資源が尽きるまで作りまくる。AIの冬がどうなるか、非常に興味深い。
>>20
いずれ設備投資(capex)の冬は来るだろう。各社は今、巨大な設備投資に散財しているが、いつまでもこのペースでGPUを買い続けるわけじゃない。だからといって、みんなが手作業で職人的にソフトウェアを書く時代に戻るわけじゃない。それは絶対に起きない。
いずれ設備投資(capex)の冬は来るだろう。各社は今、巨大な設備投資に散財しているが、いつまでもこのペースでGPUを買い続けるわけじゃない。だからといって、みんなが手作業で職人的にソフトウェアを書く時代に戻るわけじゃない。それは絶対に起きない。
>>20
意地悪で言うわけじゃないが、『常に夏である世界』を前提に計画を立てた方がいい。OSSモデルの台頭で評価額は崩れるかもしれないが、プログラミングが元の『普通』に戻ることは二度とない。
意地悪で言うわけじゃないが、『常に夏である世界』を前提に計画を立てた方がいい。OSSモデルの台頭で評価額は崩れるかもしれないが、プログラミングが元の『普通』に戻ることは二度とない。
>>2
なぜ常にサービスを修正する必要があるんだ?一度立ち上がって機能していれば、触らなければいいじゃないか。
なぜ常にサービスを修正する必要があるんだ?一度立ち上がって機能していれば、触らなければいいじゃないか。
>>23
プログラム内のどんな関数を変更・置き換えるのと同じ理由だ。状況が変わったから。
プログラム内のどんな関数を変更・置き換えるのと同じ理由だ。状況が変わったから。
>>3
エージェントスパムは、明らかに収穫逓減の典型例だ。
エージェントスパムは、明らかに収穫逓減の典型例だ。
>>7
マイクロサービスがモノリスよりマージコンフリクトが少なくなる理由が分からない。
マイクロサービスがモノリスよりマージコンフリクトが少なくなる理由が分からない。
>>15
じゃあなぜもっと多くのエージェントを動かしたいんだ?もっと生産的になるため?その生産性は何につながるんだ? — オタクのニッチの外でも使われるソフトウェアだよ。Photoshop、Canva、ClickUp、After Effects、Unreal EngineとかがfehやImageMagick、impressive、Emacs org-mode、ffmpeg CLI、pico-8みたいなツールに取って代わるみたいに。
じゃあなぜもっと多くのエージェントを動かしたいんだ?もっと生産的になるため?その生産性は何につながるんだ? — オタクのニッチの外でも使われるソフトウェアだよ。Photoshop、Canva、ClickUp、After Effects、Unreal EngineとかがfehやImageMagick、impressive、Emacs org-mode、ffmpeg CLI、pico-8みたいなツールに取って代わるみたいに。
>>22
(数ある違いの中の)1つの違いは、(ほとんどの)コンパイラはプロセス境界をまたいだ保証をしてくれないということだ。
(数ある違いの中の)1つの違いは、(ほとんどの)コンパイラはプロセス境界をまたいだ保証をしてくれないということだ。
>>22
実際、マイクロサービスの方がむしろ複雑だと言える。それが今までマイクロカーネルがモノリスに比べて成功してこなかった理由だ。
実際、マイクロサービスの方がむしろ複雑だと言える。それが今までマイクロカーネルがモノリスに比べて成功してこなかった理由だ。
それを指摘するのは社会的なルール違反ってことになってる。
>>39
『常に夏である世界を前提にする』…この考え方を受け入れるのが難しいのは、過去にも『今回は違う』『これで歴史は終わった』と主張した先見者たちが何人もいた実例があるからだ…そして、まあ、その後の顛末は知っての通りだ。
『常に夏である世界を前提にする』…この考え方を受け入れるのが難しいのは、過去にも『今回は違う』『これで歴史は終わった』と主張した先見者たちが何人もいた実例があるからだ…そして、まあ、その後の顛末は知っての通りだ。
>>50
でも今のモデルは実際に役立っているし、推論(inference)は利益を生んでいる。せいぜい心配すべきなのは、最新モデルが実は大して役に立たない、あるいはこれ以上良くならない、という可能性くらいだ。
でも今のモデルは実際に役立っているし、推論(inference)は利益を生んでいる。せいぜい心配すべきなのは、最新モデルが実は大して役に立たない、あるいはこれ以上良くならない、という可能性くらいだ。
>>39
『プログラミングはもう普通には戻らない』って、今がクソだって言いたいのか?純粋に気になっただけなんだが。
『プログラミングはもう普通には戻らない』って、今がクソだって言いたいのか?純粋に気になっただけなんだが。
>>51
昔の仕事には戻れない。プロンプトエンジニアになるか、クビになるかだ。
昔の仕事には戻れない。プロンプトエンジニアになるか、クビになるかだ。
今、野放しのAI支出は、増えている以上の人々のQOL(生活の質)を下げている。平均的な人がQOLの低下を喜ぶべき理由がどこにある?
>>40
それはそうだが、その変更を新しいバージョンとしてまとめて調整するなら、何か問題が起きたときに戻れる旧バージョンは依然としてあるはずだ。
それはそうだが、その変更を新しいバージョンとしてまとめて調整するなら、何か問題が起きたときに戻れる旧バージョンは依然としてあるはずだ。
>>40
それこそまさにコメント主が提案していた『もっと調整すべき』という話そのものだから、あなたの返信の意図がよく分からない。
それこそまさにコメント主が提案していた『もっと調整すべき』という話そのものだから、あなたの返信の意図がよく分からない。
※本記事は5ch(Hacker News)スレッド「There’s no such thing as a small software team anymore」より抜粋・要約して構成しています。
まだコメントはありません。