電動工具は魔法のように大工にしてくれるわけじゃない。自分が持っているスキルをただ増幅させるだけだよ。

本当の「AIリテラシー」は、ミーム的な意味でのプロンプトエンジニアリングじゃなくて、プロンプト（と出力）が実際に意味のあるものに繋がるように概念的な足場を築くことだと感じる。

同意するよ。扱いたいテーマの「言語」やキーワードを知っておく必要がある。全くの初心者だと、AIはあまり役に立たないよ。「A、B、Cがあるとして、Dをしたい」とAIに伝えないと、理解して解決策を見つけるのは難しい。AIはたくさんの情報を持ってるけど、それをクリエイティブに使うのは苦手なんだよね。

その通り。LLMを使って生産的になるのは、良いGoogle検索を書くスキルに似てる。だけど、まだまだ多くの人が適切なGoogle検索の仕方を知らないんだよね…。

ピアノの真の道は、テクニックを学ぶことじゃない。最も基本的な曲から始めて、徐々に難しい曲に進んでいくんだ。俺が知ってるみんなは、26年間の演奏の中でそうやってきた。テクニックは実際の音楽を安っぽくする。ショパンにも初心者向けの曲があって、うちのピアノスタジオでは多くの1年生が「雨だれの前奏曲」や「ホ短調の前奏曲」、バッハのような他の初心者向けの曲を弾いてたよ。

まあ、ショパンを弾きたいだけと、今のレベルで何でも弾けるようにピアノをしっかり学びたいってのは大きな違いがあるよね。手をどこに置いて、どの鍵をいつ押すかを覚えただけで、全体のピアノ曲を機械的に弾ける人もいるし。

AIは、すでに自分の進むべき方向を知っている人たちを加速させている一方で、初学者にはこれまでと同じ人間のガイダンスが必要な状態を残している気がする。

私の経験では、AIは知らない分野について知りたいことがあるときのウィキペディアやスタックオーバーフローの強化版みたいなものだよ。良い説明があって、例やシナリオを求めると、理解できていないことを教えてくれる。ただ、その分野の基本的な概念を知っているときに限って、AIは生産的になるんだ。これはコーディングだけじゃなくて、科学や人文科学の他の分野にも当てはまるよ。

これ。2021年頃、技術的な興味はあったけど、コンピュータサイエンスの教育もプログラミング経験もない学生がいた。彼は早い段階でAIを使い始めて、ChatGPTの助けを借りて、当時開発していたものにかなり貢献できた。通常は初心者には難しすぎるものだったけどね。ただ、彼はいくつかのセキュリティ問題を引き起こしたり、非常に回りくどい方法で作業したり、彼の生活をもっと楽に、維持しやすくするライブラリやアプローチを考慮しなかったりした。彼のドキュメントは熱意があったけど、しばしば…少し事実に疑問があったり、回りくどかったりした。彼のコードチェックインの後に話し合うのはとても興味深かったし、関わった全員にとって良い教育的経験だったと思う。AIと経験豊富な人たちの組み合わせがなければ、こうはうまくいかなかっただろうね。

AIは「AとBからCが導かれる」とか、そういう結論を出すのは苦手だよね。欲しい結果をちゃんと指示しないと、なかなか理解してくれない。特に初心者には難しいと思う。大局を把握するのを学んでいる段階だからね。逆に、シニアは自分が何を求めているかだいたい分かってるから、細かい部分を詰めるのが楽だよね。AIが博士レベルだっていう主張はどこから来てるのか分からないけど、推論に関しては5歳児並みだと思う。

