AI時代でも廃れない！GitHub CEOが語る「コードを書くこと」の重要性
引用元：https://news.ycombinator.com/item?id=44359938
他の投稿からの引用ね。なんでみんなシステムの仕様を決めるっていう本質的な複雑性についてもっと話さないんだろうって不思議なんだ。フレッド・ブルックスは「No Silver Bullet」で、ソフトウェア開発の難しい部分はツールとかの偶発的な複雑さじゃなくて、問題理解や仕様定義っていう本質的な複雑さにあるって言ってるんだ。彼のポイントは、核となる課題は概念的なもので、ツールじゃ魔法みたいに開発を楽にはできないってことだった。
今に話を移すと、AIエージェントが自然言語のプロンプトからコードベース全体を書くことでエンジニアを置き換えるっていう話がたくさんあるじゃん。でも、それは仕様定義の問題がなぜか解決された、もしくは単純になったって仮定してるように見えるんだ。実際には、曖昧なアイデアを詳細でしっかりしたシステムにするのが、いまだにエンジニアの核となる仕事だと感じるんだ。
もし誰かが詳細な仕様を提供して、AIと繰り返し作業してソフトウェアを構築するなら、それって単にAIを偶発的な複雑さをなくすために使ってるだけなんじゃないの—アセンブリから高レベル言語に移ったみたいに？それはエンジニアを置き換えるんじゃなくて、俺たちの生産性を上げるんだ。むしろ、イテレーションのコストを下げて、俺たちの影響力を拡大することで機会を増やすべきだよね。
じゃあ、これをどう整理する？もしエージェントがプロンプトからプロダクトを作るなら、それは誰か他の人がシステムを完全に仕様化した—暗黙的であれ明示的であれ—からこそ機能するんだ。そして、もし俺たちが単に既存のプロダクトを複製するためにAIを使ってるだけなら、それはもう技術的な問題を解決してるんじゃなくて、単に流通とかコストで競争してるだけだ。それはエンジニアリングの破壊じゃなくて—ビジネスの話だ。
俺が何か見落としてる？
核心は、仕様定義がAI以前から軽視されてきたってことだと思うな。ステークホルダー（クライアント、マネージャー）はずっと「雰囲気コーディング」をしてきたんだ。漠然とした説明を送ってきて、誰かが魔法みたいに解決策を返すんだ。その解決策が完全に機能してるかって？誰も知らない。なんか動くけど、確かなことは誰も知らない。
ほとんどの場合、実際にはプログラマーのドメイン知識が詳細を埋めてきたんだ（正しいフォーム送信ウェブページがどんなものか、みんな知ってるじゃん）。
今、その相手がAIになったけど、これが再現できるかはまだ様子を見る必要があるね。
あなたが抜かしてるのは、現代のウェブサイト構築がほとんどUI作業で膨大な開発時間食ってる部分だよ。それに現代のデプロイはブルックスの時代より100倍複雑になってるし。俺のプロジェクトの90%はこれら2つの部分なんだ。これこそ生産性がどれだけ下がったかを示してる（そしてAIが直せる）ってことだね。
答えが何なのかはっきりしないけど、LLMは本質的な複雑さ、つまり現実世界の問題に取り組むのを助けてくれるとは言えるね。
ビジネスが直面するほとんどの問題は、他のビジネスも経験してるはずだから。その知識が学習データにあるか、あるいはLLMがあなたの問題記述から第一原理に基づいて推論できるくらい、問題が簡単に推論できるかだろうね。
AIは「No Silver Bullet」の二分法の両方の側面で役立つんじゃないかと推測してるよ。
人々（特に実際の技術経験があまりない人や、何かを作るのが好きじゃない学生）は、ソフトウェアを書くのにたくさんの秘密めいたツールを学ぶ必要があると感じてるんだ。そして、その考えは、仕様を書ける人なら誰でもソフトウェアを作れるようになる、と約束することなんだ（そう、うまく仕様を決めるスキル—多くの依存スキルがある本当のスキル—は一旦棚上げね）。これがノーコードの約束だったんだけど、彼らはノーコードシステム（たいてい機能が限定的であることに加えて）が実際には複雑で専門的な学習が必要で、システムが強力になればなるほど学習量が増えることに気づいたんだ。LLMがSWEを置き換えるアプローチは、その別バージョンだね。システムを学ぶ必要がないから、自然言語でプロンプトを入力すればいいし、モデルが基盤となるシステムとのインターフェイス方法を知ってるから、自分でやる必要がないんだ。そういう意味では、「雰囲気コーディング」は既にこの目標の頂点なんだ（保守性の問題といった弱点があるにもかかわらず）。
マネージャーがSWEを排除したがる主な理由は、彼らとどう接すればいいかわからないからだと書かれているのを見たことがあるよ。LLMを使うことでその問題が解決するんだ、なぜならそれを操作するためにオタクが必要ないからね。
これはほとんど自業自得だと思うけどね。俺たちは複雑なデプロイを作って、 incrementalな節約が upfrontなコストを上回るだろうって約束するんだけど、実際にはめったにそうならない（それに隠れた複雑性のコストもある）。
だからAIは、俺たちがさらに手を広げて、もっと偶発的に複雑なシステムを作るのを許すだけになりそうだね。
「正しいフォーム送信ウェブページがどんなものか、みんな知ってるじゃん」だって？
世の中の何百万ものフォームが言いたいことがあるだろうね（笑）。
うん、2年くらいで「ねえAI、今日は何すればいい？」って聞くようになると思うよ。「はい、お客様が所有する個々のアカウント間での取引に苦労しているユーザーが増加していることに気づきました。マルチテナンシーの何らかの側面が、ユーザーベースのかなりの割合に暖かく受け入れられるようです。この点に関して、中規模および大規模なテクノロジー企業が採用したさまざまなアプローチに関するレポートを作成し、それぞれのユーザーフィードバックの要約を作成しました。これに基づき、私たちの業界、現在のユーザーベース、探求したい将来の市場、そして既存のインフラストラクチャに最も自然に適合させる能力というニュアンスを考慮して、これら3つのオプションのいずれかに絞り込みました。それぞれについて詳細な設計ドキュメントがここにあります。これには、影響を受けるすべてのダウンストリームサービス、すべてのデータスキーマの変更、下位互換性に関する懸念のリスト、ユーザーインターフェイスのニュアンスが含まれており、監視したいすべての新しい運用および採用メトリクスがあります。これらを読んで、どれを開始するか教えてください。質問や提案があれば喜んで受け付けます。最初のオプションについては、すでに指定された順序でコミットおよびデプロイする準備ができているPRのリストを準備しており、影響を受けるすべてのサービスのテストクラスターでe2eテストを実施し、現在テストクラスターで稼働中です。探索したい場合はどうぞ。他の2つのオプションについても、同じことをするのに数時間かかります。今日GOサインが出れば、他のプロジェクトと競合しないようにデプロイをシーケンスし、今週末までに本番環境に投入できます。それに加えて、機能が最も有用だと感じるユーザーへのコミュニケーションとオプションのトレーニングも行います。もちろん、懸念がある場合、別のアプローチを取りたい場合、または機能を進めるべきではないと考える場合は、これらのどれも変更、延期、または破棄することができます。」
自動化（「複雑なデプロイ」）の価値は、incrementalなコスト削減（つまり、同じ作業を何度も繰り返す必要がないから）だけじゃないよ。人間のエラーの削減または完全な排除もあるんだ。特に、インターネット上のソフトウェアをデプロイするようなセキュリティに敏感な活動の場合、そのコストはそれを自動化する時間の何桁も高くなる可能性があるんだ。
違いは、コーディング知識がない人でもソフトウェアを記述し始めて、エージェントにそのソフトウェアを繰り返し構築させることができるようになることだと思うんだ。だから例えば、機械エンジニアが何かシミュレーションツールを作りたいとするじゃん。その要件を定義して、何をしたいのか理解する必要はまだあるけど、その作業は（そして、これはまだ大きなもしもの話だけど、エージェントがこの種の作業に十分になったら）人間のプログラマーではなく、エージェントによって行われる可能性があるんだ。現時点ではそうなるとは思えないけど、それでもこれはダイナミクスを変えるんだ。それがシルバーバレットではないし、複雑さの多くは取り除くのが不可能だっていう点では君の言う通りだよ。でも、多くのユースケースでは、ソフトウェアエンジニアが間にいなくなるんじゃないかって思うんだ。大きなシステムはきっとそうだろうけど、多くの小さなビジネスソフトウェアではどうかな？
まあ、その頃にはエンジニアだけじゃなくて、他の仕事の人たちも失業してるってことさ :)
これ、まさに正論でピン留めしたいね。GenAIは現状、何が欲しいか分かんないPMとかに「そこそこ」の物を出して喜ばれてるだけ。巨大なデータセットのパターンで動くけど、人間は正しいか検証できないのに鵜呑みにする。衰退してる組織には救世主に見えるかもだけど、理解してる人にはツールの一つ。仕様を理解してる奴が勝つ、楽して儲けようとする奴は遅れるよ。
まあ、みんな分かってるってば。でも「正しい」フォームってのが人によって違うんだよ。
「正しいフォームのページがどんなかみんな分かってる」って？電話番号みたいに4分割されたり、検証バラバラだったり、1個だったり。分かってないってことだよ。
顧客が求めるのは「1900年の西部劇のバーにして」ってレベル。
でも実際いるのは、人生をごまかして生きてきた元中古車営業の学部生インターン、って感じだよ。
それは自動化のメリットだね。でも、ツールの複雑さとか商用製品の売りたいものとは関係ないみたい。例えば、一番複雑なデプロイが、一番エラー少なくて手がかからない、ってわけじゃないしね。
「何を見落としてる？」って？恐ろしく多くのソフトウェア開発者が、全然コード書けないんだよ。こういう奴らが簡単にAIに置き換えられる。
俺は元JavaScript書いてたけど、趣味で凄いことやる奴がいる一方、仕事じゃコピペで画面にテキスト出すのがやっとってのがザラだった。ドキュメントも書けないし実用的なこと何もできない。
どうすりゃいい？弁護士みたいに高い基準設けて、ダメな奴はクビだ。満たせない奴はジュニアか見習いで雇えよ。
AIで直せるの？
大体のその複雑さは、目立ちたいって気持ちから来てんだよ。
「弁護士みたいに高い基準で労働者を遠ざける」って？
それは世界がソフトウェアにお金出す気があるならね。だからせめて広告モデルを禁止するか、弁護士みたいに「承認されないとプログラム動かない」みたいな、普通の人ができない、絶対必要なことをやるかだよ。
IE時代にフロントエンドやっててさ、IE6とか10%くらいいた頃、デザイナーとピクセル調整に奮闘したのを思い出すよ。
複数のブラウザで見た目合わせるのって、LLMじゃ「良い見た目」の概念がないと無理だよね。
プログラマーはアーキテクチャの複雑さと格闘する必要はあるし、抽象化レイヤーは重要。
AIで構文とかリファクタリング、テストの面倒さが減ると、仕事はもっと純粋になる。
Jiraチケットに問題分解できる人がプログラマーになる時代がくるかもね。
プログラミングは言語じゃなく、コンピューターに何かさせるスキルだったんだよ。
ハイプサイクルは繰り返すだけだよ。
ツールに関わらず、ソフトウェア開発には本質的な複雑さが残るんだ。
選択肢の多さやチーム連携がボトルネック。
IDEとかローコードみたいな「開発者アクセラレーター」は、LLMも含め効果が誇張されがち。
「10x engineer」なんて話もあるけど、現実は普通。
今はLLMだけど、次はLISP Machines v2とかかな？
「仕様の問題を理解してる人が、AIみたいな変化で得する」って話、もっと詳しく聞かせて？
それって要は、ビジネスドメイン知識があって、コミュニケーションが上手いってこと？
AIは平均を目指す競争を助けるだけで、面白くない方向へ進む利点になるってことね。
リーダーはいらなくなるし、リーダーのスキルもなくなっちゃう。
まるでドラッグに酔った企業の騒ぎみたいだ。
コストを後回しにして、今だけ良いものを手に入れたいんだね。
失礼だけど、これどういう意味？
「皆知ってる」か「皆分からず、それぞれの考えがある」かのどっちかだけど、これって真逆じゃん。
何十年もひどいフォームを作り続けてきたのが、僕らが知らない証拠だよね。
HNで毎年「divを中央に寄せる方法」が話題になるのと同じさ :)。
みんなHolodeckみたいな技術は欲しいけど、それを実現するような資源が有り余る社会は求めてないんだね。
PM、data science、compliance、accountingとか、ほとんど自動化できるよね。
AIがあっという間に何でもやっちゃって、人間の仕事がなくなるかも。
OpenAIとかが産業全部乗っ取るとか？
残る仕事は、AIが地球を壊さないようにするsafeguardsくらいかな。
AIを「dumb down」する必要が出てくるかもね。
nuclear reactorみたいに制御しつつ、経済成長とバランス取るのが人間の役割になる？
100億通りの意見がある世界で、それができるかは不明だけど。
AIがソフトウェア開発でどこまでいけるか考える上で、本質的な複雑さと付随的な複雑さの区別はすごく大事な視点だね。多くの開発者が直感的に感じてるけど、なぜまだAIに置き換えられないのかをうまく言葉にできてない部分だと思う。
実際にAI（Claudeみたいなエージェント）を複雑なコードベースで使ってみると、ビジネス要件とか深いコンテキストを本当に理解できないから、ビジネス関連のコード変更は無理なんだ。でも、すごく小さなコンテキストのコード変更、つまり優秀な開発者の核心的な役割（現実世界の要件をシステムに翻訳すること）とは関係ない付随的な複雑さには役立つ。
ただ、俺たちの多くは技術的な問題じゃなくて、配布（Distribution）の問題を解決してるってことは軽視すべきじゃないな。まだジュニア開発者をAIに置き換える自信はないよ、一番の問題は自己修正能力がないことだ。でも、きっと試す人もいるだろうし、AI開発で成り立ってるビジネスは現実になって、既存のビジネスを安く請け負うようになるだろうね。それが全体的に良いか悪いかは、その混乱で職を失う人にとっては多分関係ない話だけど。
…だって、プログラミング言語がプログラムを正確に指定するのに適切なレベルの精度なんだもん。自然言語じゃ無理。もちろん、AIが作ったものをレビューして編集する必要はある。それに、変更内容を説明するより自分で変更した方が簡単なこともよくあるんだ。
Copilotを使うとソフトウェアのエラー率が上がるっていう独立した研究があるんだけど、この控えめな態度と何か関係があるのかな。AIを売ってるほとんどの人は人間の著者がいらなくなるって予測してるけどね。
Transformerはテスト自動化、より詳細な仕様作成、グリーンフィールドプロジェクトの加速、必要に応じた開発者の知識の迅速かつ正確な拡張、参照なしでの未知のAPIナビゲート、初期機能の構築、コードレビューなど、本当にたくさんのことに使えるんだ。
たとえコードがプログラムを指定するのに適した媒体だとしても、Transformerはその媒体と自然言語の自動インターフェースとして機能する。最新の高性能Transformerはコード生成に全く問題ないし、個人の知識をはるかに超える膨大な知識から恩恵を受けてるんだ。
”AIを売ってるほとんどの人は人間の著者がいらなくなるって予測してる”
本当に多くのプログラミング分野で俺たちがいらなくなる可能性は十分ある。それは単なる現実で、織工が自動織機のせいで大量解雇されたり、筆耕士が活版印刷の後に仕事を失ったり、高精度計算機が普及して人間計算機が役に立たなくなったのと同じさ。
この置き換えが明日とか来年とか、あるいは次の10年でさえ起きないかもしれないけど、能力のあるモデルを作れるのは明らかだ。残ってるのは、幻覚とか精度とかコストみたいなことに関する研究開発と、この新しいパラダイムを中心としたツールやインフラなんだ。でも、もう蓋は開いたし、日々の仕事に賢い自動化が入ってこないパラダイムには戻らないよ。プログラミングって文字通り物事を自動化することだし、Transformerは大きな前進だ。
でも、それは別に何でもない。君は好きなだけプログラミングの仕事に関わってていいんだ。給料をもらってプロフェッショナルとして働けるかどうかは、君の分野とかスキルレベルとか給与の希望による。でも、趣味や個人的なプロジェクトでいつでもプログラミングはできるし、どのくらい自動化を使うか自分で決めればいい。ただ、これらのツールを真剣に受け止めて、あまり軽視しない方がいいとはアドバイスするよ。そうしないと、パーソナルコンピュータやインターネットが登場した時みたいに、急速に進化する世界に取り残されちゃうかもしれないから。
もっとコメントを表示（1）
”最新の高性能Transformerは個人の知識をはるかに超える膨大な知識から恩恵を受けてる”
それはそうだけど、最初に試したことを元に戻して別のことを試すより、コードベース全体を喜んでゴミに変えちゃうんだよね。論理的な行き止まりから自分で抜け出せるAIはまだ見たことない。
ルーブ・ゴールドバーグみたいなコードを、きちんとした読みやすいコードに変えられる言語モデルを見せてくれたら、急にすごく興味を持つだろうね。それまでは、AIは反対のことしかできないみたいだから、俺はアンチのままだよ :)
AIの擬似的な創造性って、だんだん効果が薄れていかない？LLMの学習データを全部円の中に投げ込んでみて。もし全ての入力が他のLLMの出力から来るなら、円は決して大きくならない。人間は絶えず円の外に出るんだ。
たぶんLLMも円の外に出られるように改造できるだろうけど、今時点では猿がタイプしてるのと似たようなものだと思うよ。
君は円を小さく想像しすぎてるか、人間が円の外に出る頻度を過大評価してるかのどちらかだと思うな。典型的なプログラミングの仕事って、すごくたくさんの作業があるけど、そのどれも全くオリジナルのコンピュータサイエンスを生み出すわけじゃないんだ。現在のLLMはよく知られたUI/IO/CRUD/RESTパターンを少しの手間でカスタマイズできるし、これらは商業ソフトウェア開発の大部分を占めてる。
”それは単なる現実で、織工が自動織機のせいで大量解雇されたり、筆耕士が活版印刷の後に仕事を失ったり、高精度計算機が普及して人間計算機が役に立たなくなったのと同じさ”
ほら、こういうプログラマーの捉え方が全く理解できないんだよ。プログラミングはああいう仕事とは全然違う。「コードに過剰に執着して」「コードを書くこと」が自分の仕事だと思ってる連中が、「コード猿」って軽蔑的に呼ばれる理由があるんだ。CADがエンジニアを殺したか？ いや、殺してない。そんな考えは馬鹿げてるよ。
”プログラミングはああいう仕事とは全然違う”
その比喩が自動化と労働力削減についてであって、それぞれの職業には共通点と違いの両方があるってことは理解してると思うよ。好意的に解釈して、Hacker Newsのコメントは可能な限り良い意味で受け取るべきだ。
”「コードに過剰に執着して」「コードを書くこと」が自分の仕事だと思ってる連中が、「コード猿」って軽蔑的に呼ばれる理由があるんだ”
おかしいな。俺の経験では、「コード猿」はコードの質とか製品への影響なんてどうでもいいと思ってるから、プログラマーのままでいて、管理職とか製品責任者みたいな役割には進まないんだよね。むしろ、「コードに過剰に執着してる」のは、計算とその表現に深く興味があるコンピュータサイエンティストが多いよ。
”CADがエンジニアを殺したか？ いや、殺してない。そんな考えは馬鹿げてるよ”
もちろん殺してないさ。でも、製図工の減少には繋がった。今や製図工はより速く作業できるし、エンジニアや建築家は以前は製図工がやっていた多くのタスクをこなせるようになったからね。アメリカ労働統計局はこう言ってるよ[0]:
「コンピュータ支援設計（CAD）とビルディングインフォメーションモデリング（BIM）技術の使用により、予想される雇用減少が促進されるだろう。これらの技術は製図工の生産性を向上させ、エンジニアや建築家が以前は製図工が行っていた多くのタスクを実行できるようにする。」
同じように、俺が挙げた他の職業も、より高レベルな職業に吸収されたんだ。ソフトウェアエンジニアの将来の焦点は、プログラミングよりも製品設計や管理になるだろうと何度も言われてる。
俺はプロのキャリアを始めた10年前にこれを見て、最初から製品と設計に重点を置いて、コードを物事を成し遂げるためのツールとして使ってきた。それはコンピュータサイエンスを深く気にかけないってことじゃなくて、コーディングと製品開発はそれぞれ信じられないほど創造的にやりがいがあるし、それぞれの包括的な理解が世界を見て行動するための全く新しい方法を解き放つと俺は思うからだ。[0] https://www.bls.gov/ooh/architecture-and-engineering/drafter…
フレームワークとかローコードシステムは、何年も前からそういうことができたんだ。それでもプログラマーが置き換えられなかったのは、システムは時間とユーザーがいる限り、最終的には特別なユニークな存在になるからだよ。
成熟したコードベースでAIを使ってみると、生産性は10～20％くらいしか上がらない感じだ。まあまあだけど、人生が変わるほどじゃないね。
これは俺にとってはそうだな。こういうモデルに何か新しいものを書かせると、結果はまあまあだったりする。
でも、それを使って繰り返し作業を始めた途端…コードベースはめちゃくちゃになる。だって、コードを絶対消さないんだもん。絶対に。どんな問題を解決するためにも、常に新しいものを継ぎ足すだけで、既存のものでもっと保守しやすい方法で同じことを実現できるすごく明白な道がある時ですら、そうするんだ。
ルーブ・ゴールドバーグみたいなコードを、良い読みやすいコードに変えられる言語モデルを見せてくれたら、急にすごく興味を持つだろうね。それまでは、AIは反対のことしかできないように見えるから、俺はまだアンチのままだよ :)
ChatGPTが出てから3年で20%も効率が上がったって、これマジでデカい。たとえこれで止まったとしても、自分の役割の人が2割減るってことだろ？つまり、何万人もの仕事がなくなるってことだよ。
まあ、完全に反対ってわけじゃないけど、プログラマーを全部置き換えるAIって、もう超人レベルじゃん。人間のアウトプットと同じくらいできて、計算ははるかに速いし、休憩もいらない。そうなったら、プログラマーが仕事なくなるってより、「ほとんどの仕事がなくなる」ってレベルの話だと思うけどね。
これについてはちょっと確信ないな。コーディングにはユニークな特性があって、人間にはスキルいるけど、AIには簡単なところがあるかも。
- 失敗のコストが低い: 物理とかコンプライアンスとか、他の分野は大抵失敗コストが高いから、確認する人の価値が高いんだよね。コーディングにはこの贅沢さがない。
- やり直しやシミュレーションのコストが低い: 実験をたくさん同時にやって、一番いい結果を選べる。AIがおかしなコード作っても、エージェントとかツールがエラー受け取って、何度も試行錯誤できる。ユニットテストとかコンパイラエラーとかがこれを簡単にしてる。
- 正解がたくさんある: いい感じのソフトで十分な分野も多い（CRUDみたいなWebアプリとか）。全部じゃないけど、ソフトウェアの多くの分野がそう。
難しい知的作業かどうかじゃなくて、物理的な世界（エネルギーとか材料費とか）とか規制（仕事が成果だけじゃない）とか、そういうボトルネックの方がAI化を止めるんじゃない？
それは、現在の文脈の限界と、質の良いツールやプロンプトがないことの組み合わせだよ。よく設計されたエージェントなら、適切な文脈とgitみたいなツールへのアクセスがあれば、コードをロールバックすることだって絶対にできる。コンテキストとかメッセージ履歴をクリアすることだって、機能が公開されていればエージェントにとって実行可能になるんだ。
＞ 失敗のコストが低い: 物理とかコンプライアンスとか、他の分野は大抵失敗コストが高いから、確認する人の価値が高いんだよね。
これは全然理にかなってないね。物理とかコンプライアンスの世界に触れるコードだってある。空港とか飛行機、病院、クレーン、水道システム、軍隊、これら全部、程度の差こそあれコードを使ってる。ランディングページで実験する余裕はあるかもしれないけど、そういうところが日常的に従業員とかクライアントに混乱を引き起こす余裕があるとは思えないな。
＞ 実際に、いろんなプログラミングの分野で僕らが時代遅れになる可能性は十分にあるんだ。それはただの現実さ…
それは現実じゃないよ、だって起こってないから。現実世界では起こってない。今の進歩率がこのまま続くって信じる理由はない。知能って織機とは違うんだ。ソフトウェアエンジニアは人間電卓じゃないんだから。
構造化されたレビューパスとエージェントのルール（例えば、「古いコードを廃止できるか検討してください」みたいな単純なものでも）の組み合わせが、君のエージェントワークフローに何をもたらすか、驚くと思うよ。
＞ レゴブロックを組み合わせたみたいにごちゃごちゃしたコードを、読みやすいちゃんとしたコードに変えられる言語モデルを見せてくれたら、急に興味持つんだけどな。
彼らはもうこれできるよ。もし具体的なコード例があるなら、君のために実験して、もしそれで君が真剣に現代のエージェントワークフローを試してくれるなら、結果を報告するよ。
義父は製図工だったんだ。90年代に国防産業が縮小した時に仕事を失った。新しい仕事を探したけど、どれもCADが必要で、彼は経験がなかった（学習障害もあったから、CADを覚えるのが難しかった）。それから、最低賃金より高い仕事には就けなかったんだ。
当時は業界にいなかったから直接は見てないけど、高水準言語が出てきた時も、同じ批判があったのかな？高水準言語は精密さが足りないとか、プログラマーはメモリで何が起きてるか直接操作したいのに、高水準言語だと精密さが足りない、みたいな感じの批判。
自然言語の問題は、精密さが不可能ってことじゃなくて、ほとんどの人がそうじゃないか、自分がAIに何をしてほしいかには精密だけど、コンピューターがそれを実現するために何をする必要があるかには精密じゃないってこと。これのせいで、エンジニアがビジネス要件をコードに翻訳しようとする時に、たくさん推測することになる。今はLLMがその推測をやってて、大抵はビジネス全体の目的とか、その要件を書いた人たちの理解とか、そういう文脈が少ない中でやってるんだ。
＞ 実際に、「コードに過度に執着してる」人たちって、計算とその表現に深く興味があるコンピューターサイエンティストであることが多いんだ。
君はどんな学者たちと付き合ってるの？俺が会ったコンピューターサイエンティストは全員、メジャーバージョンが上がるたびにこうなるプロジェクトを持ってるよ:「この実験的なカーネルには本当に満足してたんだけど、ホットパッチ機能があるといいかなって思って、古いコードベースは捨てて最初からやり直したんだ。」
君がやってる仕事が斬新で最先端であればあるほど、レガシーコードは害になるんだ。
AIエージェントがコードを書けるか？絶対イエス。
でも、存在しないライブラリとか関数を幻覚見てコンテキストを汚染したら、実際には失敗するんじゃない？絶対そうなる。
それがエージェントと一緒に働く上での難しいところだよね。
＞コードベース全体をゴミに変えちゃうだろうし、最初の試みがダメでも他の方法を試すより元に戻すことも喜んでやらないだろう。
それは全然違うね…。喜んでるフリしてるだけだよ。
俺たちが「コードに過度に執着する」って言葉を違う解釈で捉えてるせいで、俺のコメントが誤解されてるんだと思う。
俺の場合、特定のコードじゃなくて、コードそのものに対する深い感謝のことを言ってるんだ。
うわ、それは悲しい話だね。人生をかけて職人技を習得したのに、突然それが陳腐化して、一番いい時期が過ぎちゃったってのはマジで最悪だ。お父さんにお悔やみ申し上げます。
産業革命が進むにつれて、こういう現象はどんどん増えてるみたいだね。ドラフティング（製図）の技術は紀元前2000年まで遡る[0]けど、数千年の間に技法や要件は徐々に変わってきたのに、デジタル革命でドラフティングや他の多くの職人技が一気に激変した。これで多くの人がリカバリーできなかったリテラシーギャップが生まれた。
エンジニアやデベロッパーの間でも、エージェントやLLMのリテラシーに関して似たような分断が見られるのかね。
[0] https://azon.com/2023/02/16/rare-historical-photos/
＞それは単なる現実だ、自動織機の後に機織り職人が大量解雇されたように
彼らはただ解雇されただけじゃないんだ。ナポレオン戦争や米英戦争が続いて経済が不安定だったし、当時の繊維生産への設備投資もすごく変動してた。彼らは巨大な富の格差に直面していて、ほとんどの人が職を失うことは全てを失うことだった。
多くのラッダイト支持者がイングランド各地で要求していたのは、より良い労働条件、最低賃金引き上げ、児童労働廃止などだったんだ。サボタージュは、ほとんど全ての権力を持っていた階級にそうした要求を突きつける手段だったんだよ。
デモ参加者の多くは撃たれた。生き残って解雇された者は救貧院送りになった。
資本家が勝って、歴史と神話を書いた。彼らは問題をテクノロジーのせいにして、労働条件のせいにはしなかった。彼らは、職を追われた労働者が他の場所で新しい、より良い仕事を見つけたと言ったんだ。
プログラマーは労働者階級の一部ではあるけど、これまではるかに有利な交渉力を持っていて、それに見合う補償を得てきた。俺たちの多くも、AIの出力品質について、織物労働者が安物のレースの品質について文句を言ったように不満を言う。でも幸い、救貧院は閉鎖された。
ただし、質の低いコードは、人々の人生の貯蓄を失わせたり、IDを盗まれたりすることにつながる傾向がある。安物のレースよりはるかにリスクが高いね。
歴史は繰り返してないけど、確かに韻を踏んでる。
「全てのソフトウェアがこうじゃないけど、多くの分野はそうだ」って俺も言ったよ。だから君に同意する。
あと、例えば物理的な領域だと、コミットしてデプロイするまで「壊す」のが高コストなのに対して（つまりコード作業中）、IDEやシェルなんかで試行錯誤したり洗練させたりできることに注意してくれ。結局は単なるテキストファイルだし、最終的に公開する前の最後の検証ステップは君の責任だ。検証ステップや、本番システムに行く前のゲートが必要ないとは言ってないよ。ただ、動かない「幻覚」を捨てたり、モデルのギャップをイテレーション／リトライ／複数のバージョンで回避してユーザーが満足するまでできるって言ってるんだ。
逆に、AIに家を建ててもらって、気に入らないからそれを解体してちょっと違うのを建て直す、とか、ユーザーが「この製品で満足です、どうぞ進めてください」と言うまで、なんてことは物理的に無理だろ。それをやるためのリソースの無駄遣いと時間の消費は膨大だろうね。
AIでシミュレーションしたりプランを生成したりはできるかもしれないけど、特に予算やリソースがない場合に、物理的なものを「作り直す／変更する」のには敵わないね。
TL;DR（要するに）イテレーション／失敗のコストが大きいほど、統計モデルのギャップをイテレーションでカバーできる可能性は低くなる（つまり、テールのリスクに噛みつかれる可能性が高く／緩和するのが難しくなる）。
公平に言うと、彼は今それが現実だとは言ってないよ、可能性が現実だって言ったんだ。少なくとも俺はそう読んだ。
で、うん、俺もそれは現実の可能性だと思うね。
俺のClaudeは、自分で詰まった時にgit restoreして別の方法を試すのを喜んでやるよ ;)
人間はごく稀に枠の外に出るだけだという点には同意するけど、一部の人はたまにそうするのに対して、LLMは決してそうしないっていう直感があるんだ。この違いは、LLM対人間の仕事を長い時間軸で考えるときに重要だと思う。
でも、LLMがなぜ決して枠の外に出ないのか、はっきり説明できないんだ。だって、LLMはtemperatureを通じていくらかのランダムなノイズをシードされてるからね。俺が間違ってるだけかもしれない。
「10年前にプロフェッショナルキャリアの始まりでこれを見て、最初から製品とデザインにフォーカスしてきた」
俺も君と同じような未来観を持ってるよ。でも、引用されたテキストが実際どういう意味かただ気になるだけだ。例えば、ソフトウェアエンジニアじゃなくてプロダクトマネジメントに行ったの？
＞驚くだろうね
そうは思わないな。色々なAIを extensively に試したし、使ってる人とも仕事したけど、ひどい結果が全てを物語ってるよ。
＞もうできるよ。具体的なコード例があれば教えて
もちろん。LinuxカーネルのBluetoothドライバーには、過去10年で oversight がほとんどなく積み上がった、大量のひどい重複コードがあるんだ。 https：＼＼code.wbinvd.org＼cgit＼linux＼tree＼drivers＼bluetooth
この重複ロジックを共通部分にリファクタリングして、ドライバーをもっとシンプルに再構築できるLLMがあれば、俺にとってすごくすごく役に立つだろうね。これで数千行はコードを削除できるはず。
これを段階的に、俺がレビューして正しいと確認できる小さなパッチの連なりでやってくれる必要がある。巨大なパッチを一つだけ吐き出すなら、やらない方がマシだ。だって俺は100％正しくなきゃいけないシステム系の仕事をしてるから、AIを信頼できないんだ。
君はAIでこれができるって見せてくれよ :）
ReactじゃなくてPhoenix LiveViewで内部ツール作った時に得られた生産性向上より、全然たいしたことないよ。
生産性10-20％向上なんて、俺のキャリアの中でしょっちゅう起きてたこと。たいていは非効率なプロセスで無駄になるか、もっと複雑なシステム作るのに使われるかだ。
Railsがリリースされた時は、特定の種類のプロジェクトだと、ほぼ overnight で3倍か4倍速く動けたんだから。
AIは共通パターンを大量のコードに適用するのはすごく得意だけど、自分が何をやってるのか「アイデア」は全く持ってないんだ。
たった数時間前に遭遇した新鮮な例があるよ。ポップアップのサイズを計算してから、別にトップ左の角を計算するコードをリファクタリングする必要があったんだ。
簡潔にするために、片方はifを使って、もう片方はswitchを使ってたんだ。<br> if （orientation == Dock.Left || orientation == Dock.Right）<br> size = ＼* horizontal placement *＼<br> else<br> size = ＼* vertical placement *＼<br> var point = orientation switch<br> {<br> Dock.Left =＞ ...<br> Dock.Right =＞ ...<br> Dock.Top =＞ ...<br> Dock.Bottom =＞ ...<br> }；<br>
LLMに、ポジションをすぐに適用するんじゃなくて、保存するようにリファクタリングさせたかったんだけど、異なるもの（ifとswitch）が似たようなことをやってるのを全く扱えなかったんだ。色々な指示を試したけど、ifを二つにするか、switchを二つにするかにすごく偏るんだ。そうしないようにかなり explicit に指示したのに。
ある意味うなずける。モデルがifを「完了」して、次に似たようなことの必要性に遭遇すると、またifを選ぶんだ。だって前のトークンを completion してるんだからね。
ここでは harmless だけど、もう少し自明じゃない例だと、 nuance を無視して、良さそうに見えるけど変な方法で失敗するコードを生成するだろうね。
とはいえ、曖昧さがない小さなタスクに分割するのはすごくうまくいくよ。「サイズを m_StateStorage に保存して render 時に適用」って言う方が、コードの5か所を手動で編集するよりずっと簡単だ。特に Cerebras みたいな、複雑なコードを秒間数 kilobytes で処理できるやつなら、シンプルな考えを物理的に typing するより速く展開できる。
もっとコメントを表示（2）
＞AIは共通パターンを大量のコードに非常に効率的に適用できるが、それが何をしているかという固有の「アイデア」を持っていない。
AIは Artificial Intelligence の略だ。AIができること、理解できることに inherent な限界なんてないよ。君が specifically に批判してるのは、今日の popular なモデル、specifically な Transformer モデルとその tooling の capability だ。これは急速に進化している landscape で、君の主張は1ヶ月後には、ましてや1年、5年後には関係なくなってるかもしれない。実際、君の批判は current なモデル間でも関係ないかもしれない。モデル間の idiosyncrasies について話すのは一つのことだけど、 strict procedure と controls を伴う comprehensive な multi-model review の outside で描かれた broad な結論は、 massive な grain of salt と共に受け取られるべきだし、 capabilities について authoritative な言葉を使うのを避けるように注意すべきだ。
君が何を critiquing しているのか precise にした方が useful だ。そうすればその critique が実際に merit と applicability を持つからだ。Even saying “LLM” is a misnomer, as modern transformer models are multi-modal and trained on much more than just textual language.
俺はLLMに coding tasks を delegate するためのGUIを開発してるから、routine に bunch のモデルで色々な実験をしてるんだ。このケースでは、Claude Sonnet 3.7 は全然問題なく handling できたけど、Llama-3.3-70B は全くできなかった。でも、それは文字通り問題を示す simplest な例だよ。
top-notch なLLMにもっと難しいタスク（parser から来る abstract syntax tree を特定のやり方で scan して、特定のものの nodes を生成する）を試させた時、彼らは completely に blew it。compile すらしないし、logical errors と missed points は言うまでもない。でも、問題を relevant な parsing contexts の lists を作成することと、at a time に一つの wrapper class を生成することに breakdown したら、a whole ton of work を save してくれた。通常 a week かかるところを a day で accomplish できたよ。
maybe 彼らは eventually に figure it out するかもしれないし、maybe しないかもしれない。Point は、right now technology には fundamental な limitations があるってことだ。そして、blindly に black box を trusting するより、how to work around them を knowing した方が you are better off だ。
うん、まさにその通り。
これは以下の組み合わせだと思うんだ。
1）prompting の granularity のレベルが間違ってる
2）engineering experience の欠如
3）一つの hallucination が whole experience を台無しにすることに関する autistic rigidity
4）自分の jerbs への threat に対する subconscious anxiety
5）the tide に逆らうことへの unnecessary guilt。 anything pro AI は Reddit で heavily に downvoted されるし、here では at best 、controversial as hell だ。
俺は、for one 、literally に a product per day を last month 出荷したし、それは amazing だ。literally に 2,000,000+ impressions 、paying users 、almost 100 sign ups across the various products 。I am fucking flying。Hit the front page of Reddit と HN countless times in the last month。
Idk if I break down the prompts better or what 。But this is production grade shit and I don’t even remember the last time I wrote more than two consecutive lines of code。
LLMが arbitrary な X、Y、Z を always（someday）できるようになる、みたいな sweeping な generalizations にも、俺はあまり興味ないな。
君が出荷した30個のプロダクトのリンクを提供できる？
みんながLLMでどれだけ god damn に productive なのか聞くたびに、俺が使おうとすると、信頼できる working code を生成できないんだ。通常は at first は正しく見えるものを生成するんだけど、either は work しない（at all か as intended か）。
君のリストを見ていこうか。
1．if the problem is that I need to be very specific with how I want LLM to fix the issue, like providing it the solution, why wouldn’t I just make the change myself？
2．I don’t even know how you can think that not vibe coding means you lack experience
3．Yes。If the model keeps trying to use non-existent language feature or completely made up functions＼classes that is a problem and nothing to do with “autism”
4．This is what all AI maximalists want to think；that only reason why average software developer isn’t knee deep in AI swamp with them is that they are luddites who are just scared for their jobs。I personally am not as I have not seen LLMs actually being useful for anything but replacing google searches。
5．I don’t know why you keep bringing up Reddit so much。I also don’t quite get who is going against the tide here, are you going against the tide of the downvotes or am I for not using LLMs to “fucking fly”？
＞でもこれは production grade の shit だ
I truly hope it is, because…
＞そして、俺は最後に2行以上のコードを続けて書いたのがいつか remember すらしない
これは catastrophic な error があった場合、君は probably に it yourself を fix できないってことを意味する。
「LLMに細かく指示するなら自分で書く方が速い？」って言うけど、俺は105wpmでもGPT-4.1は1000wpmだよ。コードより短いプロンプトで解決できるならGPT-4.1の方が速い。間違えることもあるけど、2、3回やり直してもだよ。経験がないとミスに気づけないけど使いこなせば生産性上がるし俺は速くなった。Google検索以外にもLLMは有用で、俺はこれで前よりずっとコード書けてるんだ。生産性が上がったって事実を否定できないでしょ？
LLM使うと叩かれることについて、俺に役に立つツールを批判されるのは理解できないね。結局みんな俺の経験談を信じてないだけだと思うけど、俺は速くコード書けててコードも動く。LLMは最高のツールだしもっと良くなる。なんで使わないの？
LLMの改善が無限に続くわけじゃないってことを指摘したいだけ。限界があるって信じる理由は十分あるよ。
未来のAIの話じゃなくて、今使える技術の話を批判すべきでしょ。明日良くなるかもしれないけど、まだそうじゃない。みんなコメントの日付読めるし。
人間は計算やコンピューターサイエンスの限界を押し進め続けるし、最近の進歩が研究開発を加速させると思う。Deepseekとかdemosceneみたいに古いハードでも凄いことできる。物理限界がきてもソフト最適化とか理論の進歩でまだまだ伸びしろがある。コンピューターサイエンスはまだ若い分野で、人類レベルAIは可能だ。問題はエネルギーと資源だけだよ。
俺はOPをscoldしてない。正確な言葉で、全体じゃなく特定の技術への批判に焦点を当てて欲しかっただけ。急速に進化する状況で、制約や注意書きなしに能力を断定すべきじゃない。感情的にならずに議論しようよ。
OPは経験を具体的に話してて面白かったよ。もしかしてその長文、ChatGPTに書かせたの？
タイピング速度より考えるのが大事だし、LLMにプロンプト書くより自分で直す方が速いよ。君の「経験不足」ってLLM知らんだけって意味？C++仕様なんてLLMに貼らんし。君のプロフィール見ると、LLMで速くなったって主張は信じられないな。みんな儲け話はするけど証拠がないんだよ。LLM使うことへの批判は君の気のせいじゃないと思うけど。君のコメントは「autism」とか「経験不足」とか非難っぽくて全然charitableじゃないし。ツールの批判を個人的に受け止めないで。LLMのhypeに見合う証拠がまだないんだよ。
2000年頃からニューラルネットワークを知ってるけど、大きな進歩はChatGPT 3.5から4が最後で2年以上前だよ。AIの歴史には長い停滞期もあったし、次の大ジャンプがいつかは分からない。今は曲線が平坦化してる感じで、また新しい革命が必要だね。
＞AIは共通パターンを大量のコードに効率よく適用できるけど、自分が何してるかの固有の「アイデア」はないんだよね。
これは全然「すごく正確」じゃないし、時間的な制約がないのが問題な理由を君をパトロンみたいに扱って説明するつもりはないよ、前のコメントでやったから。まだ混乱してるなら、文を何度か読んで理解するといいね。OPはどのモデルを使ったか具体的に言ってないし、具体的なprompt例も提供してないんだ。
＞君の饒舌な返信はChatGPTで書いてるの？
たった数段落の返信で対応できないか、時間の無駄だと思うなら、議論をやめてもいいんだよ。Hacker Newsのガイドラインは、実質的な応答を推奨してるからね。
あと、将来的にChatGPTを使ってるってユーザーを非難するのはサイトのガイドライン違反になるだろうから、今のうちからそういうレパートリーはやめた方がいいかもしれないね。
Hacker Newsのコメントガイドラインからいくつか抜粋するよ：
- 嫌味にならないで
- コメントは、話題が二極化するにつれて、思考を深め、実質的になるべきで、そうじゃないのはダメ
- 善意を前提として
- アストロターフィング、シリング、ブリゲーディング、外国のエージェントなどのほのめかしを投稿しないでね。それは議論を劣化させるし、たいてい間違ってるから。
https://news.ycombinator.com/newsguidelines.html
その毎日出荷される製品も見てみたいな。Redditで見るのは、違うカテゴリなだけで同じクイズが何度も作られてるのと、ピクセルアートジェネレーターだけだよね。それは君が主張するような毎日製品を出荷してるようには見えないな。
返信ありがとう。
みんな、考えるのに5分以上かかるような、どんな仕事してるの？
僕にとっては、作業は乗り越えられないほど無限にあるけど、解決策を思いつくのはそんなに難しくないんだ。自慢してるんじゃなくて、こういうことなんだよ：
ソフトウェアエンジニアリングで遭遇する問題の99.9999999999%で、僕より賢い誰かが既に実戦で試された解決策を書いてて、それを使うべきなんだ。RedisとかNginxとかPostgresとかね。あるいは深さ優先探索や幅優先探索みたいなパラダイムだったり、単にHash Setを使うだけとか。たまにBloom filtersみたいにもう少しクレイジーなのもあるけど、まあいいや。
君たちは研究論文や自分の頭の中にしか存在しない、新しいデータ構造やアルゴリズムを常に実装してるの？
5年か10年もエンジニアリングしてれば、見るべきものはほとんど全部見たことになるよ。その時点でほとんどの解決策は頭の中にキャッシュされてるはず。そして仕事は単調で重要じゃない実装の詳細に帰結するだけなんだ。
もしかして、みんながまだpolymorphismとかオブジェクト指向のくだらないことで行き詰まってることを忘れてるのかな。フラットなstructsだけ使えば、そんなに複雑なことは何も起こり得ないよ。
ちなみにHFTで働いてたけど、それは非常にインテンスでCRUDじゃない「真の」エンジニアリングと見なされるべきだね。それなら、LLMも少し苦労するかもしれないことには同意する。でもそれでも狂ったようなものじゃないよ。
ソフトウェアエンジニアリングは極めて定型的だよ。だからこそ、LLMで統計的にモデル化するのがすごく簡単なんだ。
ずいぶん長文だけど、これが以下の主張と矛盾するかい？
＞AIは共通パターンを大量のコードに効率よく適用できるけど、自分が何してるかの固有の「アイデア」はないんだよね。
君はAIが自分が何してるかの固有のアイデアを持ってる、あるいはそれ以上のことしてるって言ってるの？今日現在？
ここはインフォーマルな議論の場だよ。求めるハードルは厳密な演繹的証明じゃないと思うんだ。上記のことは僕の経験とも一致するしね。インターネット検索の便利な応用インタラクティブ版だよ。
もし違う経験をした人がいたら、それは興味深いだろうね。でもこれは単なる意味論に関する自己満足に見えるけど。
本アカじゃないよ、自分でDoxするつもりはないからね。AI賛成派は個人的なブランディングには明らかにfaux pasだよね。
たった数日前、GameTorchにユーザーが62人しかいないって叩かれたばかりだよ。今は91人に増えて、有料購読者も増えた。全部LLMで書かれてて、一度も落ちてないんだ。僕は評論家じゃなくて、ビルダーでいたいんだよね。
人は自分が落ちてる穴から這い上がるより、君をその穴に引きずり下ろしたがるものだよ。
組み込みソフトウェアをC++で、産業用アプリケーション向けに書いてるよ。独自のプロトコルやカスタムハードウェアがたくさんあるんだ。プロトコルや製品、ドキュメントでLLMを訓練するイニシアチブもいくつかあるんだけど、結果には感心してないね。エンドツーエンドのテストフレームワークも同じ。あまり一般的じゃないから結果がすごくばらつくんだろうね。
8年間やってきて、見たものはたくさんあるけど、flash、memory、性能の制約があるから解決策をコピペするだけじゃダメなんだ。
繰り返しになるけど、これはスキルの問題かもしれないし、LLMに置き換えられるかもしれないけど、今のところクールなおもちゃみたいに見えるよ。World of WarcraftのAddOnsを書くのにLLMを使ったことはあるよ、僕のLuaの知識はほとんど独自のプロトコル用のWireshark pluginを書く程度だからね。それには良かったけど、それはLuaやWoW APIを実際に扱ってる人ならもっと速く、あるいは同じくらい速く作れるものなんだ。だって、自分が何をしたいか説明して、LLMが提供するAPIが存在するか、LLMが想定した通りに動くか試さないといけないからね。
＞そして、コンピュータサイエンスという分野が、他の何十万年も続いてきた人間の実践と比べて、どれほど若いかを覚えておいてね。
Homo sapiensが地球にどれくらいいると思ってて、文明はどれくらい前からあると思ってんの？
僕は89年からプログラミングしてるよ。10万年で何が詰め込めるかは分かってる。
でも高密度のトランジスタ配列に、全体が溶けて電子がレールを飛び越えるまで、電力を大量に流し込むことしかできないんだ。その限界にはずいぶん前に達してる。命令のキャッシュ、ローディング、実行の最適化はたくさんやってきた。レジスタの前に大量のキャッシングを詰め込んだ。線形代数の計算を実行するのに特化したチップを設計し、限界までスケーリングしてきたんだ。
AIは、全体的にチップの数をスケーリングすることに基づいて構築されてる。その結果、莫大な電力が必要になるんだ。そして熱の放散も。だから新しいデータセンターをたくさん建設してるんだ：それぞれが土地、水、そして他の用途の需要レベルを維持するための新しい発電源（そのほとんどがmethaneとcoal plants）を必要としてる…
確かに、訓練における局所的な最適化を見つけて、資本コストや外部コストを下げられるかもしれない…でも、このインフラを構築してる規模からすれば、それは焼け石に水だろうね。基本的にここでやってるのは、スケールアップを力技でやってるんだよ。
そしてコンピュータサイエンスは、君が思ってるより古いかもしれないね。昔はlogicって呼んでただけだよ。物理的なコンピュータを実現するにはいくつかの電気工学の革新が必要だったけど、計算の理論的な理解はそれらが現れるよりかなり前からあったんだ。
若い分野だ、そうだね、そしてまだ長い道のりがある…かもしれない！
でもイノベーションは魔法だと信じないでおこうよ。ここには厳密な科学と工学がある。電子は決まった速さでしか移動できない。トランジスタ密度は決まった量しかスケーリングできない、とかね。
同意。AI企業は基本モデルを改善できてないから、「エージェント」みたいにアドオンを作る方にピボットしてるみたいだね。それは基本モデルの上に指示が乗ってるだけに見えるよ。
同意だよ。そして人類文明が生き残るなら、エネルギーと資源についての君の懸念は、文明のスケールで見れば短期間の問題にすぎないだろうね。特にモデルがもっと効率的になるにつれて。
人間の脳はたった20ワットしか電力を使わないんだから、何十億年にもわたる進化の洗練を使わずとも、原理的にはもっと大きな電力を使うことで人間レベルの知能に到達可能に見えるよ。
X、Y、Zと時間を定義すると、面白い疑問が生まれるね。例えば、LLMがP=NP問題を2週間、6ヶ月、5年、1世紀で解決できるか？そして、その理由を探索することだね。
