世界を動かす技術を、日本語で。

AI: 加速された無能

概要

  • LLM(大規模言語モデル)依存によるエンジニアリング能力低下の懸念
  • LLMは人間の批判的思考や設計力を代替できない
  • AI活用のリスクと人材育成への悪影響
  • プログラム理論とエントロピー管理は人間独自の能力
  • AIは道具として活用すべきで、依存は危険

LLM依存がもたらすエンジニアリングの危機

  • 2022年後半からのAI・LLMブーム により、ソフトウェア開発現場での利用が急増
  • LLMは「友達」ではなく、あくまでツール という認識の重要性
  • 生産性(速度)重視の風潮 が、思考力・設計力の低下を招く危険性
  • LLM活用によるリスク
    • 出力リスク :表面的な誤りだけでなく、見抜きにくいロジックバグ発生
    • 入力リスク :誤った前提や不完全な文脈でも無批判に回答
      • 例:本来1行で済む設計的回答が、LLM利用で200行の冗長なコードになる
    • 将来の生産性低下 :技術的負債の急拡大、保守性の低下
    • ユーザーの幼児化 :思考や問題解決をAIに委ねることで、個人・組織ともにスキルが衰退
    • 創造性・楽しさの喪失 :AI生成コードは読みにくく、開発の喜びやフロー体験を奪う

LLMと人間の本質的な違い

  • 「自分が不要になる」懸念の否定
    • LLMには置き換えられない領域が存在
  • 人間だけが担える2つの能力
    • プログラム理論(Program Theory)
      • Peter Naurによる「プログラムは設計・理論であり、ソースコードそのものではない」という考え方
      • 設計意図や理論を共有・内面化できるのは人間だけ
      • 例:同じコードでも設計意図を知るチームと知らないチームで保守性・拡張性が大きく異なる
    • プログラムエントロピー(Program Entropy)
      • Fred Brooksの「プログラムは保守を重ねるごとに複雑化(エントロピー増大)する」という指摘
      • 設計意図を守りつつ複雑化を抑えるのは人間の役割
      • LLMはテキスト処理しかできず、設計や複雑性の本質的理解ができない

LLM時代のエンジニアの価値

  • AIはコスト削減・効率化の道具
    • しかし、過度なAI依存は長期的なコスト増大や品質低下を招く
  • 本質的な技術力・思考力は今後も評価され続ける
  • AIは「杖」ではなく「道具」 として活用し、根本的なエンジニアリングスキルを磨き続ける重要性

今後の展望

  • AIやLLMの活用リスク・対策についての発信予定
  • 本質的なエンジニアリング力の価値は変わらない
  • AI時代でも人間の深い思考・設計力が求められる社会

Hackerたちの意見

3Dプリンティングが製造業を全部置き換えるって言ってたの覚えてる?誰かいる?

それともビットコインが銀行を置き換えるって?結局、ビットコインに基づいた金融ツールを売る銀行ができたよね。

これは簡単に言えることだけど、実は結構間違ってる。3Dプリントは多くの業界で大きなブレイクスルーをもたらして、現状を根本から変えたんだ。航空宇宙産業がいい例で、SpaceXや他の新興企業がやってることの多くは、3Dプリントされた部品がなければ実現できなかった。ノズルや燃焼室、ターボポンプなんかは、よくプリントされる部品だよ。

3Dプリントは徐々にもっと製造業に浸透していくよ。地味なステッピングモーターが本当に世界を変えてる。3DPはその一つの現れだね!でもAIの話に戻ると、あるハイプされたAIアプリ生成ツールのカスタマーサポートページを見たら、予想通りの内容だった。「複雑なプロジェクトには対応していない」「トークンを全部無駄にした」「返金の方法は?」みたいな。こういうのは過剰な期待を持たせていて、評価を正当化するには未来の奇跡が必要だね。奇跡が来るかどうかは分からないけど。

いい例えだね。3Dプリントは素晴らしくて、信じられないほど役立つ技術だ。本当に世界を変えるものだよ。でも、射出成形はこれからも残るだろうね。