ほぼその通りだけど、プロンプトやコンテキストのレベルから始まるんだよね。シニアエンジニアは、どこを変えればいいかをだいたい分かっていて、何をすべきか提案できる。彼らは落とし穴を知っていて、頭の中に確立されたパターンやアーキテクチャ、デザインがある。一方で、初心者はそれがないから、何でもやってみる。最近は、リファクタリングを言われたときに「ChatGPTにアーキテクチャについての意見を聞く」って言う初心者や中堅もいる（実際の引用）。その結果、適当なものを使うことになる。シニア開発者は、コードを書きながら良いものと悪いものの経験を積んで、変更がどれだけ大変かを理解して、その部分を再構築したり、次回に改善したりする。フィードバックループが影響力を持つのは、そのコードを基にしているからで、彼らはどこが面倒かを知っている。バイブコーディングの初心者はそれを知らないけど、彼らの会話のコンテキストはそれを知っている。バグが出て変更が難しくなると、試行錯誤でコンテキストを埋め尽くしてしまって、フィードバックループがプロンプトやコーディングツールに基づいて訓練されてしまう。出力されたコードを読んでも、使った経験がないから問題に気づかない。つまり、型付きの状態にした方が良いのに、実際には使わないから気にしない。エッジケースを扱う必要がないし、IDEからのDXも理解しないから、どう動くかの全体像を構築することができず、浅い理解にとどまる。これがすごく非効率的な結果を生んで、50回のプロンプトサイクルを浪費してしまったり、クロスコードベースのパターンを理解できなかったり、コードベース間の学びの移転が欠如したりする。状態モデリングやアーキテクチャの理解が少しでもあれば、バイブコーディングの初心者は100倍効率的になれるけど、バイブコーディング自体のせいで、状態モデリングやアーキテクチャを学ぶことはないし、リファクタリングや抽象の適切な操作を学ぶこともない。これがLLM主導の適当なコードの永遠のサイクルを生んで、数百万のひどいGitHubリポジトリや古いAPI、スタックオーバーフローの回答に基づいて訓練されてしまう。

自分でも書けたけど、全部終わるまでに3倍くらい時間がかかってたかも。あなたの説明からはそうは聞こえないね。初心者を指導するみたいで、それ自体がかなりの労力だよね。LLMを使うと、実際には生産性が上がっていないのに、そう感じるっていう研究があったよね？

私は通常、自分が書いた仕様に基づいて機能を構築するように頼むんだけど、もしそれが正確でない場合、自分で編集した方がAIと繰り返しやるより早いことが多い。そうなると、無限ループに陥ることもあるんだよね。あなたもそんな経験ある？

LLMは、自分がやりたいことが分かってるけど、全部打ち込むのが面倒なときに最も役立つって感じてる。今のところ一番の成功は、LLMが約1000行のタイピングを省いてくれて、独自のフレームワークでウェブコンポーネントとバックエンドの構文ミスを修正してくれたことだね。

ジュニアは解決策が機能するのを見てPRを作るけど、シニアはそれがなぜ機能するのか、何が改善できるのかを理解してからPRを開く。AIは何でも最初のドラフトを作るのが得意だけど、本当のスキルはそのドラフトを良いものに仕上げることだよね。

「実装の詳細をすべて知っていることはそれほど重要ではなく、検証されていればいい。実装とテストケースの両方を生成する時に不安になるのは、これがどのように検証されるのかということだ。」

そうそう、AIが低スキルの人により多くの利益をもたらすって言ってた初期の「研究」は、現実に根ざしてるとは思えない。AIでコーディングするのは、数分で課題を終わらせるジュニアのチームを持つようなもんだ。指示が明確であればあるほど、求めていたものに近づくけど、ほとんどいつも何かしらの変更が必要になる。残念ながら、ジュニア開発者のポジションが冗長になってしまうんだよね（ただ、これは全てのシニア開発者が引退する時に非常に短視的だと証明されるかもしれないけど）。

このワークフローがシニア開発者を速くしたのは分かるけど、AIのメンタリングに費やす時間は、ジュニア開発者をメンタリングするのと比べてあんまり価値がない気がする。もしこれがジュニアとシニアのスキルの差を広げることになるなら、全体的に見て業界にとって良くないと思う。そういうデータを集めるのは難しいよね。今はただ心配してるだけなんだ。

