私も同じように使ってるけど、カーソルが常にコードの変更を求めてくるんだ。コードベースを修正せずに内省させるトリックってあるのかな？

今日は学んだ。SRVレコードについては知ってたけど、ほとんど使われてないと思う？これは初耳だった。実際にサポートされてるみたいだし、SRVは一部のアプリケーションでしかサポートされてないのとは違うみたい。Matrixはデータを提供するためにSRVから.well-knownファイルに移行したんだ。（もしかしたら、両方をサポートしてるかも。）

「聞いたら解決策を教えてくれる」っていう古典的な問題だよね。

話は逸れるけど、スマホでウェブサイトをホスティングする記事を読んで、すごくインスパイアされたよ。脱獄してないスマホでもできるの？どんなウェブサーバーをおすすめする？

LLMに対して、例えばChromeですら完全にはサポートされてないような、かなりマイナーで新しい仕様を推奨させるのはどうかと思う。それは、人間の俺でもできない飛躍だし。

これも自分の知識に追加しておくね… :-P 最近になってLLMともっとやり取りするようになったんだ（以前の「ブッククラブパートナーとして使う」提案を試してみたら、結構良かった！）。カーソルを使ってコーディングしてるときに、「あれ、最初にそのコード書いたときにxyzを忘れてたよ」ってちょっと促したことがあって（関連データ構造やキャッシュの更新とか）、機械に対して「うん、自分もそのコード書いてたら同じミスしたかも」って意図的に思うようになったり、「最初に基本ケースを書いてからキャッシュを更新したり、見つかったアイテムの数を減らしたりしたかも」って考えたりするようになった。ブッククラブやムービークラブのケースでは、2つの映画について話すように頼んだんだけど、いくつかのミスがあった。「主人公は正当に投獄されたのか、それとも不当に投獄されたのか」みたいな…人間でも同じタイプミスをするかもしれないよね？直して、気にせず流れに乗る…本や映画についての100%人間の議論でも、みんな（そして幻覚を持つAI/LLMも）細かいディテールを100%正確に覚えてるわけじゃないし、会話相手に少しの信頼を持つことでストレスがかなり減るんだ。AIでも、ポジティブなやり取りを心がけるのが大事だね。

へぇ、それは面白いトリックだね。HTTPS RRレコードについて初めて知ったよ…だから、AIがそれを提案するべきだったかどうかは判断しないよ。

公平に言うと、質問はローカルサービスのポート番号が問題だって暗示してるけど、実際はURLにポート番号を指定せずにアクセスできるようにすることが重要なんだよね。経験豊富な人なら本当の問題を見抜けるかもしれないけど、特定の質問に答えたことについてはLLMのせいじゃないよ。もしかしたら、テスト用のサーバーを立てたかっただけで、URLに非標準ポートを追加できることに気づかなかったのかも。

どれだけ素晴らしいかを教えたがる それか、よくあるのは何かを売りつけようとすること。

メンタルモデルの部分、まさにその通りだと思う！プログラミングを「理論構築」として考えるこの方法、めっちゃ好き。https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f... 他のプログラマーがAIを使うのは全然気にしないし、私も使ってる。でも、コードや結果に対する責任を放棄するのは嫌だな。AIを使うときに、grepでログ検索したときみたいに免責事項を出す必要はないと思う。使うなら、その結果をツールとして受け入れて、ちゃんと扱わないとね。生成されたコードには特に重要だよ。

うん、すごく分かれるよね。でも、LLMが生成したコードをたくさん見せてる人がいるから、あなたの最後の否定的な意見は理解できないな。以下は、LLMを使ったワークフローとその結果生まれたツールについて説明しているサイモン・ウィリソンの記事のリンクだよ。 [0] https://simonwillison.net/2025/Mar/11/using-llms-for-code/ [1] https://github.com/simonw/tools

