でも、ボイラープレートコード生成を超えて見ると、LLMが経験豊富な開発者の生産性を本当に上げているわけではないことが分かるよ（彼らがそう信じていてもね）：https://arxiv.org/abs/2507.09089 編集：ダウンボートした人たち、どの点が間違っていると思ったのか教えてほしいな。これがHNでの一般的なナラティブに反しているからなのか、それとも全く別の理由なのか。

あなたには[ ... ]がある。次に[ ... ]がある。 実際のLLMの使用とは別の何かで定義されたグループで、あまり面白くないね。面白いのは、コード生成のためにLLMを使ってみて全く役に立たなかった人たちがいること。逆に、LLMを使ってコードを生成してみて、非常にうまくいったと信じている人たちもいる。

「それに、代わりがいないと思いたい技術系の社員もいる。」昔のように働き続けたい気持ちは分かるし、2022年以前のソフトウェアの採用や収入に戻りたいという希望もあるよね。でも、AIがそれを妨げてる。最終的には、LLMベースの新しいツールの限界が分かるようになって、人間がどこで大きな価値を加えられるかも見えてくるはず。それが最大限の採用ブームを引き起こすと思う。人が増えれば増えるほど、作業のスピードも上がるし、今度こそコードの質が大きく下がることはないかも。LLMがさらに出力の質を向上させて、エンジニアリングのワークフローが正常化すればだけど。希望的な見方だけどね。カスタマーサービスみたいな顧客志向の仕事には本当に申し訳ない気持ちになる。2020年以降、特にAIチャットボットやAIサポートラインがこの職種を壊滅させる傾向を見てきた。これらは一般的なホワイトカラーの仕事で、私たちの業界でも多くの人がサポートラインからスタートしてるからね。

わからないけど、私はソフトウェアエンジニアじゃない。システム管理者だ。もしくは「DevOpsエンジニア」？それとも「SRE」？それともプラットフォームエンジニア？正直、わからない。知ってるのは、みんなが私の仕事を無くそうとして、結局は違う肩書きでお金をもっともらおうとするってこと。やってることや使ってるツールは同じなのに、自分たちを納得させるために「実際には以前とは物質的に違う仕事だ」って言い訳するんだよね（でも、実際はそうじゃない）。20年経ってもまだ雇われてるし。私はソフトウェアエンジニアじゃないし、テクノロジーのCEOでもない。気にしないけど、キャリアの中でずっと置き換えられようとしてる（自分自身もね。「自動化して仕事を奪われる」っていうのはシステム管理者の一般的なマントラだし）。それでも、なんだかんだでまだここにいる。

「昔のように働き続けたい気持ちは分かる」そんな「昔の働き方」なんてないよ。安定した状態なんて存在しなかった。ソフトウェア開発はずっと、シンプルな部分の進化と自動化が常に進んできたんだから。 >「2022年以前のソフトウェアの採用や収入に戻りたいという希望もある」AIがそれを妨げてるわけじゃない。生産性の向上は、影響を受ける分野の需要や収入を減らすわけじゃないからね。（厳しい金融政策や経済の減速は、特に同時に起こると影響が大きいけど、スタートアップや既存企業の新しいベンチャーに投機的な投資が多い分野では特にそう。）

労働の価値が下がったよね。契約を見積もったけど、AIがあるから今はもっと短い時間でやってほしいって言われた。これで同じ仕事に対して報酬が減るんだ。AIのCEOたちは「社会は少ない仕事をするようになる」って言ってるけど、実際には今の方がもっと多くの仕事を求められてる。技術の進歩と同じだね。

ちょっと言いにくいことかもしれないけど、もしソフトウェアエンジニアリングがもうお金が稼げる場所じゃなくなったら、その仕事がなくなっても他のことに適応できる自信があるよ。俺は頭が良いし、一生懸命働くから。俺より頭が良くない人の仕事を奪う自信がある。賢い人と良い労働倫理を持った人は必要だと思うし、みんなが仕事を失うわけじゃない限り、そうなると思う。そうなったら、俺にとってはもうシンギュラリティのイベントホライズンを超えてるし、全ての賭けは無効になる。

自律的なLLMエージェントが未来の波だと言うのは早すぎるかもしれないけど、今のところそんな感じだね。AIのコード補完は素晴らしいけど、基本的にはより良いStack Overflowって感じ。Stack Overflowが開発者を失業させるって心配してた人はあんまりいなかったから、改善版が出ても心配してないよ。