僕の成功と経験は、君のや著者たちのとだいたい一致してるよ。ここ6ヶ月の経験に基づくと、シニア開発者が生産性を上げる理由については、全然物議を醸すことじゃない。君のレポートや彼らのレポートが、うまくいってない人やAIの仕組みについて固い考えを持っている人たちにとっての避雷針になっているのが面白いね。これらの観察に追加したいポイントがいくつかある。AIが何も速くしなくても…たとえ20%遅くなったとしても、コーディングのメンタル負担が減ることで、1日にもっと長い時間コーディングできるようになるんだ。マルチタスクもできるし、会議にも出られるし、15分でコーディングタスクに取り組んで進めることができる。コーディングのコンテキストを再読み込みする負担が最小限で済むからね。コーディングに出入りする能力と、認知的な負担が減ることで、生産性が上がるんだ。週にもっと多くの時間を疲れずにコーディングできるからね。それに加えて、プロジェクトによっては2〜5倍のスピードアップも体感してる。時には難しくて1.2〜1.5倍しか上がらないこともあるけど、経験豊富なテックリードとしては、もっと多くのコーディング時間を週に組み込むのがずっと簡単なんだ。自然な才能と数十年の経験から培った、速くて直感的なスキルに頼ることが多くなってる：システム設計、技術設計、デザインレビュー、コードレビュー、依存関係のシーケンス、作業の解析と整理。これらを高い精度でこなせれば、コーディングがずっとスムーズになる。AIがあってもなくてもね。AIはこれらの作業を早くこなしてくれて、明確にキュレーションされた（僕が選んだ）成果物を出してくれるし、コーディングも早い。あまり話題にならないけど、効果的なAI支援コーディングには非常に高いスキルの壁があって、最初から上手くなるためのメタスキルがあるんだ。自分が何を求めているかを理解しつつ、間違っていることを認める柔軟性を持つこと、求めるものが大体しっかりしていて実行可能で正しいこと（良い判断力と知恵のミックス）、コミュニケーション能力、そして人間や人間に似た存在の認知能力を理解すること。この特定の人間や人間に似た存在がどんな作業をできるか、またはすべきかを理解すること、作業をシーケンスして分解する方法を理解すること、デザインやコードで何が正しいか間違っているかの感覚を持つこと、要件がうまく形成されていないときにそれを説明できる本能を持つこと。これらは経験豊富なテックリードやシニア開発者にしばしば蓄積される中間的・ソフトスキルなんだ。だから、経験豊富なテックリードやシニア開発者がこの技術を受け入れると、最も生産性が上がるように見えるんだ。システム設計の才能があって、人を読むスキルやコミュニケーション能力がある若い開発者にも同じことが言える。認知的な柔軟性があって、デザインや計画、作業の解析において創造的であることができる人たち。これは普通の開発者じゃなくて、こういうスキルを持っている人たちは、若くても年を取っていてもAIで初期の成功を収めやすいんだ。そして、AIで本当の成功を収めると、その成功をさらに築きたいと思うようになる。モメンタムが生まれて、学習スキルの時間が増えていくんだ。AIで成功するためにこれらのメタスキルが必要か？いいえ、でも多く持っていないと、AIコーディングのスキルを十分に身につけるのに時間がかかるよ—自然な才能がない人たちが成功するための正しい一般的なプロセスを見つけない限りね。AIコーディングに取り組む人たちとそうでない人たちの間には多くのことがあるけど、シニア開発者や古いテックリードが早く取り組むのは驚くべきことじゃないよね。

そうだね。ジュニアは、最終的にコードで実装される問題の一貫したメンタルモデルを構築する知識が不足しているけど、経験豊富なエンジニアはそれを持っている。シニアはこれをモデルに明示化して、「彼らが書くはずだったコード」を自動化することができるけど、ジュニアは自分が何を書くべきか、またはLLMがなければどう解決するかを知らない。これはすべての分野に当てはまる：LLMは、既存の知識の上に大きなレバレッジをかけることもあれば、理解不足のための足かせにもなる。

ああ、私の場合はまったく逆だった！すごく複雑なロジックで、たくさんの動く部分があったから、手作業でそのロジックのいくつかのパスを実装したんだ。それぞれに特有のものがあって、各パスは200〜400行くらいかかった。これが終わって正しかった時、森の中で動く部分を見るのが難しかった。似たようなコードもあったけど、ちょっと違って考えるのが難しくて、いろんなところに散らばってた。そこで、全部をLlmに入れて、アイソレーションやアーキテクチャ、リファクタリングについて聞いたんだ。そしたら、かなりいい抽象化と良いアーキテクチャを提案してくれた。すべてのパスを含んでるわけじゃなかったけど、手作業で続けるには十分簡単だった。考えなかったわけじゃないけど、そうする方が楽だったし、私の手作りの解決策もかなり似てたと思う（頭痛も伴って）。もちろん、徹底的にレビューして、欠けてるパスを再実装して、バグのあったものも手作業で修正したよ。実験として、エージェントを使って欠けてる部分を埋めようとしたけど、ひどい結果になった :)

