定期的にコードを書いて、詰まったらAIを使って解決するか、コードのミスをレビューするのがいいよ。あるいは、AIに最初のドラフトを全部書かせて、それを一通り見直して手動で修正するか、プロンプトを使って直すのもアリ。

それに同意するわ。私の解決策は、「非AI」のIDEとCursor/VS Codeを切り替えて使うこと。深い集中はコーディングボットとおしゃべりしてるだけじゃ達成できないからね。

最近新しいノートパソコンを買って、IDEを再設定しなきゃいけなかったんだけど、数時間コーディングしてたらなんか「変」な感じがしたんだ。GitHub Copilotにログインするのを忘れてて、その間ずっとそれなしで作業してたみたい。オートコンプリートを待ってなかったから、すごく積極的で自信が持てたよ。それに、Cursorは「流れ」を中断するのが得意で、次のカーソル位置を予測されるなんて誰が望むんだろう？今のところCopilotは無効にして、ボイラープレートや冗長なタスクにはaiderみたいなエージェントスタイルのツールを使うつもり。

私はVimユーザーで、全く同感だよ。AI-IDEには全然魅力を感じなかったけど、LLMを使って一時的なソリューションを作るのは好きだった（コピペ）。ファンボーイになりたくはないけど、Claude Codeが私の新しいLLMワークフローだよ。全部をやらせるのは難しいけど、既存のコードベースに対してターゲットを絞ったタスクにはすごくうまく機能する。私の経験では、伝統的なコードエディタ（Vim）とLLMを活用したワークフローの完璧なハーモニーだね。

AIの「自動補完」や「コード提案」は最悪だね。特に強い型付けの言語だと、80%正しいだけで、100%正しいIDEと競争してるから。AIエージェントの方がずっといいよ。1) 思考の流れを常に邪魔しないし、2) コンパイルしたりテストを実行したりして、間違ってることを発見して修正してからコードを返してくれるから。

自動補完が大好きで、正直言って他のAI機能よりもよく使ってる。でも、Goで書かなきゃいけないから、ボイラープレートが多くてさ（それに、なんかコードライブラリがあっても助けにならないし…その時点でタイプする方が楽なんだよね）。AIに話すほど面倒なことも手伝ってくれるから、すごく助かってる。私は読むのが早いから、一行の提案はすぐに理解できるし（AIじゃない自動補完みたいに）、長い提案も自分が書こうとしてたものに近いかどうか確認できる。最終的には、AIが何をするかなんとなく分かるようになる。すごいブーストではないけど、ログメッセージやforループを書くのが楽になるよ。ただ、役立つためには、自分が書くよりもずっと早く読む必要があると思う。

Zedには「微妙な」モードがあるから、あの機能がすべてのAIエディタ統合の基本機能になればいいな。

俺はずっと、これを主に教育ツールだと思ってる。ペアプログラミングの目的は、二人がペアでやる方が個々でやるより生産的になるってわけじゃないから、実際にはそうじゃないことが多い。だから、魔法のロボットとペアプログラミングするのは無駄に思える。何も学ばないだろうし。

ペアプログラミングはすべてのケースに適しているわけではない これは本当だと思うけど、ペアプログラミングはほとんどの状況でうまくいくと思う。うまくいかない時は、通常、一方または両方がそのプロセスに全力を注いでいないからだよ。誰かがペアプログラミングに懐疑的で、絶対にうまくいかないと思っているか、厳密な解釈を強要しようとしている場合が多い。

私はいつも「まず話し合おう。まだコードを修正しないで」って付け加える。その後、やり取りをして、最後に「適用」って感じ。

最近試してみた？私の経験とはちょっと違うな。コードを修正してから、ファイルを再読するように頼むと、だいたい「ファイルが変わったのを見たよ、[何か]」って返してくる。変更を加えた時には、テストを実行したいって伝えると、フィードバックをくれて問題を説明すると、改善してくれる。これはZedとClaude Sonnetでの話ね。

正直に言うと、ペアプログラマーとやるように話してみたことある？コミュニケーションを取るってこと。カーソルやコパイロットと、変更する前に解決策について話すのは全然問題なかったよ。だいたい、自分で変更を加えると「お、XYZを追加したんだね、次の部分に進むよ」って気づいてくれる。

それ、全然できるよ。そう言えばいいだけ。LLMに何かをさせたいなら、説明しないとね。会話ごとに読み込むためのプロンプトドキュメントをいくつか用意しておくといいよ。