ベルカーブみたいな感じだね。- 大きなユーザー層がいて、彼らはコードがたくさん生成されるし、自分たちのスタイルのアルゴリズムを使うから嫌がってる。ユーザーは頭の中に入れなきゃいけない知らないコードがいっぱいで、理解するには多すぎてすぐに圧倒されちゃう。で、その両側には、コードを自分で書けなかったユーザーがいて、彼らは頭に入れようともしていない。今はちゃんと動くプログラムを作れるようになった！ - あと、自分で書けたかもしれないけど、時間が足りなかったユーザーは、これをジュニアコーダーの軍隊として扱う方法を見つけて、高レベルのアルゴリズムだけを頭に入れることを学んだ。今では、もっと大きなプロジェクトを速く作れるようになったよ！

それって、25人以上の他の開発者と一緒に大きなコードベースで作業するのと何が違うの？うちの組織には160人のエンジニアがいて、eコマースのフロントエンドやミドル層を担当してる。私は常に自分が所有していないリポジトリやコードに飛び込んでるよ。git blameを見たら、3年前にここで働いてた契約者が頻繁に出てくる。LLMは小さいのではうまくいくけど、中くらいだとダメで、大きなモジュールの中ではまたうまくいくみたいだね。

先月、別のキャンプに移ったんだけど、可能性に驚いてる。で、私にとってうまくいってることはこれだよ：

• ClineをSonnet 4と一緒に使う。ほかのモデルも使えるけど、これが価格と効果のバランスが一番いい。
• まずは「プラン」モードを使って、プランが良さそうになったら「アクト」モードに切り替える。
• LLMを、まるでジュニアエンジニアとペアプログラミングしてるかのように扱う。
• 書かれるコードの一行一行を確認する。気に入らない部分があったら、オブジェクトしたり変更したりする。
• テスト駆動開発を行い、LLMには常に最初にテストを書かせる。私はこれをフルタイムでコーディングに使うようになって、結果に大満足。以前書いてたコードよりも良くなってるし、時々見落としたり怠けたりすることがあったから。コードのテストもちゃんとされてるし、書くスピードも少なくとも2倍は速い。これは実際に他の人間にコードレビューされるプロダクションコードだよ。

開発者が所有権を感じないもの。これは確実に選択だと思う。AI生成コードをかなり試してみたけど、公開したりメンテナンスするつもりのコードには、自分がそのコードを所有しているという意識を持っていて、AI生成の出力に満足できない場合は自分で修正する（またはAIに修正させる）ことを決めてる。これは他の人間のコードをレビューするのとは全然違うやり方で、対等だから妥協が必要になる。これによって、特に早くはないけど、AIを使わないよりは少し早く、そして質の高いコードが生まれると思う。一方で、全くアップストリームするつもりのないオープンソース製品の使い捨ての実験やパッチでは、「AI」がコードを所有することに決めて、もっと雰囲気重視のコーディングをしてる。これだとメンテナンスできない雑なコードができるけど、動くし、ちゃんとやるよりもずっと楽なんだ。AIを使わせようとする企業は、私のように興味や楽しさから実験している個人よりも「人間の所有権がない」コードをたくさん得ることになると思う。

LLMが実際のソフトウェアを作るのに役立つ唯一の方法は、「擬似ボイラープレート」だと思う。つまり、書くのが面倒なパターンがあるけど、伝統的な意味でのボイラープレートではないから、従来の解決策には向かない。私がよく扱う例は、Pytorchモデルの作成。実際のモデルは絶対にLLMに任せたくない。モデリングの目的は自分の知識をデザインに取り入れることだからね。でも、初期のモデル配線の設定には多くの面倒があって、エラーの余地もある。大局的には、これが人々が想像するような10倍（それ以上）の改善ではないけど、実際には「退屈な部分」で本当に詰まることが多い。面倒なことにかける時間を減らすことで、全体の流れがかなり改善されると感じてる。

