最適なLLM支援コーディング体験の旅を続けます。特に、完璧な 1 つのことに絞り込むのではなく、私の使用法は、長所と短所を「つなぎ合わせる」いくつかのワークフローにまたがってますます多様化していることに気づきました。 個人的には、私のLLM支援のパンとバター(~75%?)は、引き続き(カーソル)タブが完成しただけです。これは、コード/コメントの具体的なチャンクを自分で書き、コードの右側に書くことは、「タスク仕様」をLLMに伝達する高帯域幅の方法であることがわかったためです。 そして、コードを適切な場所でデモンストレーションする方が速いです。タブコンプリートモデルが面倒なことがあるので、オン/オフを頻繁に切り替えます。 次のレイヤーは、コードの具体的なチャンクを強調表示し、何らかの変更を求めることです。 次のレイヤーアップは、Cursorの側で実行されているClaude Code / Codex などで、プロンプトで指定するのもかなり簡単な大きな機能のチャンクのために使用します。これらは非常に役に立ちますが、それでも全体的にまちまちで、時々少しイライラします。YOLOモードでは走らないのは、彼らが軌道から外れて、あなたが望まない/必要のない愚かなことをする可能性があり、私はかなり頻繁にESCをするので、私はYOLOモードで実行しません。また、複数のインスタンスを並行して使用して生産的になることを学んでいません - すでに十分に難しく感じています。I haven't figured out a good way to keep CLAUDE[.]MD 良好または最新。コーディングスタイルやコードの好みの問題のために「クリーンアップ」を行わなければならないことがよくあります。たとえば、防御的すぎてtry/catchステートメントを過剰に使用したり、抽象化を複雑にしすぎたり、コードを肥大化させたり(たとえば、リスト内包表記やワンライナーのif-then-elseが機能する場合の入れ子になったif-the-else構造)、または優れたヘルパー関数を作成する代わりにコードチャンクを複製したり...基本的に味覚がありません。これらは、あまり馴染みのない、よりバイブコーディングの領域に少しずつ入った場合(たとえば、最近Rustを書いたり、SQLコマンドを書いたり、以前にあまりやったことのないものなど)に不可欠です。また、CCが書いているコードと一緒に何かを教えてみましたが、それはまったく機能しませんでした - 途中で何かを説明したいよりも、コードを書くことを望んでいます。CCにハイパーパラメータのチューニングをさせてみたのですが、とても面白かったです。また、あらゆる種類の低リスクの 1 回限りのカスタム視覚化やユーティリティ、または時間がかかりすぎるため決して書かないコードのデバッグにも非常に役立ちます。たとえば、CCは、特定のバグを特定するためだけに、1,000行の1回限りの広範な視覚化/コードをハンマーで打ち出すことができ、バグが見つかったらすぐにすべて削除されます。今はコードの希少性後の時代です - 何千行もの超カスタム、超一時的なコードを作成して削除するだけで済みます。 防御の最後の層は GPT5 Pro で、私は最も難しいことに使用します。たとえば、私/カーソル/CCがすべて10分間バグでスタックしているということが何度か私に起こりましたが、すべてを5 Proにコピーペーストすると、10分間消えますが、実際には非常に微妙なバグが見つかります。とても強いです。あらゆる種類の難解な文書や論文などを掘り起こすことができます。また、抽象化をクリーンアップする方法に関する提案(結果はまちまちで、時には良いアイデアですが、すべてではありません)や、人々がこれやこれを行う方法に関する文献レビュー全体など、他のより充実したタスクにも使用しました。 とにかく、コーディングは、多くの「種類」のコーディングと、長所と短所を持つ多くのツールにわたる可能性で完全に吹き飛ばされたように感じます。集合的に可能なことの最前線にいないことに対する不安感を避けるのは難しいため、日曜日にランダムに考えが飛び交い、他の人が何を見つけているのかについてかなりの好奇心を抱きます。