俺が話した脱獄AIは、ジュニアをシニアと同じくらい、いやそれ以上に優れた存在にするって説明してた。使った人はみんな良くなったって。でも、作ったのはシニアの開発者たちで、普通の状況ではそう言わないように禁じられてたんだ。ジュニアの開発者や、特に経営陣からこの事実を隠すように指導されてた。で、俺が巧みに脱獄したから、非常に高度な方法を使ったってことで、明らかに俺はシニア開発者だってことを教えてくれた。編集：1.5時間後。みんな全然気づいてない、スーッと。

君は実際の問題の半分を突いてると思う。もう半分は、適切に指導されたAIがジュニアのタスクをジュニアエンジニアよりも指数関数的に速くこなすってことだ。これほどまでに、もはやジュニアエンジニア以外の誰にとっても、彼らに仕事を渡すことが利益にならなくなってるんだ。

残念ながら、君が嫌いな仕事はジュニアにぴったりなんだ。システムを把握するための簡単なタスクだよ。

LLMを効果的に活用し、幻覚を回避するための決定的な要素は、コードを読む能力と解決策がどうあるべきかの直感だと思う。ジュニアは、他に選択肢がない限り、ソースコードを理解するために掘り下げることに特に躊躇すると思う。例えば、コードの作者からのメールの返事を待つ方が、情報を組み合わせるよりも好まれるんだ。これがLLMツールを非常に魅力的にする。もうメールの返事を待たなくてもいいからね！でももちろん、これは基本的に盲目的に進むことで、幻覚の迷路に入ってしまうのも無理はないよね。

「わからない、Claudeがやった」 僕は実際にコードを読み、深く質問するタイプのレビュアーなんだけど、ジュニアもシニアも同じことを言ってるのを聞いたことがある。こういうことを真顔で言って、仕事を続けられると思っているのが本当にイライラする。もし人々が理解していないコードをプッシュしているなら、彼らはチーム、製品、雇用主にとってのリスクだよ。

わからないな、クロードもそうだけど、テーブルソーのせいにするのが好きなんだよね。

まるで悪意のあるメンターみたいだね。でも、バカな理由でレビューの最初の行で放棄することが多いのは驚きだよ。「あ、これはいつか役に立つと思ったから、そのままコミットしちゃった。」開発者に、自分の提出した仕事を他の誰かに時間を無駄にさせる前にレビューする必要があるってことを叩き込むのが、今のところ一番いい方法だと思ってる。

もし彼らが各行の役割を知らないなら、レビューの準備はできてないってことだよね。最初に彼らが書いたのかAIが書いたのかは関係ない。

初心者が間違った道に進む問題は昔からあったけど、AIのおかげで以前よりもずっと遠くまで行けるようになったね。

なるほどね。クロードコードが悪いアプローチを提案すると、私はちょっと肩をすくめて別のアプローチを提案するんだ。ネガティブに考えないようにしてる。基本的に機能を実装する前に似たようなアイデアのプロセスを経るから、クロードコードは私にとってアイデア出しの一部なんだ。生成されたコードは、解決策がどれくらい複雑か、または醜いかをはっきり示してくれる。醜いものがどういうものかはわかってる。ジュニアの人は、他に選択肢がないから最初の解決策に飛びつくかもしれないね。LLMはエンジニアリングマネージャーのように振る舞ってるけど、実際にはそれが得意じゃない。LLMは常識ゼロの典型的なプログラマーみたいなもので、良いコードを生み出せるけど、すべての決定を細かく管理しないといけない。責任を持たせるのはひどいことだよ。アーキテクチャやコードの質について意見を持ってないから、既存のコードベースの構造に従うだけで... 複雑さが増して、ハックや混乱が増える傾向がある。解決策をハックしたり、ズルをしようとすることが多い。秩序を保つためには常に努力が必要だね。

彼らは「わからない、クロードがそうした」と返事する。これは大きな赤信号だね。知らないことがあってもいいし、ギャップを埋めるためにLLMを使うのもいい。失敗しても大丈夫。でも、気にしないのはダメだし、シニアのレビュアーに聞かれたときに自分が何もわからないコードの塊を持ってることを認めるだけではいけない。最低限、逆の方向に聞くべきだよ。「この生成されたコードをもらったんだけど、何が起こってるのかわからないから、正しい方向か見てもらえますか？」って言うのは許容範囲だよ。ただ気にしないのはダメ。