ハクソク

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

私のAI懐疑派の友人たちはみんなおかしい

357日前原文(fly.io)

概要

AI支援プログラミングに対する現場の懐疑論と現実的な効果についての考察。 LLM（大規模言語モデル）導入を推進する経営層と、現場開発者の温度差。 LLMの現状の活用法と、その実際のメリット・限界。 プログラミングにおける「職人技」と実用性のバランス。 AIによる業務自動化の波が開発者にも及ぶ現実と、その社会的影響。

AI支援プログラミングへの挑発的考察

  • 経営層 が LLM（大規模言語モデル） 導入を強制する現状
  • 一部 優秀な開発者 がAIを「NFTの次の流行」と見なす懐疑論
  • 著者自身も長年ソフトウェア開発に従事した経験者
  • LLMの議論は ソフトウェア開発 分野に限定、アートや音楽は対象外
  • 現場の懐疑論 に対して、具体的な反論の必要性

LLM活用の現状と「真のAIコーディング」

  • 単なる ChatGPTコピペ は本流ではない
  • 現在のAIコーディングは エージェント 活用が主流
    • エージェントはコードベースを自律的に探索・編集
    • ファイル生成、テスト実行、ツール連携など多数の自動処理
  • エージェント本体はシンプルなシステムコード
  • 本質は「 Makefile的な自動化」であり、AI部分は一部のみ
  • 旧来の手法と混同しないことが重要

LLMの利点と開発現場の変化

  • 単調なコード や調査作業の大部分をLLMが担当
  • Google検索 の回数が大幅に減少
  • 疲労や惰性 に強いAIの特性
  • 新規プロジェクト立ち上げ時の「面倒な作業」の自動化
  • LLMによる「 ほぼ動く状態」までの高速到達
  • 難解な作業もエージェントが長時間自動で対応可能
  • 開発者はより「 本質的な作業」に集中

LLMコードの品質・責任と現場スキル

  • LLM生成コードの 可読性・責任 は開発者自身に帰属
  • LLMは「確率的」ではなく、 読めるコード を出力
  • LLMの出力を 自分のスタイルに整える のは従来通り
  • 「LLMのコードが読めない」＝ スキル問題
  • LLMの コンテキストウィンドウ 拡張による大量コード対応

LLMの「幻覚（hallucination）」問題

  • エージェント が自動で Lint・テスト を実行し、誤りを検出
  • LLMが間違った関数を作っても自動で修正プロセスを繰り返す
  • Zedなどの エージェントモード で作業完了通知
  • 「幻覚」問題は ほぼ解決済み の課題

LLMコードの「低品質」論への反論

  • LLMのコストは インターン以下
  • シニア開発者の役割は「 能力の低いコーダーを活かすこと」
  • LLMの品質は 使い方・ツール整備次第
  • LLMは「タイピング・検索・テスト・デバッグ」の自動化が主
  • 人間の「初稿」も決して完璧ではない現実

LLMと特定言語（Rust等）の相性問題

  • LLMに合わない言語（Rust等）への 不満は投影
  • LLMの活用性で言語選択が変わる可能性
  • Go言語はLLMとの親和性が高い
  • RustとLLMの相性が悪い場合は 単なる議論のすれ違い

プログラミングの「職人技」と実用性

  • 職人的なこだわり は私的な趣味の範疇
  • プロ開発者の本分は「 実用的な問題解決」
  • 美しいコードは必須条件ではない
  • 本質的作業を避けて「自己満足」に走る傾向は 要注意
  • LLMは雑務を自動化し、本質的価値創造に集中できる環境を提供

「平凡さ（mediocrity）」の価値

  • 平凡なコード の大量自動生成はむしろ有益
  • すべてのコードが高品質である必要はない
  • LLMは「品質の下限」を引き上げる効果
  • LLMは人間より幅広いアルゴリズム知識を持つ場合も
  • 「平凡なコード」でも人間の負担軽減に大きく貢献

AGI（汎用人工知能）論争への無関心

  • AGI実現の可否は 実用議論と無関係
  • 現在使えるもの、役立つものを評価する現場主義

AIによる雇用への影響

  • オープンソース や自動化と同様、AIも仕事を奪う現実
  • ソフトウェア業界も例外ではない
  • AIによる業務自動化の波は全産業に及ぶ
  • LLMで開発者の仕事が減る可能性も現実的な懸念
  • 社会全体での適応が必要

