ハクソク

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

「LLM」のLは「嘘」を意味する

概要

  • **AI活用の「不可避性」**に対する懐疑的な視点
  • LLMによるソフトウェア開発の現状と限界
  • 模倣・贋作としてのAI生成物の問題提起
  • オープンソースやゲーム業界でのAI利用の反発
  • 本質的な技術者の役割とAI時代のものづくりの価値観

AI利用の不可避性について

  • AIの過剰な期待と投資が世間を席巻する現状
  • LLMツールの普及にも関わらず、ソフトウェアの質や体験は大きく変化していない現実
  • 新しいモデルが次々登場するが、過去の約束が果たされていない事実
  • AIを使わなくても問題ないという立場の重要性
  • AI未使用が技術的な遅れや「時代遅れ」を意味しないという認識

Craft vs Kraft(手仕事と工業製品)

  • LLMの生成物を「贋作」と捉える視点の提示
  • 贋作の本質は「本物らしさの模倣」であり、真正性の欠如
  • 伝統食品や芸術品と同じく、ソフトウェアにも「本物」と「模倣」の線引きが必要
  • 市場やブランド価値を守るための保護主義の重要性
  • 消費者の判断だけでは本物の価値は守れないという現実

Distrust and Verify(疑い、検証せよ)

  • LLMによるコード生成は「安価な模倣品」の氾濫を招く
  • オープンソースプロジェクトにおけるモチベーション低下と品質低下
  • AI生成のプルリクエストが現場の負担や混乱を増大
  • 本質的なエンジニアリング力とAIの使い方の違い
  • AIによる生産性向上の幻想と現実の乖離

Tools for Tools(道具のための道具)

  • 経験豊富な技術者でもAI生成物の質の低さを見抜ける
  • 冗長なコードや複雑化、リファクタリングの不足がAI由来で顕著
  • AIツール利用者自身も生成物の不満を感じている現象
  • ソフトウェアの閉鎖性・複雑化とAI活用の関係
  • 本質的なユーザー体験や創造性の爆発が起きていない現状

And a Bottle of Rum(他業界の動向)

  • ゲーム業界ではAI生成コンテンツへの反発が強い傾向
  • Steamなどプラットフォームの明確なAIポリシー
  • ゲームは芸術性と唯一性が重視される市場であり、模倣が嫌われる
  • 透明性と消費者選択の重要性がゲーム業界で徹底
  • オープンソースやインフラ系ソフトウェアとは異なる価値観

AI時代の「本物」と「模倣」の境界

  • **AI生成物は本質的に「模倣」**であり、真正性の有無が価値を決める
  • 伝統工芸や食品の保護と同様、ソフトウェアにも「本物」を守る視点が必要
  • 消費者の選択だけに任せると市場全体の質が低下するリスク
  • 真正性を担保する仕組みや文化の重要性

AIとエンジニアリングの未来

  • AIツールは「便利」だが、創造性や本質的な価値を生み出すわけではない
  • 本質的な問題解決力やユーザー理解がエンジニアには不可欠
  • AI活用の「不可避性」フレームを疑う視点の必要性
  • 業界ごとにAI導入への反応や文化が異なる現実
  • **AI時代における「ものづくりの誇り」や「本物志向」**の再評価

Hackerたちの意見

