私の最初のプロンプトのほとんどは「まだコードを書くな」で始まる。 俺はまず行動計画を聞くのが好きなんだ。実際に編集やファイルに触れる前に、何をするつもりかを知りたい。

LLMは何も学んでいないかもしれないけど、俺は学んでいる それに関しては、個人的には彼らが実際にインタラクトから学んでくれたらいいなと思う。ユーザーの視点からすると、俺がやりたいのは、これまでLLMが学んだことをファイルに「保存」できること。後でそれを復元して、LLMにその内容を「再学習」させることができるようにしたい。今はさまざまなフロントエンドUIでこれができるけど、俺が求めている重要な部分は、a) この「再学習」が現在のコンテキストウィンドウに影響を与えないこと（正直言うと、この概念自体がなくなってほしいけど、それは別の話）と、b) 情報を失うようなロスのある再学習でないこと。いくつかの解決策はあるけど、根本的な問題へのバンドエイドに過ぎない。例えば、これまでの議論を要約して再スタートすることはできるけど、明らかにそれはロスのあるメモリ圧縮に過ぎない（人間が同じことをできるのは気にしない、LLMはコンピュータ上で動いているソフトウェアだから）。あるいは、RAGのようなものを使うこともできるけど、AFAIKこれは「プロンプトトリガー」によって機能する。つまり、あなたの「現在の」インタラクションを通じてのみ、知識がそこにあっても、今やっていることがそのインデックスをトリガーしないと、LLMはそれに気づかない。俺が求めているのは、例えば、LLMにfooという関数がmooオブジェクトをバーフィズするために使われることを伝えた後、さらにそのコンテキストの長さを超えて他のことを伝え、議論を保存して、次の日に復元し、さらに他のことを伝えた後、スプラファーに参加する方法を尋ねたら、前回のセッションからmooオブジェクトやバーフィゼーションについて何も言っていなくても、スプラファーに参加するにはバーフィズされたmooオブジェクトに変換すればいいと教えてくれること。 （それに、こういったメモリの保存/読み込みは明示的であるべきだと思う。クリーンスレートから始めたいからで、これは技術の限界を回避するためではない）

まだコードを書くな。笑 俺もいつもそうしてる。これは、再現する前に何をしているのか理解するために、いい方法だと思う。コードを書くのは好きじゃないけど、問題解決や論理、統合の部分は大好きなんだ。

どうやって良い製品を作るか考えてるんだね。今のところ、明確な前提デザイン以外に何を考えた？

まず、LLMを使ってコーディングする熟練エンジニアも、ソースコードを作り始める前に考えたり話し合ったり、ぼーっとしたりするんだよね。そう、考える時間は全体のソフトウェア納品において重要な部分だから、コーディングの部分を早めても全体の生産性や労働要求が劇的に変わるわけじゃないんだ。

自己管理ができる人間は少ないよね。これがほとんどの反AI記事のポイントみたいで、私も同意する。

私の最初のプロンプトのほとんどは「まだコードを書かないでください。」から始まる。IntelliJではすべての変更を承認しなきゃいけないから、このプロンプトは必要ないんだ。承認なしで勝手に変更するYOLOモードがあるけど、私はそれを使ったことがない。誰か使ってる人いるのかな。

「LLMはツールだよ。ツールってのは、事前に期待通りの仕事を高確率でこなすって分かってるか、明らかに失敗する（低確率で）って分かるもの。LLMの場合、信頼できるタスクはほとんどないし、失敗の仕方も分からない。成功を報告しながら失敗することもあるし、人間でもツールでもない動き方をする。LLMは、バグだらけのコンパイラみたいで、間違ったコードを出力しながらも成功を報告することが多すぎる。バグの場所が分からないから、唯一できることは、別の構文で同じようにプログラムを書いて、バグを引き起こさないことを願うこと。それはプログラマーがよく使うツールじゃないよ。こんなコンパイラで作業するスキルは身につくけど、そのスキルがどれだけ移転可能か、持続可能かは不明だね。もしLLMが一部の人が信じるほど大きく早く進化するなら、バグのあるコンパイラが修正されるのを待った方がいいかも。今よりも少ないスキルで同じ結果が得られるようになるだろうし。」

俺の意見は、デバッグは書くよりも難しいから、書かずにデバッグするよりは、最初から書いた方がいいってことだね。

テクノロジーが人を怠けさせるっていう考えに依存しない反AIの意見が見てみたいな。この記事はそのアイデアでちょっとズレてるけど、AIによるコーディングが生成するコードの深い理解を奪うっていう指摘は、AIコーディングに対する有効で重要な批判だと思う。ソフトウェアエンジニアの主な仕事はコードを作ることじゃなくて、機能するソフトウェアシステムを作ることなんだよね。それにとって一番大事なのは、コードがどう動くかの「メンタルモデル」と、そのドメインに対する専門知識。コードはそのメンタルモデルの派生物に過ぎない。大きなプロジェクトになると、著者としての理解度には及ばないし、読者としての理解も限界がある。ソフトウェアのメンタルモデルを構築しないことには他にも影響があるよ。構文レベルでの推論には限界があって、LLMベースのコーディングエージェントはそれを超えるのが難しいみたい。