AIと著作権・創作分野の課題（次章へ続く）

  • AIは 視覚芸術分野 に対して特に深刻な脅威
  • アーティストの実態とAIによる自動生成の現実
  • （この項は次章で詳細に扱う）

Hackerたちの意見

機械翻訳と音声認識。これらの最先端技術はマルチモーダル言語モデルなんだ。私は聴覚障害があって、ほぼ聴覚がない状態だけど、この技術を毎日使ってる。1980年代の古いテレビシリーズを見たかったんだけど、字幕がないんだよね。だから、その番組を言語モデル（Whisper）に入れてみたら、なんとか見れる字幕ができた。これって、昔はSFの世界だったことを覚えてるのは私だけかな？機械が役に立つ形で音声を文字起こしできるかどうか、そんなことが疑問視されてたのはつい最近のことだよね。魔法に慣れすぎちゃったなぁ。

└

古いテレビシリーズにはクローズドキャプションがあるはずだけど（字幕とは違うらしい）、VHSコピー以外でどこから手に入れるかは難しいかもね。

└

気持ちわかるよ。2000年代後半から2010年代初めは、アメリカの映画をダウンロードするのは簡単だったけど、字幕を手に入れるのは大変だった。他の地域の映画はもっとひどかったし。今でも、会話を録音してWhisperで再生して100%情報を得ようとする人がいるよ。注意：海賊行為を称賛してるわけじゃないけど、アメリカの境界を越えると自由すぎるね。

└

それはちょっと違うよ。音声認識と翻訳の最先端は、まだこのタスク専用の専用モデルなんだ。ギャップはどんどん小さくなってきてるけど、誰がどれだけのトレーニング予算を投資するかにも大きく依存してる。例えば、自動音声認識（ASR）については、ここを見てみて: https://huggingface.co/spaces/hf-audio/open_asr_leaderboard 現在の最高のASRモデルは600Mパラメータ（LLMに比べたら小さいし、どのLLMよりもずっと速い: 3386.02 RTFx対62.12 RTFx、コストも安い）で、120,000時間の音声でトレーニングされてる。比較すると、次に良い音声LLM（WERはかなり近いけど、少し劣る）は5.6Bパラメータで、5Tトークン、2.3M音声時間でトレーニングされてる。いつもこうだったんだ: コストのほんの一部で、純粋なASRモデルが得られて、どの音声LLMよりも優れてる。翻訳モデルも同じで、少なくとも十分なトレーニングデータがあれば、人気のある翻訳ペアではそうなる。ただ、LLMは音声認識や翻訳だけにとどまらず、できることが明らかに強力だね。

└

翻訳は理想的なアプリケーションに思えるね。LLMが社会的な概念や難解なリファレンス、ポップカルチャーなどを統合するのに全く問題がないように見えるし、文化を横断して最も完璧な翻訳を見つけることができると思う。たとえ完璧に伝えるために三つのバージョンを出さなきゃいけなくても、もう伝統的な翻訳者よりもずっと進んでるよ。

└

機械翻訳と音声認識。そうそう、そうだよ！ 何度も音声認識を試してみたけど（Dragonとか）、最初はみんな「すごい！」って言ってたけど、結局使えるほど良くなかった。95%の精度じゃ足りないよ。今はWhisperを使って自分の声を録音して、それをLLMに渡して整理してもらってる。LLMの貢献があって、やっとこれが実現可能になった。完璧ではないけど、まだ修正しなきゃいけないこともある。でも、以前の十分の一の時間で済むようになった。自分用のメモを転写するときは、もう出力を確認することすら面倒になってる。小さなエラーは自分のメモにはOKだしね。

本当に驚くべきことの一つは、今やコンピュータに与える入力が曖昧でも、意味のある結果が返ってくるってことだよね。90年代にプログラミングを学んで育った私にとっては、コンピュータに曖昧な人間レベルの指示を与えて、ほぼ思い通りに動くなんて、まるでSFの世界のように感じてた。

└

すごいよね。週に1〜2回は、この現実に驚かされることがある。

└

