この地理的保護は、ほとんどの場合、非常におかしいと思う。私の意見では、彼の主張を弱めている。

「ハンドメイドネットワーク」って、要するにこれなんだよね（いい意味で）。LLMがコード生成に十分なレベルになるずっと前から、無味乾燥な「企業向けソフトウェア開発」に対抗する哲学として存在してた。10行で実装できる機能が、1000行の「業界のベストプラクティス」のボイラープレートに包まれるのが普通になってる。LLMを使ったプログラミングは、量を重視する工業化されたソフトウェア開発のニッチの論理的な結論なんだ。要するに、アーキテクチャの宇宙飛行士が書いた仕様を考えずにコードに変換する人間のボットを置き換えてるだけ。そんな「仕様を書いてコードを出す」みたいなプログラミングは、そもそも存在すべきじゃなかった。アーキテクチャの宇宙飛行士たちが、実際に自分の技術を大切にしているプログラマーを煩わせることなく、LLMでアイデアを実現できるようにしてあげよう ;)

あなたは著者のポイントを見落としている。彼は「裁判所が判断を下すべきではない」と言ったんだから、それは「無罪が証明されるまで有罪」とは真逆だよ。有罪というのは裁判所が判断を下したということ。彼は全く判断を下さないことを提案している。AI企業が何かを主張するなら、それを証明しなきゃならない。科学のようにね。どんな主張も単なる主張として扱われる。トリックは、何も主張せずに、ユーザーが自分でそれが魔法だと結論づけるようにすること。確かに、LLMは設計上、出所を引用できないから、何かを作り上げたのか、意味があるのか、ただコピー＆ペーストしたのか、機能するものかクソなのか、あるいは素晴らしい新しいものを作り出したのかを教えることはできない。私たちが見るのは成功のストーリーだけ。n回目の試行とプロンプトの調整、エージェントを正しく扱うプロセスの後の成功だけ。隠れたコストはそこにあって、ほとんど隠れていない。この曖昧さはAI企業に利益をもたらしていて、彼らはそれを最大限に利用している。多くの国で禁止されているエンティティから違法に海賊版の知的財産を取得し、それを利用パイプラインの一端で売って、他の端では「史上最大のもの」として販売するところまで行っている。そして、AIが世界を支配するという終末的な話は、マーケティングのハイプの一部だよ。

抽象化はタダじゃないよ… たとえ正しい抽象化と、デプロイに必要ない部分を取り除くためのツールがあったとしても、理解とコンパイルのコストはまだ残るからね。それに、誰かが抽象化を売ろうとしたら、マネタイズしようとするから、みんなが使いたいと思うわけじゃないし（オープンや無料だと永遠に終わらないかもしれない）。プラットフォームのロックインや競争の側面もあるし…

しばらく前に本を書いたんだけど、コーディングは何に取り組むかを選び、それを書き、デバッグすることだと主張したんだ。そして、私たちはこれらのステップを逆の時間順で習得する傾向がある。最近のことを見て、今読むとどれだけ古く感じるか不思議だよ。チューリングテストについても書いたけど、AI開発の大きなマイルストーンとして扱われているのに、実際にはチューリングテストを通過したプログラムに対する一般的な反応は、肩をすくめて軽視することだった。

これは、テクノロジーの考え方と、唯一の「ボイラープレート冗長コード」が言語そのもので、アイデアや哲学の緩やかな集合体である多くの作家やアーティストとの間の考え方の違いを示す、非常に洞察に満ちたコメントだね。おそらく、ここでの元の罪は、彼らを「プログラミング言語」と呼び始めたことだと思う。あと、あなたの作品は単なる新奇性以上のものだよ！知的労働や時間のような無形のものがあるからね。

ライブラリは境界を作るけど、それはほとんどの場合恣意的で、コードとのインタラクションの仕方を制限して、ライブラリから欲しいものを得るためのボイラープレートを増やすんだ。抽象化は肥大化の原因だよ。抽象化がなければ、常に肥大化を減らすことができるし、グルーの中で肥大化を減らすこともできるけど、グルー自体を減らすことはできない。恣意的な関数シグネチャや短命の中間データ構造、型定義を作らないためには、規律が必要なんだ。これがボイラープレートの始まりだよ。ボイラープレートを取り除くための多くの進歩は、あなたの5つの関数呼び出しと10の中間データ構造や型定義が、実際には0の関数呼び出しと0のカスタムデータ型、そして少ない行数でできることを認識することなんだ。抽象化は、あなたが欲しいものがどれだけシンプルかを隠す。問題は、すべてのオープンソースコードが上で説明した肥大化のように見えるから、LLMはボイラープレートなしで実際にコードを書く方法が分からないことなんだ。私が見た中でうまくいったのはシェーダーだけで、通常は抽象化の一般的な落とし穴を避けるように書かれている。LLMは、あなたが欲しいことをする1つの関数と1つのファイルで大きなプログラムを書くことができない。プログラムを関数や複数のファイルに分割するのは、多くの時間が経った後に行うステップだけど、すべてのオープンソースはそんな感じじゃない。

本って、結局は数百ページのテンプレートに過ぎないシンプルなテーマや主張だよね。

いや、同意できないな。「ボイラープレート」だからって、価値がないとか新しさがないわけじゃないよ。家や車など、色んなものを作る時には「ボイラープレート」があるけど、本当に新しいものを加えるためには「いつも同じ基盤」が必要なんだ。その基盤をしっかり作ることに価値があるんだよ。技術や深い知識、誇りを持ってね。プロジェクトはそれぞれ違うし、全てが一般的な市販品から作れるわけじゃない。

