全体の生産性は10〜15%くらいしか上がらない。それでも無視できる数字じゃないけど、10倍には程遠いね。LLMツールのコストのせいで、雇用コストが10〜15%高くなるなら、それは無視できない数字だよ。生産コストはスループットだけじゃなくて、常に考慮すべきだね。

私がイライラするのは、職場の経営陣が10倍の生産性向上を聞いたことがあることだ。中には職場の初期導入者からの主張もある。私の職場でも似たような状況だけど、内部の初期導入者からの生産性の主張は、非常に狭い測定方法と、かなり怪しい数学に基づいているものばかりだよ。

オープンソースプロジェクトの分析によると、生産性は10%から15%向上するらしいよ…だから、君の言ってることは正しいね。

ただのテクノロジーのハイプ波だと思う。現実は完全な破滅と無限のユートピアの間くらいだろうけど、たぶんそのどちらでもない。AIのことは、2000年代初頭にソフトウェアエンジニアを外注しようとした時の大きな動きに似てる。経営者たちの間でめちゃくちゃ盛り上がってたけど、書類上ではすごく妥当に見えた。でも、ほとんどの取り組みは大失敗に終わって、ほとんどの仕事はアメリカに戻ってきた。ソフトウェアエンジニアがやってる、全体をまとめるための小さなことを無視しがちなんだよね。AIはその辺が欠けてる。外国人がそれを欠いてるわけじゃないけど、言語の壁やタイムゾーンの違い、文化の違いなどが似たような問題を引き起こす。コードの品質や保守性は急降下して、外注先で作られたものの多くはゴミ箱行きになった。今、僕が関わってるコードベースにもAIの雑なものが溜まってきてるのが見える。コードレビューを通り抜けてしまうこういう問題を見つけるのはすごく難しいんだ。差分を見てると、合理的に見えるからね。問題は、見えてない冗長なコードや、高い視点から見ると全く意味がない奇妙な抽象化なんだ。

君の今日の世界に対する見解には同意するけど、たった12ヶ月前（今のベースモデルやClaude Codeのようなコーディングエージェントが出る前）は、コードの一部を書くことで10倍の改善なんてあり得なかったよ。

個人プロジェクトでは、状況によっては簡単に10倍以上速くなることもある。仕事では、数ヶ月先を見越して計画を立てて、5つの異なるチームと協力して、開発中に8回も変わる要件に対して正しいやり方を見つける？PRレビューや他の人が理解できるようにするだけでも大変だよ。時には、たぶんトントンか10-15%の改善に留まることもある。環境によってはうまく機能しないこともあって、AIが本当にうまくいくためには（超高品質なアーキテクチャの計画やデザイン、標準化されたパターンなど）が必要だけど、それは小さなスタートアップや個人プロジェクト以外では実現不可能だよ。正直、エンジニアたちがその超特化した標準化パターンに同意するのさえ大変だし、AIを助けるものは彼らが慣れているものとは違うことが多い。少しでも逸脱するものが出てくると、AIが混乱して10倍の効果が得られなくなる。特に、僕が「10倍」のローカルプロジェクトで行う変更のPRをレビューしてくれる人なんていないし…その基準を維持するのも、サイドプロジェクトではすでに大変だ。AIは自然に逸脱してノイズを生み出すし、それをガイドするシステムを構築するのが課題なんだ（ノイズはさらにノイズを生むから）。結局、バランスを取り直すことが大事だと思う。もし、同じ志を持ったエンジニアが1人か2人いれば、彼らは10倍の効果を得られるだろう。でも、実際の企業環境や、4人以上になると、そんなことは絶対にないと思う。中間管理職やプロジェクト計画にはAIが役立つけどね。