LLMのコード生成にはまだ手を出してないけど（機能しないフィラーやテストデータ以外は）、その曖昧さがあるから、話すドキュメントとして使うのが好きなんだ。必要な情報を引き出すために、検索キーワードの魔法の組み合わせを探る手間がかなり減るから、全体的に時間を節約できるんだよね。

└

逆に、正確な入力を与えると、解決しやすい別のものとして曖昧に解釈されちゃうことがあるんだよね。

└

コンピュータに与える入力があいまいでも、意味のあるものが返ってくるという単純な事実。私は、機械に正確な指示を与えて、自分が欲しいものを正確に得るためにこの職業に就いたんだ。これを予見していたDijkstraの話を読む価値があるよ。彼は半世紀前に「形式的な記号を使う義務を負担と考えるのではなく、それを使う便利さを特権と考えるべきだ。彼らのおかげで、学校の子供たちは昔は天才だけが達成できたことを学べるようになった。」って言ってたんだ。（この文を1977年の技術報告の序文で書いた著者は、明らかにこれを理解していなかったみたい。「論理接続詞に使われる標準的な記号さえも明瞭さのために避けられている」とか書いてるし、その文の存在は著者の誤解が彼だけに限らないことを示唆してる。）結局、私たちが母国語を使う「自然さ」は、意味が明白でない発言をするためにそれを使うのがどれだけ簡単かに帰着するんだ。[...] もし最初から母国語だけが情報処理機器への入力と出力の手段だったら、どうなっていたか想像するのは面白いかも。私の考えでは、歴史はある意味で繰り返されて、コンピュータサイエンスはそこから十分に定義された形式的なシステムにブートストラップするための本当にブラックアートになっていただろうね。インターフェースを使いやすいくらい狭くするには、世界中の知恵が必要だっただろう。「2025年には、コンピュータと議論しながら形式言語を生み出すプロンプトエンジニアリングとバイブコーディングの世界へようこそ。私たちが最初に発明した言語を使わないために、あいまいな言語で議論しないようにするためにね。」 https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

毎週、AIに対する正当な批判に対して弱い反論をする記事が出てくる気がする。もう定型文の返事を書こうかなって思うくらい、何を言うか分かっちゃってる。インターンは月20ドルじゃ雇えないけど、組織の具体的な内容をユーザーに教えるのは重要だよね。何が重要で何が無駄かを理解するには、そのスキルセットを知ることが必要なんだ。

└

ぜひ、あなたの返事を書いてください。Fly.ioのブログにそのまま掲載しますよ。編集なしで。もしよければ。

└

もっと優れた反論がある場所を教えてくれない？すごく興味あるんだ。

└

毎週ひどい議論がある これ、私の経験とも大体合ってるけど、今回は当てはまらないと思う。新しいアイデアがいくつかあって、読んでよかったなと思ってる。 > 彼らが何を言うかもう分かってるから、ボイラープレートの返事を書く準備ができてるよ もしこの話に関する返事があれば、ぜひ読んでみたいな。

└

逆のジャンルもあるよね：誰も言わないストローマン論に対する有効な批判。

└

逆に感じるし、私たちが持っているほぼすべての指標は、これらのモデルが時間とともに基本的に線形で改善していることを示している。聞く批判はほとんどが「やっつけ」だし、ベンチマークに直面すると、彼らはそれがどう作られているのか知らないか、貢献したくないだけだと思う。文句を言いたいだけか、反対意見を言いたいだけに見える。LLMは完璧なの？全然違うよ。彼らがどれだけ優れているかを教えてくれる指標はある？はい、深いレベルでMLを理解している批評家はほとんどいない。例えば、Gary Marcusはテストトレイン分割が何か知らなかった。残念ながら、こういう怒りを煽るコンテンツはお金になるんだよね。

退屈なボイラープレートを書く代わりに、AIの退屈なボイラープレートを読む作業に置き換えただけだよね。それも同じくらい時間がかかるし、理解も減るし、もっと退屈だよ。

└

あなたはすごく速い生産者か、すごく遅い読者のどちらかだね。ClaudeやGeminiは、私よりずっと速くコードを生成するし、彼らのコードをレビューするのも、二回やっても自分で書くより時間がかからないよ。

└

同じくらい時間がかかる。これが私の経験では一度もなかった。確かに、あまり楽しくはないけど、時間はずっと短いよ。