LinkedInを見てると、今の求人市場ではシニアテックエグゼクティブがみんな生成AIの専門家になってるのが面白い。2020年に彼らがこんなに投稿してた時は、みんな暗号通貨の専門家だと思ってたからね。

なんでテックのCEOやCTOはAIが自分たちの仕事を「破壊」することに気づかないんだろう？誰でもコードが書けるなら、なんで君の会社にソフトウェアを作ってもらう必要があるの？非開発の仕事もAIの影響を受けると思う。今ならマーケティングコピーやHRポリシー、プロジェクトプランを同じかそれ以上のクオリティで生成できるからね。

AIはただのオートコンプリートだよ。AIが法律文書を書くとどうなるか見てみれば、なぜソフトウェア開発者を置き換えることができないのかがわかるよ。

いいポイントだね。対面での仕事はリモートワークよりも帯域幅が高く、レイテンシが低いから、特定の役割ではリモートワーカーに任せたくないのもわかる。仕事の質が微妙に劣化することがあって、それが苦手な人もいるからね。人間にタスクを渡すのとLLMに渡すのでは、前もって考えるのが難しいコンテキストペナルティがあると思う。基本的には、LLMがタスクをこなすためにどんなシステムプロンプトが必要か、そして継続的なコンテキストストリームがどうなるかを最善の推測で決めることになる。でも、これらは複雑な評価パイプラインがない限り、比較的静的だと思う。だから、人間の労働者はタスクが変わったときに新しいコンテキストを見つけるのが早いと思う。カスタマーサービスがその代表例だね。多くのカスタマーサービスのタスクはLLMで処理できるけど、コンテキストを早く集められる人間が優れているエッジケースがたくさんあると思う。これが、Klarnaが今年初めにLLMに全力投球するという決定を覆した理由だと思う。

確率的に正しいっていうのは、ある程度の閾値までの話だよね？9がいくつか並ぶと、まあ大丈夫だし。最近はAIを使って質問を投げかけたり、問題の理解を深めたり、既存のパターンやトレンドを深く調査したりして、その結果をプランニングセッションの文脈に使ってる。アーキテクチャのための文脈も提供されるしね。だから、ツールが本質的に右寄りに進むとは思わないんだ。

「短期的には大丈夫だけど、長期的にはもっとお金がかかる」それがAIが普及しない理由の一つだと思う。ソフトウェアを作るのがどれだけ複雑か理解してない人たちの短期的な考え方だから。長期的に安くソフトウェアを生産する方法も知らないしね。ボーイングが航空業界で厳しい状況にあるのも、まさにその理由だと思う。5年後に破産したくないならAIを使うべきじゃないけど、今すぐに金持ちになりたいなら別だね。技術的な観点から見るとあなたの分析は理にかなってるけど、結論がAIが普及する理由になってる。今すぐ金持ちになりたい人たちが長い間権力を握ってきたし、私たち技術者が「これは永遠には続かない」と言っても、すぐに止まるとは思えない。

短期的な考え方をしてる人たちが、ソフトウェアの複雑さを理解してないのが皮肉だよね。AIがあれば、誰が長期的に考えてるか、誰がそうじゃないかがちょっと分かりやすくなるかも（上層部も現場も）。 > 「5年後に破産したいならAIを使え。でも今は金持ちになりたいなら、AIを使ってさっさと抜けて、他の誰かに5年後に破産させればいい」って感じかな。

もっと広い視点で見ると、左側を見てみると：構想 -> 設計 -> コンパイラ -> コードレビュー... AIツールがより良い迅速なプロトタイピングを可能にするなら、構想や設計の段階で「エラー」を見つけるのに役立つかもしれないね。でも、実際どれくらい役に立つかは分からないけど。

業界はエラーを左に押し出そうとしている。これは本当？ほとんどのソフトウェア開発者はそうしたいと思ってるけど、ビジネスはスピードにもっと興味があると思う。エラーを右に押し出す方が、ほとんどのソフトウェアでは利益が出るみたいだし。10年も前からあるものでもね。