今の仕事がR&D寄りだからかもしれないけど、俺にとってLLMは「思考」の部分でも「コーディング」の部分でも同じくらいの成果を出してくれてるよ。今のところ「コミュニケーション」は自分でなんとかできてるしね。LLMを「思考」タスクに使うのは、20年以上前にウェブ検索をマスターしたときの感覚に似てる。検索エンジンは、何を探しているか分かっていれば情報にアクセスできたけど、今はLLMが何を探しているかを見つける手助けをしてくれて、その上で便利に検索もしてくれる。これで、以前は手間や不確実性から難しいと感じていたタスクが簡単になったよ。今では、ウェブ検索の約1/3をChatGPTでやってるし、もう手放せないと思う。LLMが半端な考えを整理してくれるおかげで、タスクがずっと楽に感じるっていう心理的な面もあって、それだけでも大きな違いがあるね。

コミュニケーションや会議のどれくらいが、従来のコード作成が非常に高価で遅かったからだと思う？将来的にどれくらいの会議が効率化されるか、あるいは完全になくなるか？俺の経験では、ソフトウェアがスケジュール通りに進んでいることや、ちゃんと機能していることを確認するためのプロセスがたくさんあると思う。ソフトウェアライフサイクルが再発明される時が来てるんじゃないかな。

僕がイライラするのは、今働いてる会社の経営陣が10倍の生産性向上を聞いたことだね。これは、ジュニア開発者にとってLLMがシニア開発者ほどの加速剤にならないからかもしれない（ジュニアは良いものと悪いものの区別がつかないし）。だから、1人のシニア開発者に強化されたLLMのワークフローを与えたら、10人のプレLLMジュニアと同じくらい生産的になるのも驚かないよ。もしかしたらそれ以上かも。悪い開発者は実際には負の生産性を生むことがあるから（シニアから盗む）、その場合は無限大になる。普通のジュニアはほとんど低レベルの雑用に制限されていて、LLMはそれをすでにもっと上手くこなせる。要するに、仕事が失われる可能性があるのは理解できる。

AIを使って「全くコーディングせずに」小さなアプリを週末に作って、月曜日にそれを自慢して、エンジニアがタスクに時間がかかることに驚くのは最高だね。

まあ、君の具体的な経験（現在または過去）については言えないけど、俺はすべてに対して懐疑的だけど、期待を超えてるよ。24時間以内に何かを作ったけど、これが立ち上がるのに数ヶ月かかってたと思う。最も印象的なのは、俺ができることをすべて、ただ速くやってくれること。さらに、俺が絶対にできないこともやってくれて、外注しなきゃいけなかったことを、もっと少ないお金と時間で、他の人とコミュニケーションを取るよりも早くやってくれる。完璧じゃないし、時には本当にイライラすることもある（明示的に言ったのに値をハードコーディングしたり、特定の修正をしたと嘘をついたり）、でも俺にとってはゲームチェンジャーだよ。

俺は40年間プログラミングをしてきて、数ヶ月前からLLMを使い始めたけど、本当に仕事のやり方が変わった。エラーメッセージをログから貼り付けるだけで、1分以内に修正してくれることが多いし、アーキテクチャや新しいソリューションについてブレインストーミングもしてくれる。もちろん、書いたコードはチェックするけど、ほぼ毎日その知性と正確さに驚かされてる。（暗号とは全然違うね。）

LLMが得意だと思うことが一つある。それはデータサイエンス。IOが明確だから、出力が正しいか簡単に確認できる。データの特性を知っていれば、テストを書くように頼むこともできる。ただ、LLMには君が何をしているのかの文脈が必要なんだ。その文脈をチャットで与えるのは難しいことが多い。ここでClaude Codeがゲームを変える。例えば、PCAPファイルがあって、各UDPパケットに複数のメッセージが含まれているとする。IP/ポート/プロトコル/時間をどうやってフィルタリングする？LLMを使って、出力を確認する。パターンA、AB、AAB、ABBを持つパケットの数をどうやって見つける？LLMを使って、出力を確認する。テスト用にそれらのパケットだけを含むPCAPをどうやって作る？LLMを使って、出力を確認する。などなど。コードを読めるから、君が何をしようとしているのかをより良いレートで推測できる。とにかく、「上記のすべての関数のユニットテストを書いてください」と頼めるのは、自己確認を手助けできるってことだ。