正直言って、あんまり感じないけど、もしかしたらそのハイプサイクルは私の時代の前だったのかも。でも、これは不公平な比較に思える。まず、3Dプリントのおかげでエンジニアリングがより良くなったと思う(機械工学が得意だった頃ね)。プロトタイプを作ったり、ミスを早く安くできるから。全ての製造を置き換えたわけじゃないし、近づいてもいないけど、デザインにおいて重要な役割を果たしてるし、ユーザーのスキルを衰えさせることもないよ。

3Dプリンターを持っていて、部品をCADで作ったけど、射出成形工場は持ってないんだ。

シンギュラリティには至らないかもしれないけど、学術界で働いている人たちにとって、課題の設定や採点、講義ノートに関しては、良くも悪くもAIがものすごい影響を与えているよ。LLMが単にいくつかのシステム的な欠陥を露呈しただけだと主張することもできるけど、その影響は確かにある。2年前にはかなり標準的だった講義のワークフローが、今はもう通用しなくなっている。これには、コロナ後に多くの大学が投資を始めたオンライン教育やリモート教育全体が含まれていて、ちょうどその頃にChatGPTが登場したんだ。この影響を文脈に置くと、私たちは世界的に高等教育と中等教育のセクターについて話している。

小規模な製造には、3Dプリンティングが絶対にすごい。3Dプリンティングの大きな制限は、射出成形のように1時間に何千もの部品を生産することはできないってことだけど、それでも全然問題ないよ。射出成形の部品を作るには、最初に大きな投資が必要だからね。もし小ロットの部品を作っているなら、3Dプリンティングは初期コストを完全にスキップできるから、遅いマージナルタイムを十分に補ってくれるんだ。

それか3Dシネマ、あるいはVR。全部ただのハイプだよね。

それが真実じゃないとは言わないけど、ハードウェアとソフトウェアは異なる軌道を持ってるよね。

入力リスク。LLMは、導くプロンプトに対して挑戦しない…(強調は私のもの)これが私にとって一番の痛点で、もどかしいのは、自分が特定の方向に導いていることに気づかないことがあるってこと。LLMの動き方を考えれば納得できるけど、曖昧な言葉一つで結果が悪い方向に偏ることがあるんだよね。時には本当にやりたかったこととは逆の方向に行っちゃったりして、間違った道に迷い込むことも。気づいたときには、なんか適当に組み合わせたコードの泥沼にハマってて、ほとんど動いてるかどうかも怪しい状態。人間の言語がすごく曖昧で具体性がないから、正確さを求めるために形式的な言語を作ったわけだよね… 個人的には、AIツールのおかげで自分のスキルが急速に退化してる気がする。ちょっとしたタスクでも怠けて頼っちゃってたけど、実際に一歩引いてみると、あんまり時間を節約できてないことに気づいた。さらに悪いことに、AIが間違った部分を直すために何十行、何百行もコードを読んでると、すごく疲れちゃう。測ったことはないけど、トータルで見ると、AIツールで節約した時間よりもずっと無駄にしてる気がする。AIは多くのタスクに本当に役立つと思うけど、使ってる人は2つのグループに分かれてる。複雑なタスクで小さなミスがすぐに積み重なる人たちと、もう一方(私の経験では主にマネージャータイプ)は、理解できない200行のコードを見て、これが完成品だと思っちゃう。動くかどうかも怪しいTODOアプリが「MVP」として十分だって言って、「ほら、これを生成できるってことは、君の仕事も簡単にできるはずだ!」って。私が間違った使い方をしてるとか、違うモデルを試してるとかのコメントが来ると思うけど、私の経験については古いコメント[1]を読んでみてね。 [1] https://news.ycombinator.com/item?id=44055448

いやいや、全然違うよ![モデル名]と[coding product]を試すべきだよ。俺の生産性が100倍になったから!