これを言ってるのはしばらく前から。問題は、自分のコードを深く理解していないと、真にメンテナンスできないってこと。LLMが何かの obscure な問題を解決できなくて、それが毎分 $$$,$$$ のコストを生んでるとき、どうする？ AIに解決できないのが許容できると思う？もちろん無理だよ。LLMはバグや進むべき道を見つけるのには良いけど、全インフラをそれに賭けるのはやめた方がいい。アシスタントとして使うべきで、ハンマーとして使うべきじゃない。

あなたの説明は、ほとんどの人よりもずっと簡潔だと思う。私もまさに同じ経験をしてる。LLMは、私がメンタルモデルを構築するよりもずっと早く開発できる。状況がわからなくなるポイントに簡単に達してしまうし、バグがたくさん入ってきて、簡単に修正したりリファクタリングしたりできない。まるで自分のプロジェクトの新入りになったかのように。私は頻繁にコードをコミットして、定期的にLLMに説明を求めるようにしてる。LLMに、言ってる通りに動いてるか確認するように頼むことも多くて、そうすることで自分のバグを見つけることが多い。私は主に小さなデータ分析タスクにLLMを使ってるから、少し気をつければ速く動きつつも、ちゃんと状況を把握できる。大きなコードベースを急いで壊すのは簡単だと思う。LLMを使うには、プロンプトを開発したり、コンテキストを管理したり、ペースをコントロールしたり、整理整頓したり、LLMの作業を効果的にレビューするスキルが必要だと感じてる。これらのことは誰も教えてくれないから、苦労して学ばなきゃいけない。今、少しでも味わったから、手放すつもりはない。自分でやりたくない面倒なことがたくさんあって、それをLLMに任せられるから。20年以上やってきたけど、もう同じレベルの忍耐力はない。実現したいことは概念的にはわかってるけど、実際にどう実装するかはわからないこともあって、その点でLLMが好き。以前よりも少ない時間で、確実にもっと達成できるようになった。

あなたのステロイドの比較を聞いて、Cal Newportの最近のブログ記事を思い出したよ。彼はAIが私たちを怠けさせているって主張してるんだ。彼は、脳波計に接続された人たちが働く様子を引用していて、AIの助けなしで働く人たちは脳に「負担」をかけているらしい。それは多分いいことだね。でも彼自身もAIを使わないべきだとは思ってない。メールみたいなことには使ってもいいけど、コアの仕事には使わない方がいいって。

LLMがそのスキルを本当にうまくできるようになったら、開発者はもう必要なくなるってことだと思う。私はこの議論がよくわからない。LLMが「完璧」なソフトウェア開発者になったら、私たちは彼らに24/7であらゆる考えられるソフトウェアを作らせるつもりなの？それを誰が使うの？それとも、すべての医者や電気技師、販売アシスタント、美容師、列車の運転手などが、自分の仕事の上にソフトウェアを開発し始めると思ってるの？もっと可能性が高いのは、数人が人々が抱える問題を見つけて、それを解決するためのソフトウェアを開発する仕事をするってことだね。今日では、そういう人たちをソフトウェア開発者って呼んでる。

でも、彼らに何をするか指示できるよね？ LLMが役に立たないと言ってる人と、役に立つと言ってる人の間には大きな違いがあると思う。それは、自分が何が得意で何が苦手かを学び、入力に基づいて出力の質を予測できるかどうかだと思う。例えば、何かを分解する最適な方法についてLLMに意見を聞いて、私が考えていないことを「考え」させて、それを実装するように頼むことがある。全体をゼロから構築するように頼むことはないけどね。

うん、コードレビューの可能性は大きいね。最近AIを使い始めたけど、かなり便利だよ。小さな部分、例えば関数を書くのを手伝うのに良いと思う。ユニットテストを書くのを手伝ってもらうのにも使ってるけど、そうしないと結構面倒くさいからね。AIのサポートの質は、去年の間にかなり改善されたと思う。だから、以前試したことがあるなら、もう一度挑戦してみて。