「思考パートナー」アプローチをしばらく試してみたけど、一瞬うまくいくと思ったんだ。でも、どこかでほころびが見え始めて、その嘘を見抜いた。LLMは、自分が知っているかのような幻想を作るのが得意だけど、実際には知的な会話を育むのが苦手なんだ。特に新しい分野に挑戦する時、LLMから知識を引き出そうとするのは危険に思える。普通の検索エンジンを使っていれば、情報の信頼性を判断するためにソースのウェブサイトを見ることができるけど、LLMにはそれがない。出力は本当に何でもあり得るし、間違いを見つけるのがそんなに簡単だとは思わない。

僕はLLM懐疑派としてこれを言うよ。すべてのコードは、経験豊富なコーダーが書いたものも含めて、本質的に確率的なんだ。それがあるから、コードレビューやユニットテスト、ペアプログラミング、ガイドラインやガードレールが重要なプロジェクトには必要なんだ。LLMの出力を批判的に使わないなら、それは間違ってるけど、人間の出力を批判的に使わないのも間違ってる。とはいえ、彼らは魔法じゃないし、僕が心配してるのは、人々がコパイロットやエージェントモデルを使って、悪いエンジニアリングプラクティスを隠すことだよ。効率や安全性、長期的に重要なことのためにリファクタリングや再設計をする代わりに、どんどんボイラープレートを作っていくのが心配なんだ。

NodeでのWeb開発のCRUD？

私は非自明なグリーンフィールド製品を出荷したことがあります。リンクをください。

LLMが出力するコードの質はかなり悪いと思う。何度も繰り返し作業をする羽目になって、結局自分でやった方が早いってことが多い。エージェントが実際に役立つのは、大規模な機械的なリフラクタリングをする時だね。完璧なvimマクロやASTリライトスクリプトを考える代わりに、エージェントを使うことにしてる。

毎日数時間Claude Codeを使ってるけど、あいつは嘘つきだから、使う時は自己責任でね。個人的には、あなたはその体験を美化してると思う。

同じような経験をしてる、ちょっと違う働き方だけど（博士課程の学生）。LLMには非常に懐疑的だったけど、Claude Codeが私の働き方を完全に変えた。_キュレーション_の要件はなくならないし、それは私の役割にしっかり残ってる（部分的には博士課程が教えるべきことだよ！なぜXをやるのか、Yで何を示したいのかを正確に考えること、すべてのステップを分解して、他の人に説明すること -- これは素晴らしいソフトスキルで、今は特に重要だと思う。これらのエージェントは持続的な世界モデルを持っていないし、相互作用のシーケンスの目標をすぐに忘れちゃうからね、賢い圧縮があっても）。もし私が正確なコミュニケーションを心がけているなら、CCを使って計算を整理することができる。これは今まで不可能だったことだよ。プログラミングより簡単ではないけど（質を気にするなら！）、違うやり方で、異なるイディオムがある。

でも僕の生産性は少なくとも3倍だったよ どうやってそれを測るの？

すべてのPRを出す前に自分で監査して、厳密にテストしてる どうやってそんなに早く信頼できないソースのコードを監査するの？LLMはプロジェクト全体を把握してないし、幻覚を起こしやすい。平均的に、君のプロンプトはどれくらいの長さで、LLMはユニットテストも書いてくれるの？

でも君は、ブログ記事が主張していることを全部確認しちゃったね。信じられないことを言ってるのに、証拠を何も共有してくれなかった。身元を隠すために使い捨てアカウントを登録するなんて、君の主張を検証するのを不可能にしてるよ。君のコメントは、俺には冗談みたいに感じる。