今のところの私の経験では、問題解決のために別の意見をもらうのが役立ってる。そして最終的には自分が作業をする。あるいは、すごく具体的にして、比較的小さな問題を解決させると、AIがそれを解決してくれる—コードを書いてくれて、私はそれをレビューして、自分の基準を守るために変更を加える。つまり、AIは私のアシスタントだけど、質の高い、メンテナンスしやすい仕事をするのは私の責任なんだ。ただ、一般の人たちに考えてもらいたいのは、単純な計算機を考えてみて。計算機は人々の心の中での計算能力を奪った。AIは、ライティングやコミュニケーションスキル、問題解決スキルなどでも同じことをするだろうね。

AIのハイプは、ノーコーダーやおもちゃを作る仕事をしてる人たちの背中に乗っかってる感じがする(もし彼らに仕事があるとしても)。

この盛り上がりは、品質管理の法則を再発見する時代への準備段階だと思ってる。良い例が、昔からあるコカ・コーラとペプシの対比だね。

ほんと、みんなが「AIができる」と言ってから「実際にはモデルo2.7を使ってRAGのあるIDEでやって、プロンプトでどうやるか教えたらできたかもしれない」と目標を変えていくのに共感する。...まあ、ある時点で、自分でコードを書くのと比べて、労力に対して価値が少なくなるよね。とはいえ、AIは今のところいくつかのことを簡単にしてくれる。例えば、「これと同じページを作って、データはyの代わりにxを使って」みたいな例があるときは特に。ドキュメントを探すよりも早いことが多いし、ハルシネーションのリスクがあることを考慮してもね。もちろん、時間が経つにつれて改善するだろうし。私が見たい特定の改善点は、一般的に正しいことをすることとともに、常に「こうやってやれ」と言われなくても最もシンプルな解決策を見つけることだよ。私の経験では、chatgptやclaudeなどを自由に使わせる最大の欠点は、すぐに無駄なものを大量に出してしまうこと。未来に何かをするには複雑すぎるって言うこともなくね。TFAは、全体のデザインを理解することで人間だけがエントロピーに抵抗できると主張してるけど、それが改善されるかどうかは分からないけど、今のところ大きな問題に感じる。

でも、あいまいな使い方をした単語が結果を悪い方向に歪めるのに十分なんだ。こう感じてるのは私だけじゃないみたいで嬉しいよ。これらのモデルは、私のプロンプトのどこかにある特定のキーワードに執着して、伝統的な論理を無視して、元の問題を解決することすらできないニッチな道に私を押し込もうとするみたい。これが人間にとってのフラストレーションや不幸を増すだけなんだ。 > 体験的に、AIツールのおかげで自分のスキルが急速に退化してると感じてる。これに対抗するために、私は通常StackOverflowの結果で解決する問題をAIに解決させようとしてる。小さくて明確に定義されたタスクに対してね。「Xをどうやってやるの?」と検索する代わりに、今はモデルに同じ質問をして、その答えを問題解決のガイドとして使ってる。

正直に言うと、70%のスタッフは仕事を手抜きしてて、AIの方がマシなことも多い。実際の問題は、手抜きしてる人たちはAIと一緒でも無駄だってこと。残りの人たちはAIと共に学んで成長するだろうね。

大企業にとってはこれが真実で、これが私が読んだ中で一番のAIコーディングの意見かも。完全自動運転と似てる。FSDは、悪い運転手や酔っ払い、スマホをいじってる運転手よりも優れてるし、実際に道路にいる運転手の多くがそうだからね。

AIに仕事をアウトソーシングしてる人たちは、解雇されることを自ら望んでるようなもんだよ。コンピュータープログラムが自分の仕事をより良くできるって証明してるだけじゃなくて、その道を開いてるんだから!

それ、めっちゃ自己中心的な話だね。君はその30パーセントの一員なのかな?

「[AI]は概念的なレベルで働くことができない」って、著者はどこでそんな感覚を持ったんだろう。最近のLLMが何度も証明してるのは、文脈に応じて概念を正しく翻訳することで、彼らが確実に概念的なレベルで働けるってことだよ。「人間のように概念を理解していない」って言うのは別の話。痛みを「理解」することはないけど、経験がないからね。でも人間は、自分が直接経験したことのないことについても常に話すよね(実際、そうすべきじゃないかもしれないけど、それはまた別の話)。

