まず読み込み
ローカルコーディングAI：補完とエージェントでは選び方が違う
コーディングといっても、入力中の行を補うこと、エラーを説明すること、複数ファイルを修正することでは違います。一つの速度表で三つの満足度は予測できません。任せたい仕事を分けるところから始めます。
一行の補完に最大のモデルが必要か
補完は自分が先に入力してしまう前に届く必要があります。説明が得意な大型モデルより、有用な短い候補を素早く出す構成が快適な場合もあります。普段のファイルで採用できた提案と邪魔になった提案を記録します。エディタとモデルの補完対応も確認しましょう。チャットでコードを書けることは、カーソル位置を自然に補える保証ではありません。この小さな作業が動くことを確かめてから装置を選びます。
関数修正を検証できる形にする
バグ修正には再現入力、現在の出力、期待する出力を用意します。無関係なファイルを全部渡すより、必要な関数と呼び出し元から始めます。説明の自信ではなく差分とテストを見てください。速いモデルが三回失敗するより、遅いモデルが一回で成功する方が早いこともあります。ただし一問の成功を一般的な知能順位にはしません。自分のプロジェクトで繰り返す問題を残し、同条件で再利用しましょう。
最初からリポジトリ全体を渡さない
エージェントがファイルを読むと、コードに加えて過去の回答やツール出力も蓄積します。後半の依頼が最初より重くなることがあります。ファイルの選び方と渡す範囲が重要です。大きなコンテキストを許可しても、適切なファイルを選べる保証はありません。一機能の修正から始め、何を読んだかを確認します。文脈選択の問題をメモリ購入で解決しようとしても原因は残ります。容量と検索品質は代替できません。
実行権限は速度とは別に考える
ローカル推論だからと、端末やファイルへの無制限アクセスを許可する必要はありません。コピーや別ブランチで始め、変更を確認して適用します。初期テストに秘密鍵や顧客データを混ぜないでください。検索ツールやAPIが外部へ送信する可能性もあります。コード実行やパッケージ導入は文章を読むより影響が大きいため、承認が必要な操作を決めます。誤りを見つけて戻せる環境が重要です。
一つの作業が終わるまで比べる
生成速度に加え、最初の応答、修正回数、テスト完了までを記録します。補完とファイル編集に同じモデルを使う必要はありません。役割を分けるとメモリや同時に保持するモデル数も変わります。当サイトで同一モデルの装置間予測を比べ、実際のエディタでは普段の作業を検証します。文字が流れる時間は作業の一部です。読み直しや手直しも含めて負担が少ない構成を選びましょう。