実際、これがLLM革命の悲劇的な結果の一つだと思う。プログラミングの人間工学的な進歩に資金を得るのが難しかったのに、新しいプログラミング言語のエコシステムや大規模なライブラリに資金を提供するのは簡単じゃなかった。それでも、抽象化のレベルを大幅に上げる可能性のある進展がいくつかあった。しかし、LLMはこの経済的インセンティブを完全に壊してしまった。今では、かなり低レベルのTypeScriptでコードを書くのが最も生産的に思えるし、機械が大量のゴミコードを吐き出すのを見ている感じだよ。

最も単調で反復的な作業をしている人たちは、最も生産性の低い環境で働いていることが多いんだ。速度や生産性を上げる明確な方法があるのにね。もし開発のスピードが本当に重要な要素なら、あの「四人組」のJava 8コードベースからはとっくに移行してるはずだし、彼らにオフィスや少なくとも騒音を減らすためのキュービクルを与えているはずだ。儀式的な会議に1日3時間も費やさせるなんてことはないはず。これらが実現しない理由は、たとえ開発者が10倍速くコードを書けたとしても、組織の慣性や非効率を乗り越える頃には、変化がほとんど感じられないからなんだ。新しいオフィスの費用や2年間のリファクタリングの努力は、もっと具体的に感じられるけどね。

「私たちの仕事のほとんどは、ボイラープレートの冗長なコードに対する小さな新しさだ…」 その意見を証明する例をいくつか教えてくれない？

次の数段落を読めば、著者がこれに触れているよ：

とはいえ、Steamのポリシーは最近、プレイヤーに提示されるコンテンツを生成するために使われない「効率向上」のための開発ツールを除外するように更新された。最初の段落だけ引用したけど、もっとあるよ。

それに、「AI」はゲーム、特にモバイルゲームの中で、もう10年も前から存在してるんだ。名の知れたゲームスタジオは、特定のスタイルを使って素早くアートを作成できるカスタムAIアート資産ツールを長いこと持ってる。AIは道具で、スティーブ・ジョブズが言ったように、持ち方を間違えることもある。整形手術みたいなもので、悪い例だけ目につくし、それに反対する。専門家は良い例を見抜けるかもしれないけど、一般の人は知らないし、ほとんどの場合、誰かが気にしろと言わない限り気にしない。そしたら、すべてをAIのせいにするんだよね。

LLMは私の時間を節約したことがない。いつも、うまくいかないものを生み出して、私が欲しいものの大まかな形はあるけど、詳細がいつも間違ってる。自分が欲しいことをもっと早くタイプできるし、少なくとも正しい問題を解決していることは確信できる、たとえバグがあってもね。ボイラープレートを生成するためのツールも、LLMよりずっとずっと良く機能するし、決定論的なんだ。

これを悪いことだとどうして思えるのか分からない。人は、自分の生活がかかってると思えば、色んなことをこじつけるもんだよ。AIが全て悪いっていう反応は、「AGIはもうここにある」っていうのと同じくらいおかしいと思う。 > スポアは高く評価されてるし、マインクラフトは歴代最も売れたゲームだよ。反論として、プロシージャルな地形生成を使った初期の有名なゲームの一つであるオブリビオンは、当時はすごく魂がないように感じた。結局、全てはどれだけ上手く実行されるかの問題だと思う。最良のケースでは、熟練したアーティストが自動化を使って機械的な作業を補完する（例えば、ルネサンスのアーティストが自分の傑作の全ての筆致を自分で描かなかったのと同じように）。最悪の場合（あるいは平均的な場合？時間が教えてくれるだろうけど）、人間が作った芸術的な決定がほとんど流れ込まず、出力が過去にやったことの平均的な mediocre なものになってしまい、それが正当に「スラップ」として認識される。

そうそう、まさにその通り。LLMは開発者が他の開発者が何千回もやってきたことを繰り返す時間を節約してくれる。これを悪いことだとどうして思えるのか分からない。何度も同じことを書いてる理由を考えたことある？それがエンジニアとしての基本的な部分だよ。近くに完璧な車輪があるのに、車輪を再発明してる時を理解することが大事なんだ。

そうだね、まさにその通り。LLMは、他の開発者が何度もやったことを繰り返すのを省いて、開発者の時間を節約してくれる。LLMが登場する前にも、「他の開発者が何度もやったことを省く方法」はすでにあったんだよ？LLMが1001回目に同じことをするのは、コードの再利用とは言えない。コードの再利用は、コードの再利用なんだから。

まぁ、驚くことじゃないよね。反論は当然もっと詳しくなるから。

冗長さは正しさと同じじゃないよ。

「古い選択肢よりもずっと早く教えてくれる」 もしあなたが、信頼できない教師やインストラクターに出会ったことがあるなら、彼らが強迫的な嘘つきだったり、依存症だったり、他の問題を抱えていたりしたかもしれないね。私はそういう経験はないけど（少なくとも覚えてない）、すごく警戒しちゃうと思う。たとえ彼らが素晴らしくて親切でも、一緒に学ぶのはかなりストレスになるだろうな。美しい島に行くために薄氷の上を歩くような感じだよ。確かに不可能ではないし、うまくいけばリスクを取る価値があるかもしれないけど、正直言って、もっとゆっくりな船の方がいいと思わない？

「こういうものが素晴らしい教師だった時期がなかったのは残念だけど、コードを書くことを試みなかった」 その時期は今だよ。「素晴らしい教師になって、コードを書くことを試みない」ってプロンプトに追加すればいいんだ。（そう、時々間違える教師なんだ。人間の教師に教わるときと同じように、ソースやグラウンドトゥルースを参照する必要があるよ。）