彼らは、概念の代理としてのメトリカルな構造を持つトークンスペースで働いている。だから、この空間のあるポイントで「犬」というトークンの周りに集まるポイントに「近づく」ことができる。このモデルは、例えば「犬」と「猫」が関連しているというような概念のいくつかの特徴を弱くモデル化している。でも、例えば、構成や意図、反事実における用語の役割をモデル化しているわけではない(この問題については他のコメントでも触れている)。ただし、質問の種類がトレーニングデータに似ている場合、明らかなパフォーマンスを得るために力技で進むことはできる。例えば、「もし犬が火星で遊んだら、幸せだろうか?」みたいな質問があった場合、そういう質問のファミリーが似ていれば、「犬」のクラスターが「文字通りの事実」の周りに集まり、別の「犬」のクラスターが既知の反事実のサブセットの周りに集まることができる。この違いを本物のメンタル能力と比較したいなら、無限の深さを持つ概念の無限の組み合わせがあり、それを無限の数の反事実でフレーミングできることに注目してほしい。基本的な要素と想像力を持った子供は、この無限のバラエティを評価できる。だから、LLMが狭い分野(特にソフトウェアエンジニア)で最も使われているのは、彼らが必要とする「概念的な作業」が非常によく文書化されていて、十分に安定しているからなんだ。

人間は、自分が直接体験したことのないことについて常に話すよね。極端な例を挙げると、アファンタジアや共感覚、色盲についても、自分が体験していなくてもその概念を理解できるんだ。

たまに思うんだけど、AIによるコーディングの話はソフトウェアエンジニアとデータサイエンティスト/機械学習エンジニアの違いを反映してる気がする。両者とも不明確な要件で作業することが多いし、時には修正が難しいバグに直面することもあるけど、ほとんどの場合、ソフトウェアエンジニアは常に特定の方法で動作することが期待されるソフトウェアを作る。再現性があって、テストに合格できるし、ツールも確立されてる。機械学習エンジニアは確率的な性質を持つモデルを扱うから、通常のテストは特定の出力を生み出すことではなく、例えばモデルが90%のケースで正しい出力を出すかどうか(評価)に関するものだよ。ツールはソフトウェアエンジニア用ほど発展していないし、頻繁に変わる。だから、機械学習エンジニアにとって、常に信頼できるわけではないAIと仕事をするのは普通のことなんだ。彼らは確率や分布、許容できるエラーのレベルについて考えることに慣れてる。間違ったり予期しないコードを生成するかもしれないコーディングアシスタントにこの考え方を適用するのは、より自然に感じるよ。彼らはそれをモデルのように評価するかもしれない。「80%の確率で正しいコードを出してくれるから、手間が省けるし、20%は自分でチェックできる」ってね。

SWEは常に確率を使ってるよ。レースコンディションの周りを再設計するか、それともそのフットプリントを減らすか?このデータベースコールはどれくらいかかるかな、p99は?A/Bテストとかね。

自分の経験でも、だいたい50%くらいはそうだね。実際のシステムでMLを使いこなせる優秀なエンジニアもいるけど、サブドメインの専門家が開発したよく理解されたシステムを完全に置き換えると信じている人たちもいる。具体的な例を挙げると、アマゾンで働いていたとき、古典的なアプローチに頼れない現実の問題に対して、いくつかの本当に良いMLベースのソリューションがあった。例えば、グリッドマップからの動きの予測とか、画像やグリッドマップからの分類とかね。これらは非常に役立ち、古典的な推定と制御のパイプラインにうまく統合されて、意味のある結果を出していた。一方で、名前は出さないけどスタートアップで働いていたとき、低レベルのマネージャーから、静止した平面の向きを時間とともに推定するための学習ベースのアプローチに疑問を持つなんて、何度も叱責された。チーム全体がマッピングやフィルタリングについて基本的なことを学んでいなかったから、静止した物体に対してちらつく、飛び跳ねる、アドホックな回転推定を与えられていた。データが増えれば問題が解決すると思っていたんだ。このギャップは本当に存在していて、面接でうまく引き出せる方法があればいいのにと思う。