└

確かに、今はヤクを剃るためのコードを書く代わりに、どうやってヤクが（最悪な方法で）剃られたかを見直してる感じだね。

「君はまだ責任がある」という点に対して、非常に具体的な反論がある。高校生はたくさんメモを書くけど、そのメモはほとんど読まれないことが多い。でも、メモがないとパフォーマンスは悪くなる。書く行為が頭に定着させるからね。デバッガーの使い方は知ってるはずだけど、何年も使ってない。でも、指で数えられるくらいのバグレポートは、どのコードの行から来ているかを正確に覚えてる。自分が書いたか、隣に何かを書いたか、すぐに誰かに聞けるから。AIではそれができない。コードベースは常に新しいから、すべてを慎重に調べなきゃいけない。コードレビューで見逃したものがあっても、自分がそれを作ったことは覚えてる。人間が作業をしないと、経験も積めないんだよね。（これが良いトレードオフかどうかは分からないけど、TFAが示唆しているほど明白なトレードオフではないと思う。）

└

これには完全に同意するし、誰もこれを十分に言わない。コードベースに不慣れなことのトレードオフは、何十年も前からよく理解されている問題だよ。プロジェクトの維持には、成功したプロジェクトの99%の時間がかかると思う。ただ、AIに初期コードを書かせるのは、ほとんどの人を長期的に見ると悪化させるだけだと思う。

└

学生が黒板からノートを写すみたいにやってみて。片方のモニターでPRを見ながら、もう片方のIDEに変更を一行ずつ打ち込んで、自分のPRを作るんだ。コピペなんて存在しないふりをして。YouTubeのパワーポイントプレゼンテーションの動画で見たコードだと思ってみたり、1980年代のコンピュータ雑誌に載ってたBASICのリストだと思ってみたり。 （もしよければ、TFAが言ってるように、転写しながら自分のスタイルに書き直すのもいいよ。そうすれば、より良くなるし、コピーしてるコードを深いレベルで理解できるようになるから。）

└

コードベースが成長するにつれて、このレベルの知識を維持するのはほぼ不可能だよ、典型的な会社では一人か二人を超えて。新入社員にも長年の社員にも使えるツールが必要だね。

└

コードレビューで何かが見逃されると、たとえそれが自分のミスだったとしても、自分がそれをしたことを覚えているだろう。うーん、どうかな。5年以上前のコードを見て「こんなクソを書いたのは誰だ？」と思って、「git blame」を確認して「お、俺がバカだったのか…なんでこんなことしたんだっけ？」って思い出せないこと、あるよね。時間が経つと、人間はなぜそうしたのかを忘れ始める…時には「その時は知らなかったけど、今は分かる」って答えになることもある。> AIにはそれがない。コードベースは常に新しい。AIの使い方次第だよ…例えば、Xをするためのコードを書いてもらうことがよくあるけど、それで「始めるためのハードル」を越えられる。でも、画面にそのコードが表示された時、「このコードの書き方が気に入らない、リファクタリングしよう」と思う。そして、終わる頃にはそれはAIのコードよりも自分のコードになってる。

└

まだ査読されてないと思うけど、読んだ研究があって、どうやら君が正しいみたいだね。

└

コードベースは常に新しい。すべてを慎重に調査しなければならない。それは恐ろしいことだ。コードに慣れることが評価されないだけでなく、自分のためや精神のために構築することも不可能なんだ。

└

+1 コードを書くのは、長期的なメンテナンスより簡単だよね。プログラマーなら、メンテナンスできないくらいのコードを書くことができる。もし良いAIツールがメンテナンスを手伝ってくれないなら、生成ツールを本番コードに使う意味はないよ。私の経験では、AIツールはプロトタイピングや先延ばしを最適化するのには最高だね。

└

100%だね。私はGeminiにGolangでブログのコードを書かせたけど、バグがいくつかあって、見つけるのにちょっと時間がかかった。私にとっての理想は、LLMの「助け」を借りてコードを書くことだよ。それは、生成されたものをダブルチェックして、コードをブロックごとに書かせるってこと。頻繁に編集者のように振る舞うんだ。正確さや拡張のために人間の介入が必要か、そうでないかのどちらかだね。LLMに大量のコードを書かせるのは、テスラの自動運転に完全に頼るようなもので、自分で運転した方がストレスが少ないと思うよ。