あなたはコード生成のためにLLMを見てるけど、それだけがソフトウェアエンジニアリングの応用じゃないよ。うちの会社では、何人かが自分のコードを生成するためにLLMを使ってるけど、もっと多くの人が同僚にレビューを依頼する前に初めてのコードレビューを得るために使ってる。これで簡単なことや細かいことを先に片付けられるから、フィードバック+修正のサイクルを1回減らせることが多い。例えば、「このユニットテストを変更したけど、ユニットテストの名前を更新してない」とか、「この関数を変更したけどドキュメントの文字列を更新してない」とか、「これらのif文を並べ替えれば深いネストを避けられる」とか。特に画期的なことではないけど、いいことだよね。レビューは前と同じようにやってるけど、「どうやって」よりも「何を」ちょっとだけ集中できることが多い。この使い方では、LLMはあまり厳密でないルールのリンターみたいな感じ。最近は多くの言語が標準フォーマッターを持ってるからって、コードレビューをやめたわけじゃないしね。AIのコード生成の側面が今はすごく注目されてるけど（記事を引用すると）： > あなたが気にかけている領域で、AIに本当に関連している具体的な変化に焦点を当ててください。

これは本当にイライラするんだけど、面白いことに、時間をかけて人間を助けるためのツールがたくさん作られてきたのに、AIのコーディングツールはそれを無視してるんだよね。最高のAIコーディングツールは、ドキュメントのウェブサイトやターミナルのエラーメッセージを読み取ったり、テストを書いたり実行したりするけど、実際には使われてないもっといいツールがたくさんあるんだ。* プロファイラー * デバッガー * リンター * 静的解析ツール * ランゲージサーバープロトコル * ワイヤープロトコルアナライザー * デコンパイラー * コールグラフアナライザー * データベース構造クローラー もし完璧なワンショットソフトウェアエンジニアリングができるモデルがないなら、しっかり統合されたツールの使い方に頼るしかないけど、まだ誰もそれをうまくやってないみたい。

でも、PythonやJSでエクサバイト単位のコードが書かれてるよね… それって、すべてがコンパイル時に押し込まれてるっていう君の話には合わないと思う。C#、Java、Goは確かに人気だけど、他の言語に対してそんなに成長してるのかな？もし間違ってなければ、Rustは主にCやC++で使われてたプロジェクトで採用されてるみたいだよ。

これは最近聞いた中で一番いい意見だね。LLMのハイプに乗ってる友達や同僚に、蓄積されたエラーやエントロピーの厄介さ、コードに関わる必要があるときに人間のボトルネックが不均衡になることについて、少し違った形で説明してきたんだけど、君の言い回しはこれらをうまくまとめてる。ありがとう！

この議論で言うべきことをうまく表現してくれてありがとう。エラーを左に押しやるか右に押しやるかっていうのはすごくいいメタファーだし、メンタルモデルについてのメタファーも素晴らしいね。それに、自然言語が問題を適切に説明できない理由についての君のコメントも良かった。時には制約が解決プロセス中に発見されることがあるし、問題が適切に説明できるなら、それがプログラミング言語だっていうのもいいね。自然言語が問題を適切に説明できるなら、それは形式言語になる。失敗したプロジェクトを経験したエンジニアだけが君の言ってることを理解できるだろうし、AIマニアに取りつかれている人たちもすぐにそれを理解するようになるよ。

「カーボンキャプチャ」って、なんか特定すぎない？

フレッド・ブルックスは「1つのバージョンは捨てるつもりで計画しろ、そうすることになるから」と言ったけど、彼が見落としたのは、捨てない1つのバージョンはほぼ永遠にメンテナンスしなきゃならないってことだよね。（SaaSの登場を見抜けなかったのは責められないかな？）もしAIの本当の価値がこの両側にあったらどうなる？ * デモ中に使う捨てバージョンをすぐに作って、潜在顧客からフィードバックを集めて、どこが壊れるかを見る。これで10倍、100倍のスピードアップができて、役に立たない「フル」バージョンを作らずに済めば素晴らしいROIになるかも。 * その後、「ちゃんとした」システムを「古い」方法で作る。AIを強化版のオートコンプリートとして使って、1.5倍、2倍のスピードアップを狙う。 * それから、時間がないからやらないこと（テストやドキュメントなど）をLLMを使ってやる。ここでは、やらなかったら無限のスピードアップがあるし、価値があったらね。でも、権力者は次の機能に取り掛かるように君に求めるだろうね。 * LLMがバグを直すのにどう役立つかは分からないけど。要するに、2つのコードベースの「レーン」が並行して進化してる感じかな。1つはAI/人間比率が90/10、もう1つは30/70くらい？AIは早く積み上げるために、人間は耐えるために使う？