90%の正しい答えが全く足りないケースがたくさんある。もし利害関係者が、AIが全てに対応できるなんてことをみんなに納得させようとしなければ、誰もそんなことに問題を感じないだろう。この仮定のばかげたことは、論理で反論するのも難しいくらいひどい。これは信念に基づいた物語で、今までのところ、狂った投資を引き寄せるのに非常に成功しているし、利益重視の労働力最適化のためのトラヴェスティだ。

だから、MLEにとって、信頼性が常にあるわけじゃないAIと仕事するのは普通のことなんだ。彼らは確率や分布、許容できるエラーのレベルを考えることに慣れてる。間違ったり予想外のコードを生成するかもしれないコーディングアシスタントにこの考え方を適用するのは、自然に感じるんだろうね。彼らはそれをモデルのように評価するかもしれない。「80%の確率でコードが合ってるから、手間が省けるし、20%は自分でチェックすればいい」とかさ。今の状況を考えると、MLEは自分たちの考え方を他のグループに押し付けることに自信を持ってるみたい。会社の会議の後に、上司がそのことについて愚痴ってるのを聞いたことがあるよ。うちの会社は正確さと正しさが大きな売りの製品を売ってるのに、MLの人たち(別のオフィスにいる)がそれを理解してないみたいで、80-90%の正確さで十分だと思ってるみたい。パンデミックの病気の致死率が1%かどうかの議論を思い出すよ。1は最小の整数だけど、3億の1%は300万人だよね。

同意するけど、マネージャーとソフトウェアエンジニアの違いもあるのかな?前者(SWEチームリーダーも含めて)は、エンジニアが完璧じゃないことが分かってる。後者は、しばしば決定論にこだわって(これがうまくいく/いかない)いて、対立する目標に悩んでる。キャリアを通じて、SWEは最初は硬直的で目の前の問題に集中しすぎていて、システム(機械的または人間的)マネージャーになるにつれて柔軟でエラーに寛容になるんだ。これって、マネージャーがAIソリューションを好む理由に関連してると思う。新しい採用者と比べて有利だから、そしてその観察をするための文脈があるからね。

今、AIの修士課程を勉強中で(機械学習がたくさん)、ソフトウェアエンジニアとして新しいスキルを身につけてる感じ。で、MLE(機械学習エンジニアリング)を独立して考えることもできるし、ソフトウェアエンジニアリング全体の中でどう位置づけられるかも考えられる。頑丈なパイプラインを作ったり、アプリにモデルを統合したり、大規模なクラスターにモデルをデプロイしたりする方法を考えてる。純粋なMLEの人たちも多いけど、ソフトウェアエンジニアリングの視点が欠けてる気がする。特に、私のプログラムにいる多くの機械学習の人たちは、コンピュータ系じゃなくて数学や科学が専門の人が多い。機械学習は理解できても、コンピュータに対する親和性がないとソフトウェアエンジニアリングは難しいよね。真のフルスタックって、低レベルのシステムやバックエンド・フロントエンドのアーキテクチャ、デプロイメント、そして今はMLEを理解することだと思う。あとは、これらを持ってきた分、ちゃんと報酬をくれる人を見つけるだけ。ほとんどの求人はまだソフトウェアエンジニアかMLEの博士号を求めてるし。お金ちょうだい!!全部わかってるから。