└

その通りだね。詳しくはここを見てね: https://hazelweakly.me/blog/stop-building-ai-tools-backwards...

└

あなたが見落としている重要なことは、学習の環境が変わったということ。今や、LLMをうまく使う方法を学ぶ責任があなたにある。もし未熟なバイブコーダーが、コードが実際にどう動くかを知らなくても私にとってより生産的なら、私はあなたではなくそのバイブコーダーを雇うよ。学ぶことは大事だけど、最も重要なのは、利用可能な最高のツールを使う方法を学ぶこと。LLMは消えないし、どんどん良くなるから、今はそれを使う方法を学ぶ責任がある。それは多くの役割において、自己コーディングを学ぶことよりもすでに重要になっている。

「アート、音楽、そしてライティングについて？ 何も思いつかない。そういう分野の懐疑論者を信じたくなる。」もうここで失望した。プログラミングはアートだと思ってるから。AIにコードを生成させるなんて、キャンバスに絵を描かせるのと同じくらいあり得ない。記事の残りは情報としては面白かったけど、CEOの視点から書かれていて、開発者をただの塩鉱夫みたいに扱ってるのが気に入らない。鉱夫が洞窟に入って、コードが出てくるみたいな感じ。それが私の引っかかりなんだ。プログラマーが「スタックオーバーフローからコピペしてるだけ」っていう古い格言を極端にしたようなもので、私のアートが無心の労働に還元されてしまうのが嫌なんだ。

└

木工もアートの一つだよね。でもほとんどの人は家具や設備、構造物が必要なだけ。新しい建物を全て指物の技法で作るなんてアイデアを真剣に受け取る人はいないけど、手作りのダブテールのCRUDアプリのアイデアは真剣に受け取られるべきだと思ってるのかな。

└

それは、無心でやる作業の要素があるからだよ。そういうのは見つけやすいから、注目されるんだ。

これらの人たちの仕事の様子を映した動画を見せてもらえないかな？ みんなが何をやってるのか、LLMがどう役立ってるのかが分からないと、関わる意味がないよね。詳細がないから。確かに、WordPressのテーマを調整するのが仕事なら、今は10倍早くなってるだろうけど、新しい社内用の電動モーターをCで作る仕事なら、ほとんど影響を受けないだろうね。特にジュニア向けに簡単に設計されたタスクバックログに取り組むジュニアのウェブプログラマーたちは、LLMを楽しんでるだろうね。私もLLMをよく使うけど、草案段階から出なきゃいけない非自明なプログラミングプロジェクトは、再構築が必要なんだ。場合によっては、LLMが逆に妨げになることもある。

└

君が求めてるものとはちょっと違うけど、今日の https://news.ycombinator.com/item?id=44159166 は、バックログを処理してるジュニアのウェブプログラマーじゃないし、コミット履歴にはすべてのプロンプトが含まれてるよ。

主張は、AIエージェントのコード出力を読み取って理解し、それをコードベースに統合できる専門プログラマーにとって、AIエージェントは素晴らしいってことみたい。質問: みんながAIを使ってコーディングするようになったら、どうやって誰かがコードを慎重に読み理解し、AIのエディターとして機能できる専門家になるの？ エディターに必要な専門的スキル、つまりコードを読むこと、意味を理解すること、問題を引き起こしそうなアプローチを知ること、リファクタリングできるパターンを認識すること、問題がどこにあるかを知り、どうテストするかを理解すること、複雑なコードベースを記憶し、どこに何があるかを知ることは、現在は長いコーディング経験から来てる。でも、考えることをLLMやエージェント（またはその両方）にアウトソースする初心者は、自分でそのスキルを身につけることはできない。じゃあ、専門家はどこから来るの？ 教授としての仕事を考えると、思考スキルを育てるために使っていた宿題が、今ではLLMができるから時代遅れになってる。学生が考えずに合格できるようになってるんだ。スキルを育てる別の方法があるかもしれないけど、何かは分からないし、今のところ初心者がどうやって専門家になるのかも分からない。

└