テクノロジーが人を怠けさせるっていう考えに依存しない反AIの意見が見てみたいな。私の意見だけど、たまにClineを使ってコーディングするけど、最近は手でコーディングすることが多い。理由はシンプルで、AIツールを使うと大抵はコードを書く代わりにプロンプトを書くことになるから。こう考えてるんだ。プロンプトを書く時間と推論時間が、手でコードを書く時間より短ければ、AIを使うことが多い。でもこれはリファクタリングのタスクの時だけで、そこでのボトルネックは指が打つ速さだと思ってる。ほとんどの他の問題ではこうなる：手動で10分かかるタスクをAIに頼むと、プロンプトを作って実行するまでに8分かかる。確かにそのタスクで2分の節約にはなるけど、AIが間違えなければの話ね。もし再度プロンプトを作り直したり、手動で修正する必要が出てきたら、結局そのタスクにかかる時間は10〜12分になっちゃう。最良のシナリオは、AIクレジットを使ったのに時間の節約がゼロだったってこと。最悪の場合は、AIクレジットを使った上に、タスクが遅くなったってこと。今ではいろんなタスクでこの計算をしていて、大抵は手でやる方が「安全」だと感じてる、コードの出力に関しても、タスクにかかる時間に関してもね。

「もし考える部分が一番好きなら、AIを使えば、コンセプトからトラブルシューティングまで、ほぼ全ての時間をそこに費やすことができるよ。でも、この議論はちょっと薄っぺらくなってきたね。毎日何度も、少し言い換えられて目にするよ。『何年も『練習』をしてこなかったら、考えることがどれだけうまくいくと思う？』って返すと、いつも沈黙か、話がズレるんだよね。だから、もちろん『考える』部分に集中し続けていいけど、十分な『行動』がないと、考えはどんどん浅くなっていくよ。」

@shredprez あなたのプロフィールにあるウェブサイトは、AI駆動の製品を販売してるみたいだね。「Claude、Cursor、またはVS Codeで何でもデザイン」って。次回は免責事項を残すといいかも。今の半端なAI製品が成功することに利害関係があるみたいだね。

まあ、私個人としては、LLMや似たような機械学習アプリケーションがメンタルの敏捷性に悪影響を与えるという主張をしたことはないんだけどね。今までの主張には以下のようなものがあるよ。 — どんなクリエイティブな作品もLLMの産物だと言えるようになると（今や新しいアーティストやコピーライターにとって現実の話）、人間が完全にオリジナルなクリエイティブな作品を作る動機が大きく減ってしまって、創造性や革新性に悪影響を及ぼす。 — 結果が手段を正当化するわけではない、という一般的な哲学的議論。大規模な知的財産の盗用は、この新しい機械学習の波の初期において重要な役割を果たしていて、基本的には海賊行為だよ。力のある者や富裕層が、私たち一般人に対して利益のために行っていることなんだから。（彼らはトレーニング用にオリジナル作品のライセンスを取得するお金はあったはずなのに、法的な曖昧さを利用してスクレイピングや悪用を選んだ。） — LLMが情報へのアクセスを仲介するという考えにみんなが慣れてしまうと、不平等が増す（この技術を支配する人たちやその投資家がより裕福で影響力を持つようになり、逆にその犠牲者である大多数の人々は富のスケールで下がってしまったり、仕事を失ったりする）ことが多い。 — 人間性が薄まる。人間らしく振る舞うことで、私たちは他者に人間らしさを示し、彼らから人道的な扱いを受けるに値する。もし人間と全く同じように歩いたり話したりする存在が一般的になったら、私たちがその存在に対して非人道的に接することが、他の人間同士の扱いにも影響するんじゃないかな。 — ボットのトラフィックが人間のトラフィックを圧倒するようになって、オープンなオンラインコミュニティを運営するのが難しくなってきてる。（これもLLM自体に対する批判ではなく、大企業や国家がどのようにLLMを訓練し運用しているかに関するものだよ。普通の人が自分でホスティングしようとしても、こんな規模で混乱を引き起こす技術的な能力はないだろうし。） これは私が思いつく限りのことだね。

AIを使えば、コンセプトからトラブルシューティングまで、ほぼすべての時間をそこに費やすことができる。 それは違うよ！インタラクティブなIDE AIを使っていると、AIを正しい方向に保つために時間を使ったり、元のタスクが何かを思い出させたりすることになる。エージェントを使っているなら、中間的な思考や計画をすべて委任しているわけで、残るのはインターンでもできるような具体的な要件を書く作業だけど、これは「ソフトウェアエンジニア」よりも「ビジネスアナリスト」に近いよね。

アセンブリやマシン言語でコーディングできない人が増えてるって文句言ってる人たちみたいだね。新しいコンパイル言語とか…現代の厳密に型付けされた言語を使う人たちも。新しい型安全な言語とか… NANDゲートを回路基板に配線してた頃からコーディングしてる私としては、新しいやり方には賛成だけど、間違いや行き止まりもたくさん出てくるだろうね。どんな大きな進歩にもそういうのはつきものだから。

結局のところ、エンジニアはプログラムに何をさせたいのかを正確に指定しなきゃいけないのが問題だと思う。Pythonでも英語でもできるけど、最終的には同じ動作を得るために同じ情報を入力しなきゃいけない。LLMがこれを少し効率的にしてくれるかもしれないけど、英語でも曖昧さなく正確に指定するのは非常に難しい（場合によってはPythonよりも難しいこともある）。

私の経験では、コーディング作業の「物理的」な経験が、ソフトウェアデザインのメカニクスやトレードオフ、落とし穴、一般的なデザインの風景などを理解するために必要なんだ。作業の「メンタル」な部分をきれいに分けることはできないと思う。コードを反復して書くことで、メンタルモデルが構築されるし、単にコードをレビューするだけでは得られない、もっと表面的なレベルでしか得られないことだと思う。

「考える部分は同じだけど、修正は違うと思う。自分が書いたものを修正するのは、他の誰か（またはAI）が書いたものを修正するよりずっと簡単だよ。コードのメンタルモデルがないから、デバッグやリファクタリングで最も重要な部分が欠けてるんだ。」