決定論的な振る舞いと確率論的な振る舞いについて話してるんだね。確かに、君が言うことに合致する議論もあるけど、この記事はそうじゃないと思う。この記事は、ソフトウェアエンジニアリングをやっている人たちのメタな懸念と、AIがそれにどう関わるかに焦点を当ててる。プログラムのエントロピーについて話すとき、彼は的を射てると思う。ソフトウェア製品を作る上で重要なのはエントロピーの管理なんだ。具体的には、コードや人を増やしながら、合理的な進行速度を維持する方法だよね。もっと具体的には、システムを維持して、全ての人がどうやって全ての要素が組み合わさっているのか、そしてどうやって新しい要素を追加するのかを理解できるようにしなきゃいけない。AIがいつかこれを楽にしてくれるのは見えるけど、今は逆にエントロピーを悪化させることが多いよ。

GoogleマップやAppleマップのような地図技術についても似たようなことが言えると思う。これらを使うことで、物理的な世界をナビゲートするスキルが低下して、方向感覚や地理感覚が衰えてしまうってね。実際、それは間違ってないよ。今の人たちは、Googleマップのような助けがなければナビゲートに苦労することが多いからね。確かに、物理的な世界との関係は多くの面で変わった。でも、そもそもナビゲーションが得意だった人は少なかったんじゃない?特に不慣れな場所で、A地点からB地点に安全かつ確実に移動できる人の平均的な能力は、確実に劇的に向上していると思う。地理やナビゲーションに自然に優れた少数の人たちは、Googleマップのようなものによって自分の能力が補完されているだけで、置き換えられているわけじゃない。AIも、もっと大きなスケールで似たようなことになると思う。確かに、いくつかのトレードオフはあるし、スキルや能力が減少することもあるけど、それ以上に多くの人が以前はできなかった仕事ができるようになるし、ごく少数の人はさらに自分の得意分野で上達すると思う。

GoogleマップやAppleマップのような地図技術についても似たようなことが言えると思う。これらを使うことで、物理的な世界をナビゲートするスキルが低下して、方向感覚や地理感覚が衰えてしまうってね。実際、それは間違ってないよ。今の人たちは、Googleマップのような助けがなければナビゲートに苦労することが多いからね。全くの経験則だけど、私は逆のことを感じている。この地図ソフトを使うことで、ランダムな方向に歩いても、自信を持ってコースを修正できるし、一度どこかに歩いたら、その道は記憶にしっかり残るんだ。

人々がA地点からB地点に安全かつ確実に移動できる能力の全体的な平均は、特に不慣れな場所では確実に劇的に向上している。これに証拠はあるの?

GoogleやAppleの地図技術についても似たような議論ができると思う。問題は、地図ソフトウェアは信頼性があり、本質的にはランダムな数値を出すわけではないことだ。計算機と同じように、その出力を信頼できる。もちろん、地球全体をマッピングするのは非常に複雑な作業で、無数の注意点やエッジケースがあるけど、LLMの出力と比べれば? 同じプロンプトで温度設定を0にして何度も再生成しても、全く異なる出力が得られる。さらに、LLMははるかに広範な概念をカバーしているから、実際には使うべきでない状況でも、人々はこれを使うようになる。地図でも、Googleマップが「そこが道だ」と言ったから湖に突っ込む人がいるくらいだから、LLMの出力を盲目的に信じて思考を全て置き換えることがどれだけ危険か、想像もつかない。

信頼性の違いが大きすぎて、例えにならない。自分の住んでいるところでは、Googleマップはタクシードライバーより90%の確率で優れている。AIは、数日間その仕事をした人よりも優れているわけじゃない。