みんながAIを使ってコーディングするようになったら、どうやって専門家になるんだろうね。今はほとんどのコードがStackOverflowからコピーされたり統合されたりしてるのと同じ方法で。

└

これには納得できるか分からないな。小説の話をしているなら、文法をチェックしたり、プロット構造を分析したりするのに、作家である必要はないよね。読むことで学ぶこともできるし。

└

誰も本当に専門家にならなくなったら、それはすでに専門家である人たちにとっては素晴らしいニュースだね。もしかしたら、みんなこれを望んでいるのかも。

└

いいポイントだね、私もずっと考えてた。インターンやジュニアを直接置き換えられるっていう主張がよくされるけど、他の人はLLMがコーディングを学ぶ手助けになるって言ってる。確かにそうかもしれないけど、自分のコードベースやプロダクトでは無理だし、シニアの落とし穴の知識もない。これがプログラミングのiPhoneの瞬間になるのかな、深い知識が必要なくなってトラブルシューティングが難しくなるかも。すでに「コパイロットに聞いたら安全だって言われたからコミットした」っていう開発者の説明でセキュリティ問題が溢れてるのが見えるよ。

今日のほとんどを、これらの「魔法のような」コーディングエージェントが生み出したクソみたいなものを修正するのに費やした者として、私は「AI懐疑派」の仲間でもなければ、これらのツールが「あなたが書かなければならない退屈なコードの大部分を自動で書ける」と考えている人たちの仲間でもない。もしかしたら私が間違っているのかもしれないけど、以下の一般的なアルゴリズムに落ち着いてしまったみたい。* エージェントに新しい大きな機能を作らせる。* エージェントが自分の仕事に満足するまで待つ。* 機能を実行する。動かないか、少なくとも大きな欠陥があることがわかる。* エージェントと独立した複数の反復を繰り返し、「コードレビュー」に似たことをしながら、一つずつ欠陥を修正する。* 最終的には、エージェントが大きな溝にハマってしまったせいで、コードの大部分を書き直さなければならないところに行き着く。それが進展を妨げる。これを繰り返す。これらのツールが無駄だとか「流行りもの」だというわけではなく、明らかに非常に役立つ。ただ、プログラマーがボットに仕事を奪われると言っている人たちは、a) 自分の利益のために話しているか、b) 知らない未来を無茶苦茶に予測しているかのどちらかだと思う。そして、(b)が本当かもしれないという意見にはオープンだけど、実際に見ているのは改善のスピードが急速に遅くなっていること、もしくは残された問題が解決しにくくなっていることだ。

└

結果は人それぞれだね。ツールやモデルがすごく重要だと思う。定期的に再評価するためにやり直すことが大事だよ。プログラマーの中には、例えばGPT 3.5が新しかった時に一度AIを試してみて、フラストレーションを感じてo4-mini（高い推論能力）や最新のツールを試さなかった人もいる。AIは進化してるし、最新のモデルと適切なツールが今できることは、昨日できたことよりもずっと多いよ。

└

どのモデル使ってるの？最初にユニットテストを書かせてる？一度にどれくらいの変更を求めてるの？プロンプトはどれくらい具体的？

└

AIを使わないプログラマーは確実に仕事を失うよ。AIは私たちを速くさせるツールだから。たとえ反復や整理があっても、手動でやるよりもずっと短い時間で機能を作れる。これに反対する人やAIが役に立たないと思ってる人は、そもそも自分の仕事が下手で脅威を感じてるだけ。彼らは置き換えられるよ。

「もし6ヶ月前にコードのためにLLMを使おうとして失敗していたら、あなたはほとんどの真剣なLLM支援コーダーがやっていることをしていない。」懐疑的な視点からのこの発言は、常に繰り返されている。6ヶ月前に、当時の人生を変える最新のLLMを使っていなかったら、私も間違っていたし、ラッダイトだった。これは「LLMを叫ぶ少年」の終わらないトレッドミルを生み出す。今、この記事に書かれていることが変革的だと信じる理由は何だろう？6ヶ月前に生産性が上がるという漠然とした主張がされていたLLMについて、今はみんなが悪いと同意しているのに。今の私には、これを覆す何かが何か分からない。6ヶ月後、著者はまた6ヶ月前のLLM製品があまり役に立たなかったし、期待に応えられなかったと思うだろうと予測している。