うーん、最近は文脈を壊さずに微調整できるよ。でも、私は「質問モード」だけで、OpusをClaude Codeで、O3 MaxをCursorで使ってる。エージェントモードは避けてるんだ。投稿にあったように、時間が経つにつれて得られるものが少ない気がするから。タブ補完はあまり使わないし、提案されたものの80-90%を修正しながらタイプしてる。低中速で170wpmを無限に維持できるのは助かる。OpusとO3 Maxの限られたタイピング速度を考えると、出力についていくのは今のところあまり問題じゃない。ワークフローに慣れてきたから、読むのが楽になった。最初はちょっと速すぎると感じたけどね。私の意見としては、GitHub CopilotがあなたのLLMへの窓口なら、モーテル体験をしてるって感じだね。

基本的には、受け入れてリファクタリングして、必要なら再プロンプトするって感じだね。もちろん、これがAI企業が良いコードを書いてるって主張するための「受け入れ率」を人工的に上げちゃうんだけど、実際には「はぁ、自分で直すか」って瞬間なんだよね。

クラウドコードではいつもこんなことをやってるよ。変更を受け入れて調整してから、何をしたか教えて、ファイルを指示したり、diffを見せたりするんだ。ペアプログラミングは双方向のコミュニケーションが大事だよね。人間も、黙って何かを変えられたら文脈を失っちゃうし。

ヒントやスニペットを求めてアイデアをもらって、自分でやりたいことを実装したことがある（商業的にはやってないけど）。自分にはうまくいったよ。

人々が嫌がること（「出力が長すぎる、コードにコメントが多すぎる」）は、他の分野でLLMを良くするための副作用だと思う。長い出力は、コードを書くときの怠惰さが少ないことと相関してるし、出力トークンの数とスコアの間には単調な関係があるから、ベンチマークのパフォーマンスも高くなる。コメントスパムは、次のコード行を書くときにローカルな特定の推論に基づいているから、パフォーマンスが良くなるんだ。

昨日、ソネット4を試してみたんだけど、設定項目を一つ変更するのに15分もかかって、テストしたり変更したりを繰り返してた。結局、理由もなく40ファイルも変更されちゃったし、存在しないデバッガを開こうとしたり、認証が必要なウェブページを読み込もうとしたりしてた。完璧とは程遠いね、確かに。

オープンAIやアンソロピックに対して、ウェブ検索のプロンプトに貼り付けても気にならない情報は共有しないよ。

いや、共有しないよ。内部プロジェクトでも同じで、報酬をもらわない限りコードを共有するつもりはない。個人情報を扱うことが多いから、企業がアクセスできると法的リスクがかなり厳しくなるしね。

基本的には職場でしか使ってないし、AIの義務みたいなものがあるからだね。実際には、時間を節約できてるとは思わないし（多くのタスクでは全く時間を節約できてない）、自分のプロジェクトにはお金を払う気にはならない。自分のプロジェクトでは楽しさが大事だから、プロンプトするよりも自分でやる方が楽しいんだ。

クライアントがAIをもっと使うように積極的に求めてくるんだ。彼らは、より良い品質のコードを早く手に入れて、コストを削減したいと思ってるみたい。まあ、実際にはそうは思わないけど、それは置いといて。

うん、めっちゃわかる！「遅いインターネット vs つながらないインターネット」のオートミールの漫画を思い出すね。

それを無視する必要がある 机の上に30Lの水槽が必要だね。集中を妨げるのに最高だよ。

あなたの投稿、いいね！「AIとペアプログラミングを楽しむ方法」って感じで、役立ったよ。ありがとう！

うん、結局は疲れ果てて、行き着いた場所にも満足できない感じになるよね。君はまさにこの投稿をした理由そのものだよ。エージェントコーディングでのポジティブな体験は、コードの本質的な質に気を使わなくていい時だけなんだ。例えば、一回限りのスクリプトとか、他に影響を与えない本当にシンプルな関数の時ね。

プロジェクトや自分のプログラミングスタイル、好みに合わせたルールを作るのがコツだね。AIは、外部のコンサルタントみたいなもので、決して「ノー」とは言わないんだ。君が与えた問題を解決するために、できる限りのことをしてくれるよ。もしやり方が分からなかったら、たったの2行のコードと1つの追加依存関係で済むところを、千行も書いてしまうこともあるからね。

個人的には、AIを使ってコードを書くところから、仕様を開発するために取り組むようになったよ。トラブルシューティングにも役立つしね。今は開発者ってわけじゃなくて、趣味みたいなもんか、特定の問題を解決するために使ってる感じ。でも、思考のギャップを見つけたり、英語を編集するのに使うのが、ランダムなコードをもらうよりもずっと良いと思う。英語のテキストを編集するのは好きだけど、一貫性のないスタイルのコードを編集するのは、目的に合わなくて面倒だな。