記事の前提にも、具体的な主張にも強く同意するよ。ただ、日常生活でLLMを使うことのポジティブな面にも気づいてきた。ちなみに、私はソフトウェア業界に約30年いるんだ。AI生成のコードを扱うことで強制されることの一つは、コードを読むことなんだ。開発は、最初の原則からのクリエイティブな旅というより、コードレビューの連続になる。これは、ソロ開発者にとっては有益だと思う。なぜなら、チームにしかない責任を模倣したり学ぶ手助けになるから。もう一つは、LLMと仕事をするには、開発者が問題を明確に定義し、よく構造化された階層的理解を持っている必要があることがすぐにわかる。大きなものを一発で解決しようとすると、たいていは自分の足を踏むことになるからね。デザインの観点から問題にアプローチして、詳細な仕様を書いてから、その一部を実装することで、概念的なビルディングブロックの境界やインターフェースを定義するのが助けになる。もっと観察があるけど、注意が散漫だから、結論として言うと。LLMを強力な加速剤として見ることができる。ジュニア開発者がシニアの役割に成長する手助けをしてくれるんだ。少しのガイダンスがあれば、これらのツールは、私たち経験豊富な人たちが学ぶのに時間をかけたレッスンの進行を明らかにしてくれる。全てが暗いわけじゃないと思う。AIが開発者を置き換えることはないし、今は非常に破壊的だけど、他のツールの中に落ち着くと思う(もしかしたら独自の棚に)。

それはアイデアや図、要件仕様について推論しない。(...) LLMがコードの複雑さを減らすのを見たことはどれくらいある? > 複雑さを減らしたり抵抗したりできるのは人間だけだ。こういう投稿の背後には本当に面白いコンセプトがあることが多いけど、具体的な主張は明らかに間違っていることが多いのが面白い。簡単にできることだよ:もっとシンプルなコードを求めるだけ。自分はそれをよく使って、セカンドオピニオンを得て素晴らしい結果を得ている。モデルに質問しなければ、複雑でもシンプルでも答えは得られない。デフォルトのオプションで質問しても、それは選択肢であって、LLMのアイデアに内在するものではない。自分はコードをアイデアや図に変換したり、その逆をしたりするのを楽しんでいる。なんで実際に毎日矛盾している強い主張をするのかな?

ジュニアエンジニアのコードをレビューしていて直面する大きな問題は、コードの質そのものではなく、解決策の方向性なんだ。LLMモデルが「なんでそうしたいの?」って質問してくれる能力があるかどうかはわからない(有名なStack Overflowの回答みたいにね)。

誰もコンピュータープログラムが文字通り自分の仲間だとは思ってないと思う。クラウドの製作者が言ったことを引用すると、 > AIシステムはもはや専門的な研究ツールではなく、日常的な学問の仲間だ。 > https://www.anthropic.com/news/anthropic-education-report-ho... アンスロピックのオープナーを大胆だとか、うざいとか、婉曲的だとか言うのは控えめすぎるね。これが牛乳のように腐ることを願ってるし、それが会社を恥ずかしめることになって、最終的には訂正の前書きや撤回が必要になるといいな。

ソフトウェアの世界で「エンジニアリング」という用語が他の世界とはまったく異なる意味を持つ問題だと思うけど、「LLMは人間のエンジニアリングを置き換えられない」というような発言をする記事を真剣に受け止めるのはちょっと難しいな。「もし君が熟練した経験豊富なエンジニアで、AIが君を雇用不可能にすることを恐れているなら、もっとニュアンスのある見方を持つべきだ」との返答に対してね。もし君がそんな推論ができるなら、ほとんどの「ソフトウェアエンジニアリング」の役割に就いている人が実際のエンジニアリングをしていないことも推論できるはずだよ。この記事は、ソフトウェア会社が「エンジニア」を雇っていると仮定しているけど、実際にはほとんどのソフトウェア会社は実際のエンジニアを雇っていないんだ。もしエンジニアがAIに置き換えられないとしても、君が実際にはエンジニアじゃないなら、AIに置き換えられるのかな?今のところその答えは分からないけど、「ソフトウェアエンジニアリング」の役割にいるほとんどの人にとっては、少なくとも今のところは「ノー」だと思う。でも、その理由はAIがエンジニアリングをできるかどうかとは関係ないはず。最後に、実際のエンジニアリングをやってると思ってるソフトウェアエンジニアの人には、実際のエンジニアリング分野を勉強することを勧めるよ。始めるための知的レベルは十分にあると思う。でも、電気工学、電子工学、機械工学、構造工学、排水工学などは、君の日常の仕事とは非常に基本的な部分で全く違うことにすぐ気づくと思うよ。