厳しいスタートアップで仕事を始めて数ヶ月経つけど、まだ手でコードを書いたことが一度もない。うわ、これかなり退屈そうだね。

「研究や計画、慎重に進めるプロセスがあって、エージェントを成功させるように設定したんだ。」 いい記事とか、あなたのプロセスをシェアしてくれる？本当にこれを上手くやりたいんだけど、エージェントの使い方がイマイチで、正直どこから始めればいいかわからない。クラインのメモリーバンクを試してみたり、もっと考える指示を使ってみたりしたけど、複雑なことをやらせるのができなくて、結局時間の無駄になっちゃってる。

クリプトに例えるのは怠慢な批判だよ。それを検証する価値もない。クリプトからのネガティブな雰囲気を再利用したい人たちのことだ。二つの技術は全く関係ないから、比較技術評価をする理由は明らかにない。でも、社会的な反応は、テクノロジー崇拝のトレンドで、長いこと業界にいるエンジニアたちは疲れてると思う。非現実的な主張は簡単に見つかるし、最悪なのはAI企業のCEOたちから出てくるものだよ。同時に、たくさんの人が実質的にコンピュータに疎い。基本的な自動化にすら限られた接触しかない人たちにとっては、どれだけワクワクすることか想像できるよ。SFで見慣れた「話すコンピュータ」が現実になりつつあるし、その中には様々な意見がある。すごいよ。AIの前に数年間MLとNLPで働いてたけど、今の状況はこれまでのどんな出来事よりも主流になってる。だから、統計的推論を使った設計の経験不足も多いだろうね。しばらくは意見や成功した実装、現実的なプロジェクトアイデアを形成するのが「西部開拓時代」になるだろう。こう考えてみて：今、友達が新しいアプリのアイデアを持っていたら、自分でやれって言われることができる。それは少なくともみんなにとっての勝利だね。

僕の推測では、1人のソフトウェアエンジニアに対して、100人がこの種の「手動データパイプライン」をやっていると思う。これはどんな会社に当てはまるの？500のホワイトカラーの仕事を調査して、すべてを分類してくれる人が本当に欲しい。真に自動化されているものはすでに自動化されてしまったと思う。AIが多くの混乱を引き起こすとは思うけど、ほとんどのホワイトカラーの仕事が「メール仕事」やデータ入力だけだという見方には非常に懐疑的だ。それは僕の経験とは全く合わないし、ここで言われているような過去に囚われた大きな官僚的な会社で働いてきたから。

定義はあるよ。「AIはまだやっていないこと。」

みんなが同じ意味で合意する必要はないよ。僕は「AGI」の定義について、もっと緩やかなマイルストーンを持ってるけど、他の人がそれを共有するとは期待してない。僕にとって「クリプト」はまだ暗号技術であって、暗号通貨じゃないから、時には主流が全然違う意見を持つこともある。

過剰評価がもたらすネガティブな影響を過小評価してると思うよ。市場を歪めて、過剰投資を引き起こし、部門を事前に削減させて、決して満たされない期待を生んでる。こういう記事は期待を冷やすために重要だと思う。LLMを売るとき、たいていは顧客サポートのコールを要約することについて話してるんじゃなくて、顧客サポートのスタッフを解雇するアイデアを売ろうとしてるんだよ。

君のコメントは、記事で著者が指摘しているコメントと同じくらいダメだよ。「90%」も少し怪しいね。

うーん、君は要するに「天気予報士」のセリフ「60%の確率で、いつも成功する」を引用してるんだね。僕も毎日Cursorを使ってGPTやClaudeを使ってるよ。GPT-3は一般的な知識検索にはまあまあいい。Claudeはすぐにダメになるけど、トークンを無駄に使ってる間に、実際の問題に気づかないことが多いんだ。モデルはバカで、バカサバンよりもバカだけど、時々は関連するアイテムにヒットすることもある。自分が何を求めているかを理解して、LLMを農場のラットテリアのように扱えば、うまく活用できるよ。