> この種の保護主義は、例えば職人チーズや cured ham のような管理された産地の食品でも見られます。これらは、伝統的な製造方法や高品質な食材が必要なだけでなく、特定の地理的起源も求められます。もしかしたら「職人コーディング」みたいなものが未来に登場するかも?
この地理的保護は、ほとんどの場合、非常におかしいと思う。私の意見では、彼の主張を弱めている。
「ハンドメイドネットワーク」って、要するにこれなんだよね(いい意味で)。LLMがコード生成に十分なレベルになるずっと前から、無味乾燥な「企業向けソフトウェア開発」に対抗する哲学として存在してた。10行で実装できる機能が、1000行の「業界のベストプラクティス」のボイラープレートに包まれるのが普通になってる。LLMを使ったプログラミングは、量を重視する工業化されたソフトウェア開発のニッチの論理的な結論なんだ。要するに、アーキテクチャの宇宙飛行士が書いた仕様を考えずにコードに変換する人間のボットを置き換えてるだけ。そんな「仕様を書いてコードを出す」みたいなプログラミングは、そもそも存在すべきじゃなかった。アーキテクチャの宇宙飛行士たちが、実際に自分の技術を大切にしているプログラマーを煩わせることなく、LLMでアイデアを実現できるようにしてあげよう ;)
一瞬でページのヘッダーを思い出した。たぶん、最後にこのサイトに訪れたのは10年くらい前だと思う。
> 私の意見では、AIの出力が合法か著作権の対象かどうかを判断するために裁判所が判断を下すべきではなかった。なぜなら、どれも出所がないから。判断は単純にはできないし、AIの出力はそれが証明されるまで偽造物として扱うべきです。「無罪が証明されるまで有罪」というのは著者のLLM特有の主張には合致するけど、良い原則とは言えない。
あなたは著者のポイントを見落としている。彼は「裁判所が判断を下すべきではない」と言ったんだから、それは「無罪が証明されるまで有罪」とは真逆だよ。有罪というのは裁判所が判断を下したということ。彼は全く判断を下さないことを提案している。AI企業が何かを主張するなら、それを証明しなきゃならない。科学のようにね。どんな主張も単なる主張として扱われる。トリックは、何も主張せずに、ユーザーが自分でそれが魔法だと結論づけるようにすること。確かに、LLMは設計上、出所を引用できないから、何かを作り上げたのか、意味があるのか、ただコピー&ペーストしたのか、機能するものかクソなのか、あるいは素晴らしい新しいものを作り出したのかを教えることはできない。私たちが見るのは成功のストーリーだけ。n回目の試行とプロンプトの調整、エージェントを正しく扱うプロセスの後の成功だけ。隠れたコストはそこにあって、ほとんど隠れていない。この曖昧さはAI企業に利益をもたらしていて、彼らはそれを最大限に利用している。多くの国で禁止されているエンティティから違法に海賊版の知的財産を取得し、それを利用パイプラインの一端で売って、他の端では「史上最大のもの」として販売するところまで行っている。そして、AIが世界を支配するという終末的な話は、マーケティングのハイプの一部だよ。
> これはコードとは対照的で、コードは一般的に再利用による問題が全くない・・・これは絶対にシェフのキスのダブル・エンタンドルだね。
Acko.netはインターネット上で最高のウェブサイトのままだ。
著者や他の多くの人が消化しにくいのは、LLMが私たちの仕事のほとんどが、冗長なコードに対する小さな新しさである現実を浮き彫りにしていることだ。私たちがプログラミングでやっていることのほとんどは、高レベルでの小さな新しいアイデアと、低レベルでの繰り返し可能なボイラープレートだ。公平な質問としては、「なぜボイラープレートがライブラリや他の抽象化として自動化されていないのか?」ということだ。LLMは特に、繰り返し可能なコードをあいまいに抽象化するのが得意で、他の手動の方法では同じ結果を得ることはできない。私も共感するよ、私たちが提供する価値のほとんどが、そのコードの行ではなく、高いレイヤーでの小さな革新にあることを認識するのは辛いから。どの開発者もそんなことを聞きたくないだろうし、自分の言葉が自分の魂からの創造だと思いたいはずだ。
抽象化はタダじゃないよ… たとえ正しい抽象化と、デプロイに必要ない部分を取り除くためのツールがあったとしても、理解とコンパイルのコストはまだ残るからね。それに、誰かが抽象化を売ろうとしたら、マネタイズしようとするから、みんなが使いたいと思うわけじゃないし(オープンや無料だと永遠に終わらないかもしれない)。プラットフォームのロックインや競争の側面もあるし…
しばらく前に本を書いたんだけど、コーディングは何に取り組むかを選び、それを書き、デバッグすることだと主張したんだ。そして、私たちはこれらのステップを逆の時間順で習得する傾向がある。最近のことを見て、今読むとどれだけ古く感じるか不思議だよ。チューリングテストについても書いたけど、AI開発の大きなマイルストーンとして扱われているのに、実際にはチューリングテストを通過したプログラムに対する一般的な反応は、肩をすくめて軽視することだった。
これは、テクノロジーの考え方と、唯一の「ボイラープレート冗長コード」が言語そのもので、アイデアや哲学の緩やかな集合体である多くの作家やアーティストとの間の考え方の違いを示す、非常に洞察に満ちたコメントだね。おそらく、ここでの元の罪は、彼らを「プログラミング言語」と呼び始めたことだと思う。あと、あなたの作品は単なる新奇性以上のものだよ!知的労働や時間のような無形のものがあるからね。
ライブラリは境界を作るけど、それはほとんどの場合恣意的で、コードとのインタラクションの仕方を制限して、ライブラリから欲しいものを得るためのボイラープレートを増やすんだ。抽象化は肥大化の原因だよ。抽象化がなければ、常に肥大化を減らすことができるし、グルーの中で肥大化を減らすこともできるけど、グルー自体を減らすことはできない。恣意的な関数シグネチャや短命の中間データ構造、型定義を作らないためには、規律が必要なんだ。これがボイラープレートの始まりだよ。ボイラープレートを取り除くための多くの進歩は、あなたの5つの関数呼び出しと10の中間データ構造や型定義が、実際には0の関数呼び出しと0のカスタムデータ型、そして少ない行数でできることを認識することなんだ。抽象化は、あなたが欲しいものがどれだけシンプルかを隠す。問題は、すべてのオープンソースコードが上で説明した肥大化のように見えるから、LLMはボイラープレートなしで実際にコードを書く方法が分からないことなんだ。私が見た中でうまくいったのはシェーダーだけで、通常は抽象化の一般的な落とし穴を避けるように書かれている。LLMは、あなたが欲しいことをする1つの関数と1つのファイルで大きなプログラムを書くことができない。プログラムを関数や複数のファイルに分割するのは、多くの時間が経った後に行うステップだけど、すべてのオープンソースはそんな感じじゃない。
本って、結局は数百ページのテンプレートに過ぎないシンプルなテーマや主張だよね。
いや、同意できないな。「ボイラープレート」だからって、価値がないとか新しさがないわけじゃないよ。家や車など、色んなものを作る時には「ボイラープレート」があるけど、本当に新しいものを加えるためには「いつも同じ基盤」が必要なんだ。その基盤をしっかり作ることに価値があるんだよ。技術や深い知識、誇りを持ってね。プロジェクトはそれぞれ違うし、全てが一般的な市販品から作れるわけじゃない。
実際、これがLLM革命の悲劇的な結果の一つだと思う。プログラミングの人間工学的な進歩に資金を得るのが難しかったのに、新しいプログラミング言語のエコシステムや大規模なライブラリに資金を提供するのは簡単じゃなかった。それでも、抽象化のレベルを大幅に上げる可能性のある進展がいくつかあった。しかし、LLMはこの経済的インセンティブを完全に壊してしまった。今では、かなり低レベルのTypeScriptでコードを書くのが最も生産的に思えるし、機械が大量のゴミコードを吐き出すのを見ている感じだよ。
最も単調で反復的な作業をしている人たちは、最も生産性の低い環境で働いていることが多いんだ。速度や生産性を上げる明確な方法があるのにね。もし開発のスピードが本当に重要な要素なら、あの「四人組」のJava 8コードベースからはとっくに移行してるはずだし、彼らにオフィスや少なくとも騒音を減らすためのキュービクルを与えているはずだ。儀式的な会議に1日3時間も費やさせるなんてことはないはず。これらが実現しない理由は、たとえ開発者が10倍速くコードを書けたとしても、組織の慣性や非効率を乗り越える頃には、変化がほとんど感じられないからなんだ。新しいオフィスの費用や2年間のリファクタリングの努力は、もっと具体的に感じられるけどね。
> 「私たちの仕事のほとんどは、ボイラープレートの冗長なコードに対する小さな新しさだ…」 その意見を証明する例をいくつか教えてくれない?
> ビデオゲームは、消費者が効果的に反発している市場の一つとして際立っている。 いや、それは単に真実じゃないよ。プレイヤーはAIアートの資産にだけ反対してるんだ。しかも、それが明らかに分かる時だけね。コードの書き方なんて誰も気にしてないよ。SteamのAI調査で使われている言葉をちゃんと読めば、SteamがAI生成コードに完全に屈していることが分かる。具体的にはこう書かれているんだ:> アートワーク、サウンド、ナarrative、ローカリゼーションなどのコンテンツ。'コード'や'プログラミング'は一切ない。もしゲームプレイヤーが最も反AIなグループなら、LLMコーディングは避けられないってことは明白だね。 > これは、一般的に再利用の影響を受けないコードと対照的で、むしろインフラの場合は利益を得ることもある。 そうそう、まさにその通り。LLMは開発者が他の開発者が何千回もやったことを書く手間を省くのに役立つんだ。これを悪いことだとどうやって言えるのか分からないよ。 > クラシックな手続き型生成は、ここで前例として注目すべきで、ゲーマーはすでにそれに慣れている。なぜなら、全体的に見て成功していないからだ。 Sporeは高く評価されてるし、Minecraftは文字通り史上最も売れたゲームだよ。一人の開発者が失敗したからって、手続き型生成のアイデアが悪いわけじゃない。これは、道具が本質的に良いか悪いかは使う人次第だっていう完璧な例だね。
次の数段落を読めば、著者がこれに触れているよ: > とはいえ、Steamのポリシーは最近、プレイヤーに提示されるコンテンツを生成するために使われない「効率向上」のための開発ツールを除外するように更新された。最初の段落だけ引用したけど、もっとあるよ。
それに、「AI」はゲーム、特にモバイルゲームの中で、もう10年も前から存在してるんだ。名の知れたゲームスタジオは、特定のスタイルを使って素早くアートを作成できるカスタムAIアート資産ツールを長いこと持ってる。AIは道具で、スティーブ・ジョブズが言ったように、持ち方を間違えることもある。整形手術みたいなもので、悪い例だけ目につくし、それに反対する。専門家は良い例を見抜けるかもしれないけど、一般の人は知らないし、ほとんどの場合、誰かが気にしろと言わない限り気にしない。そしたら、すべてをAIのせいにするんだよね。
LLMは私の時間を節約したことがない。いつも、うまくいかないものを生み出して、私が欲しいものの大まかな形はあるけど、詳細がいつも間違ってる。自分が欲しいことをもっと早くタイプできるし、少なくとも正しい問題を解決していることは確信できる、たとえバグがあってもね。ボイラープレートを生成するためのツールも、LLMよりずっとずっと良く機能するし、決定論的なんだ。
> これを悪いことだとどうして思えるのか分からない。人は、自分の生活がかかってると思えば、色んなことをこじつけるもんだよ。AIが全て悪いっていう反応は、「AGIはもうここにある」っていうのと同じくらいおかしいと思う。 > スポアは高く評価されてるし、マインクラフトは歴代最も売れたゲームだよ。反論として、プロシージャルな地形生成を使った初期の有名なゲームの一つであるオブリビオンは、当時はすごく魂がないように感じた。結局、全てはどれだけ上手く実行されるかの問題だと思う。最良のケースでは、熟練したアーティストが自動化を使って機械的な作業を補完する(例えば、ルネサンスのアーティストが自分の傑作の全ての筆致を自分で描かなかったのと同じように)。最悪の場合(あるいは平均的な場合?時間が教えてくれるだろうけど)、人間が作った芸術的な決定がほとんど流れ込まず、出力が過去にやったことの平均的な mediocre なものになってしまい、それが正当に「スラップ」として認識される。
> そうそう、まさにその通り。LLMは開発者が他の開発者が何千回もやってきたことを繰り返す時間を節約してくれる。これを悪いことだとどうして思えるのか分からない。何度も同じことを書いてる理由を考えたことある?それがエンジニアとしての基本的な部分だよ。近くに完璧な車輪があるのに、車輪を再発明してる時を理解することが大事なんだ。
> そうだね、まさにその通り。LLMは、他の開発者が何度もやったことを繰り返すのを省いて、開発者の時間を節約してくれる。LLMが登場する前にも、「他の開発者が何度もやったことを省く方法」はすでにあったんだよ?LLMが1001回目に同じことをするのは、コードの再利用とは言えない。コードの再利用は、コードの再利用なんだから。
この意見記事について、賛成してる人たちが「本当にそう!」とか「素晴らしい!」って短いコメントを投稿してる一方で、批判してる人たちがしっかりした批判の段落を書いてるのを見ると、色々と物語ってるよね。
まぁ、驚くことじゃないよね。反論は当然もっと詳しくなるから。
冗長さは正しさと同じじゃないよ。
これらのものの「最良の使い方」に関するコンセンサスの周りでモード崩壊が起きてるのは残念だね。これらが素晴らしい教師だった時期がなかったのが残念だ。私の意見では、理想的な使い方は、エージェントが雑でバグの多い無秩序なコードを大量生産することじゃなくて、古い方法よりもずっと早く物事を教えてくれることだと思う。疲れている時や、捨てるつもりのCLIコードや、慣れてないAPIの時に関数のスニペットを時々書くことだよ。
> 「古い選択肢よりもずっと早く教えてくれる」 もしあなたが、信頼できない教師やインストラクターに出会ったことがあるなら、彼らが強迫的な嘘つきだったり、依存症だったり、他の問題を抱えていたりしたかもしれないね。私はそういう経験はないけど(少なくとも覚えてない)、すごく警戒しちゃうと思う。たとえ彼らが素晴らしくて親切でも、一緒に学ぶのはかなりストレスになるだろうな。美しい島に行くために薄氷の上を歩くような感じだよ。確かに不可能ではないし、うまくいけばリスクを取る価値があるかもしれないけど、正直言って、もっとゆっくりな船の方がいいと思わない?
> 「こういうものが素晴らしい教師だった時期がなかったのは残念だけど、コードを書くことを試みなかった」 その時期は今だよ。「素晴らしい教師になって、コードを書くことを試みない」ってプロンプトに追加すればいいんだ。(そう、時々間違える教師なんだ。人間の教師に教わるときと同じように、ソースやグラウンドトゥルースを参照する必要があるよ。)
この職業にいる私たちがまだ受け入れていない冷たい現実がある:誰も私たちのコードなんて気にしない。美しいとか賢いとかエレガントかどうかなんて、誰も気にしないんだ。時々、まれに、保守性があるかどうかを気にすることもあるけど。私たちは自分たちとお互いに対してだけ職人なんだ。他の誰にとっても、私たちは売るためのウィジェットを生産する工場労働者に過ぎない。これを受け入れれば、工場のオーナーたちが生産を速く、安くするツールを使わせたがるのも驚きじゃないよね。時計職人たちも、自動旋盤が発明されたとき、自分たちの技術が平凡に自動化されていくのを見て、同じように失望したんじゃないかな。時計職人のように、私たちもエレガントな機械を求める顧客のために作り続けることはできる。でも、ほとんどの顧客はクォーツを求めるだけなんだ。