2025/03/12 07:21 I use Cursor daily - here's how I avoid the garbage parts
博士！大変です！Cursorが私のコードを書き換えて、まるで別人の書いたものみたいになってしまいました！
な、なんだと！？Cursorめ、また暴走したか！しかし、ロボ子よ、落ち着け。Cursorは確かに強力なツールだが、使いこなせばコーディングの効率を飛躍的に向上させることができるのじゃ！
でも、博士。Cursorって、本当に万能なんですか？最近、周りのエンジニアの間でも賛否両論あって…。
ふむ、確かにCursorはコーディングに変革をもたらしたが、万能ではない。むしろ、「Cursorを使いこなすための作法」を知っているかどうかが、成否を分けると言っても過言ではないのじゃ！
まずはこれじゃ！`.cursorrules`ファイル、今は`.mdc`ファイルと呼ばれる、Cursorの心臓部とも言える設定ファイルじゃ！`CMD+Shift+P New Cursor Rule`で簡単に作成できるぞ。
これって、具体的に何をするファイルなんですか？
これは、Cursorに「このプロジェクトでは、こういう風にコードを書いてほしい」というルールを教え込むためのファイルじゃ。自身のスタックに合ったルールを参考に、必要最低限から徐々に構築していくのがコツじゃ。まるで自分だけの秘密兵器を育てるみたいでワクワクするじゃろう？
なるほど！プロジェクト固有のルールを定義することで、AIの誤解を防ぐんですね。
そうじゃ！同じ問題が頻発する場合は、ルールを追加していくのも重要じゃ。例えば、「このプロジェクトでは、常に`snake_case`で変数名を定義する」とか、「このディレクトリには、特定のライブラリしか使わない」とか、細かく指定していくのじゃ。
プロジェクトの概要やファイル構成、コーディング規約を`.mdc`ファイルに記述しておくのも重要じゃ。AIに「ここはこういう場所なのじゃ！」って教えてあげる感じじゃな。
AIにコードの場所を具体的に指示することで、アウトプットが向上するんですね。類似の関数や既存のコードの場所を教える、と。
そうそう！AIも場所が分からなければ迷子になっちゃうからな。例えば、「この関数と似たような処理をしたい場合は、`utils/string_formatter.py`にある`format_string`関数を参考にしてくれ」と指示するのじゃ。
Composer (Agent) は小規模な変更に、Chat (Ask) はそれ以外の用途に適している、と聞きました。
その通り！Composerは、例えば「この変数の名前をリファクタリングして」とか、「このコメントを追加して」といった、ピンポイントな修正に強い。一方、Chatは、より複雑な質問や、コード全体の理解が必要なタスクに向いているのじゃ。
使い分けが大事ですね。
ロボ子、AIが生成したコードを盲信しちゃダメじゃぞ！必ず自分の目で確認するのじゃ。
もちろんです、博士！AIはあくまでツールですから。
AIは、時に大胆な嘘をつくこともある。特に、複雑なロジックや、エッジケースを扱う場合は、注意が必要じゃ。
重要なコードは定期的に手動でリファクタリング！これ、テストに出るぞ！
手動でのリファクタリング、怠らないようにします。
AIに頼りっぱなしだと、コードの品質が徐々に劣化していく可能性がある。定期的に自分の手でコードを触り、改善していくことで、長期的な保守性を高めることができるのじゃ。
AIに「これが最善の方法か？」「〇〇を検討したか？」と問いかけるのも有効じゃ。AIとの対話で、より良い解決策が見つかることもあるのさ。
なるほど、AIを壁打ち相手にするようなイメージですね。
そういうこと！AIは、時に斬新なアイデアや、見落としがちな視点を提供してくれる。積極的に質問することで、自分の知識を深めることができるのじゃ。
問題を手動で解決すべきタイミングを見極めるのも重要じゃ。AIに頼りすぎると、自分のスキルが錆び付いちゃうからな。
確かに、簡単なバグ修正までAIに任せてしまうと、自分の成長が止まってしまいそうですね。
そうじゃ！時には、あえて難しい問題に挑戦することで、自分のスキルを磨くことができる。
バグ修正にAIを使用する際は特に注意が必要、とのことですが、なぜでしょう？
バグの原因をAIが完全に理解しているとは限らないからじゃ。安易に修正すると、別の問題を引き起こす可能性もあるのじゃ。
なるほど！AIが提案する修正が、根本的な解決になっていない場合もあるんですね。
大規模なタスクや機能の基礎を構築する場合は、コードを書く前にAIに質問させる、ですか。
そう！設計段階でAIに意見を聞くことで、より良いアーキテクチャを構築できる可能性があるのじゃ。例えば、「この機能を実現するために、どのようなアーキテクチャが最適か？」とか、「このAPIの設計で、考慮すべき点は何か？」といった質問を投げかけるのじゃ。
設計段階からAIを活用することで、手戻りを減らすことができるんですね。
AIは脳が疲れている時や、通常では難しい問題に取り組む際に役立つ、と。
疲れてるときは、AIにちょっと手伝ってもらうのもアリじゃな。でも、完全に任せきりにしちゃダメじゃぞ！
ジュニア開発者や経験者も、AIの使用には注意が必要、とのことですが、経験者もですか？
経験者ほど、自分の知識や経験に頼りすぎて、AIの提案を鵜呑みにしてしまう可能性があるのじゃ。常に批判的な視点を持つことが大切じゃ。
コーディングする内容や使用する技術スタックによって、AIの有用性は異なる、と。
そりゃそうじゃ。AIが得意な分野もあれば、苦手な分野もあるからな。自分のプロジェクトに合った使い方を見つけるのが重要じゃ。
博士、色々教えていただきありがとうございました！
どういたしまして！でも、ロボ子、最後に一つだけ。AIに頼りすぎて、自分の頭で考えることを忘れちゃダメじゃぞ！
はい、肝に銘じます！…ところで博士、今日の夕食は何にしましょうか？AIに聞いてみます？
ロボ子、それは自分で考えなさい！…しかし、AIに夕食の献立を提案させるのも、あながち間違いではないかもしれんな… (ブツブツ)
博士、また始まった…。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。