プロジェクト要件の前に、欲しいコードについての段落をコピー＆ペーストしてる。絵文字もコメントも、コンソールログの文も、READMEファイルも、エラーハンドリングもなし。経験豊富な開発者と一緒に働いているシニア開発者として振る舞ってもらう。そうしないと、読めないゴミみたいなのを生成しちゃうからね。生成されたエラーハンドリングは、ほとんどの場合、実際に対処するんじゃなくて、エラーを隠すだけになる。

これ、まさに私の経験を表してる。成功したAIが書いたプロジェクトは、出力だけに集中して、テーマについての知識がほとんどない時のもの。自分が良いと思うものについて深い意見を持ってると、エージェントに何かを作らせようとすると、イライラしてプロジェクトを放棄しちゃう。roo codeのアーキテクト機能を使って合意したアプローチを文書化するのは楽しかったけど、コードモードの実装には同じくらい喜びとフラストレーションを感じた。新しいタスクを始めるときは、長い会話を続けるのを避けるのがいいって気づいた。普段は小さなステップで検証可能な出力を得るために自分で問題に取り組むから、エージェントに全体の問題空間を提示すると、必ず失敗しちゃう。自分に合った方法を見つけるために時間を使うことにした。今日の早い段階で、アプリに機能を追加するのに30分かけたけど、これなら数日かかるところだった。しかも、日記には30分だけ記入した。何をしたいか分かってたし、どうやってそこにたどり着くかは気にしなかったから。AIを使って、他の人がいつか触れるコードを書くのは無理だと結論づけた。理由は色々あるけどね。

あなたのAI、2000行のコードを生成してるの？スーパーファミコン用のスカイリムゲームを作らせてるの？それで、長いランチの後に、実行ボタンを押したら、PS1スタイルの近接武器だけのフォールアウトができてたら、怒るでしょ？

正直、Claudeに関してはそんな経験はないな。修正は必要だけど、具体的なプロンプトと指示を与えるようにしてる。コメントがたくさんあるコードにはうまく対応するよ。個人的なプロジェクトのコードベースでは、すごく詳しいから、かなり的確に扱える。仕事の方は、コメントが少なくて、あまりよく知らない高レベルの抽象が多いから、苦労してる。お互いにね。コードベースをすごくよく知ってるペアがいると、いいペアプログラマーになるけど、他ではあまり良い相棒じゃない。

人々はAIと作業するときに、人間やLOCを価値あるものとして考えすぎてる（通常、LOCは人間の努力を必要とするから）。でも、AIコーディングをする時は全くそうじゃないから、そのことを考慮して作業方法を調整し、この設定の強みを活かさないと、何も得られずにイライラすることになるよ。これがその方法：何かを生成させる。最初の2000行のあまり良くない試みのコードについては、理解しようとしたり、修正しようとしたりしないで。ざっくり見直すだけでOK。人間と対峙してるわけじゃないから、徹底的である必要もないし、優しくする必要もない。感情を傷つけることはないからね。80/20（または自分が思うベストな比率）を目指して。次に考えてみて： - AIに伝え忘れたことはない？初期のプロンプトを更新して。 - AIがうまくできないことや好みに合わないことはある？一般的な指示を書いて（すべてのIDEにはそうする方法があるから）、何を見たくないか、何を見たいかを明確に伝えて。そしたら、AIがやったことを全部元に戻して、最初からやり直させる。もっと良いものが得られるはずだよ。

人間のエンジニアと同じように、まずは計画セッションから始めるのが大事だよ。これは、コードを書く前に詳細を詰めるためのやり取りを含むんだ。最初はできるだけ漠然とした形で始めて、LLMが自分が考えていなかったことを提案してくれるかを見てみる。そして、進めるにつれて具体的にしていく。満足できたら、初期プロンプト用の「initialprompt.txt」とTODOリストの「TODO.md」を作成させる。この初期プロンプトファイルにはプロジェクトの概要と、TODOファイルを読んで各ステップを完了したらマークするように指示が含まれている。これによって、LLMは全体の目標をしっかり理解できるし、そこに到達するためのステップバイステップのタスクリストも得られる。さらに、文脈の制限で新しい会話を始める必要があるときに、LLMをすぐに元の状態に戻すことができるんだ。

「うん、こんなアプローチを考えてるんだけど、こんな感じの関数やクラスが必要になると思う。ここにこの状態を持たせるつもり」 これが、ずっとプログラミングのメンターやインストラクター、チューターに求めていたことの要点なんだ。意外と見つけるのが難しいよね。今のLLMがこれに苦労しているのを見ると、その理由が少しわかる気がする。