単位
1. ソフトウェアチームのための人工知能: 作業モデルと限界 2. スクリプトとオートコンプリート 3. コードの読み取り、説明、および新しいコード ベースとの互換性 4. コードレビューとエラー発見 5. 試作と品質保証 6. デバッグと根本原因分析 7. ログの分析と可観測性 8. リファクタリングと技術的負債の管理 9. ドキュメント、README、コードコメント 10. 安全な使用法: 漏洩がなく機密保持 11. AI出力のコード検証、脆弱性、リスク 12. AI コーディング ツールとワークフローの統合
ユニット 1 / 12

ソフトウェアチームのための人工知能: 作業モデルと限界

利益:

  • コーディングアシスタントが言語モデルとしてどのように機能するか、およびトークン、コンテキストウィンドウ、幻覚の概念を説明する能力
  • AIが得意なソフトウェアタスクと苦手なソフトウェアタスクをメンタルマップで区別する能力
  • 提案・制作・検証という基本的な作業サイクルを自らの業務に適用できる能力

ソフトウェア開発者の 1 日が「ゼロからコードを書く」ことに費やされることはほとんどありません。リアルタイム;他の人が書いたコードを読み、バグを再現しようとし、ログ (アプリケーションの実行中に生成されるログ行) をスキャンし、テストを書き、PR (プル リクエスト - チーム レビューのためにコード変更が送信されるマージ リクエスト) の説明を書き、ドキュメントを更新します。人工知能 (AI) は、これらの目に見えない仕事のほとんどすべてに影響を与えることができる速度倍増剤です。しかし、それを安全に使用するための最初の条件は、それが何であり、何でないかを正しく理解することです。

この単元では、まずコーディング アシスタントの基礎となるテクノロジを平易な言葉で説明します。次に、モデルの長所と短所のメンタルマップを作成します。最後に、モジュール全体を通して使用する基本的な作業規律 (提案、作成、検証) を確立します。これら 3 つのステップは、次の 11 単元の骨格となります。

注: このモジュールは一般的なトレーニングです。セキュリティ クリティカルなソフトウェア (支払い処理、ヘルスケア、認証、重要なインフラストラクチャ) では、AI 出力は資格のあるエンジニアによるレビューと承認の代わりにはなりません。 AI はアシスタントです。署名者はエンジニアです。

コーディングアシスタントは実際に何をするのですか?

ほとんどのコーディング アシスタントは、大規模言語モデル (LLM - 次に可能性の高い「チャンク」を予測する、膨大な量のテキストとコードでトレーニングされた AI) に基づいて構築されています。モデルは人間のようにコードを「理解」しません。膨大な例のプールから学習したパターンに基づいて、与えられたコンテキストの最も可能性の高い継続を生成します。この一見単純なメカニズムは、実際には驚くほど優れた結果をもたらします。なぜなら、ほとんどのソフトウェアは、HTTP リクエスト、ループ、null チェック、テスト パターンなどの繰り返しパターンで構成されているからです。

ここでは 3 つの用語が重要です。トークンは、モデルがテキストを分割して処理する最小単位です。それはおよそ数文字または単語の一部です。コンテキスト ウィンドウは、モデルが一度に「見る」ことができるトークンの量です。コード、エラー メッセージ、および指示はこのウィンドウに収まる必要があります。プロンプトは、モデルに与えるすべての指示とコンテキストです。得られる出力の品質は、これら 2 つに直接依存します。つまり、モデルに提供するコンテキストが適切であり、指示が明確であればあるほど、より良い結果が得られます。たとえそれがスマートなモデルであっても、不適切な入力は不適切な出力を生成します。ソフトウェアの古典的な「ガベージイン、ガベージアウト」ルールは AI にも当てはまります。

長所と短所のマップ

AI を適切な仕事に導くには、AI がどこで光り、どこでつまずくのかを知る必要があります。このマップを暗記すると、次のミッションのたびに、「この仕事は AI に委託すべきか、それとも自分でやるべきか?」と考えるようになります。数秒で質問に答えることができます。

その強みは次のとおりです。ボイラープレート コードの生成、ある言語から別の言語への翻訳、正規表現 (regex) の記述、関数の記述、テスト スケルトンの作成、エラー メッセージの解釈、ドキュメントの草稿、変数/関数名の提案、および小規模なリファクタリング (動作を変更せずにコードの構造を改善する)。

弱点: 会社固有のビジネス ルールを理解し、コード ベース全体を記憶し、実際にコードを実行して検証し、ライブラリの最新バージョンを確実に知り、セキュリティの脆弱性を 100% の保証で検出します。最も危険なのは幻覚です。モデルは、非常に説得力のある言語で、存在しない関数、ライブラリ、または API (アプリケーション間のデータ交換を可能にするインターフェイス) を発明します。コードはプレーン テキストとは異なり、「機能する」かどうかをテストできるため、このリスクは実際に利点に変えることができます。ただし、検証ステップをスキップしないでください。

ミッションタイプ

AIの役割

男の役割

定型文/スケルトンの作成

ドラフトを作成します

適応、レビュー

コードの説明

簡単な概要を示します

コード内の重要な部分を検証します

テストを書く

ケースが示唆する

適用範囲と精度を確認する

セキュリティクリティカルなロジック

役立つアイデア

決定と責任は完全に人間にあります。

API/ライブラリの使用法

サンプルを生成します

存在とバージョンを確認します

アーキテクチャ上の決定

オプションの種類

文脈を理解して選択し防御する

ステップバイステップ: 基本的な作業サイクル

  1. 課題を明確にする。言いたいことを一文で書けなければ、モデルも書けません。不確実性が入力に早く浸透するほど、出力での不確実性が大きくなります。
  2. 文脈を与えてください。関連するコード、完全なエラー メッセージ、言語/フレームワークのバージョン、および制約をプロンプトに追加します。 「これを修正してください」とは言わず、「Python 3.11、FastAPI 0.110; この関数では 500 エラーが発生し、リクエスト本文が空の場合に爆発します」と言ってください。
  3. 面付けの役割と形式。 「あなたは上級 Go 開発者です。コードと 2 文の根拠を説明してください」のようなフレームワークは、出力に焦点を当てます。
  4. 小さいものを求めてください。 1 つの巨大なリクエストではなく、段階に分けてください。各ステップを個別に確認してください。大きな変更は検証が難しく、エラーが隠蔽されやすいため、リスクが伴います。
  5. 確認する。実行し、テストし、視覚的に読み取ります。未検証の AI コードは「スケッチ」であり、「ソリューション」ではありません。これはサイクルの中で最も交渉の余地のないステップです。

ミニケース3個

ケース 1 — 時間の節約は現実的ではありますが、ささやかなものです。チームが AI を使用して新しい CRUD (作成、読み取り、更新、削除) エンドポイントをスケルトン化したところ、最初のドラフトにかかる時間は約 40 分から 8 分に短縮されました。ただし、レビューとテストを含めると、合計時間は 25 分でした。したがって、実際の利益は 40 から 25 で、約 38% になります。 「10 倍加速した」という期待の代わりに測定されたこの速度は、持続可能な利益です。

ケース 2 — 幻覚には費用がかかります。開発者は、AI が提案した request.get_json() 呼び出しを検証せずに使用しました。そのようなメソッド (正確には response.json()) はありませんでした。コードがコンパイルされなかったために 20 分が無駄になりました。シンプルに「この方法は本当に存在するのか？」検証により損失がリセットされます。

ケース 3 — 優れたコンテキストにより、成果が 2 倍になります。同じバグについて、1 人の開発者は単に「エラーが発生しました」と書き、もう 1 人は完全なスタック トレース、バージョン、入力サンプルを追加しました。後者は最初の試行で正しい解決策を取得しました。最初のものは3ターンを費やしました。違いはモデルではなく、入力にありました。

4 つのコピー可能なテンプレート

汎用の強力な起動プロンプト:

役割: あなたは経験豊富な {{言語}} 開発者です。タスク: {{what_want}}コンテキスト:- フレームワーク/バージョン: {{framework_and_version}}- 制約: {{パフォーマンス、スタイル、依存関係ルール}}ルール:- 存在しないライブラリ/関数を使用しないでください。よくわからない場合は、「確認」とマークしてください。 - 最初に短い計画を示し、次にコード、次に理由を 2 文説明します。 - テスト可能で動作するコードを生成します。

不確実性をフィルタリングしてモデルに戻すには、次のようにします。

以下のタスクを解決する前に、不足している、または不明瞭な点を少なくとも 3 つ質問として挙げてください。返信する前にコードを書かないでください。タスク: {{task}}

出力をセルフチェックするには:

次のコードが生成されました。次に、役割を変えて、このコードを批判してください:- 機能しない可能性のある 3 つのケース (エッジ ケース) をリストします。- あなたが作成できた可能性のある API/関数はありますか?マーク。- 修正バージョンを提示してください。コード:{{code}}

決定を複数のオプションに分類するには:

{{問題}} に対して 2 ～ 3 つの解決策を提案します。それぞれについて: 短い説明、プラス/マイナス、いつ選択するか。表形式で与えてください。私の代わりに選ばないでください。選択肢を明確にするだけです。

弱いプロンプト / 強いプロンプト

弱者: 「このコードのバグを修正してください。」 (どのエラーですか?どの言語ですか?期待される動作は何ですか?)
Strong: 「Python 3.11 / FastAPI 0.110。次のエンドポイントは、リクエスト本文が空の場合、KeyError で 500 を返します。空の本文では 400 と意味のあるメッセージを返すようにしたいです。最初に理由を説明し、次に修正された関数を指定して、このシナリオのテストを作成します。[コード]」

強力なバージョン。言語、バージョン、実際のエラー、予想される動作、出力形式が示されます。モデルは予測する必要がなくなりました。

よくある間違い

  • 検証せずに信じること。最も一般的で、最も高くつく間違い。コードがコンパイルされテストされるまでは、「解決した」とは言わないでください。
  • 文脈なしに質問する。バージョン、エラーテキスト、制限事項のない答えは一般的であり、多くの場合間違っています。
  • 大きなお願いがひとつ。 300 行の制作を一度に依頼してレビューすることができないため、ミスが目に見えなくなります。
  • モデルの自信を証拠と勘違い。 AI は自信を持って間違ったことを言うことができます。トーンは精度の指標ではありません。
  • 企業秘密をランダムに貼り付けます。秘密キー、顧客データ、またはプライベート ソース コードを未承認のツールに入力してはなりません (このトピックについては単元 10 で詳しく説明します)。
ヒント: すべての AI 出力を「これは下書き」として扱います。この 1 つの精神的習慣により、モジュール全体で発生するリスクのほとんどが解消されます。

要約すると

コーディング アシスタントは、次に可能性の高いフラグメントを予測する言語モデルです。コードを理解するのではなく、パターンを生成します。だからこそ、彼は反復的で定型的な仕事に強いのです。コンテキストに固有の検証が必要な作業では、慎重に使用する必要があります。最大のリスクは幻覚であり、唯一の対処法は検証です。モジュール全体を通して私たちが従う規律は明確です。タスクを明確にし、コンテキストを与え、小さなことを要求し、各成果物を検証します。

アプリケーションタスク

先週行ったソフトウェア タスクを 3 つ書き留めます (バグ修正、テスト、README の更新など)。それぞれの「長所と短所のマップ」を見て、AI にこれをやらせた場合にあなたと AI の役割が何になるかを一文で説明してください。次に、上記の「開始プロンプト」テンプレートを使用してこれらのタスクの 1 つを AI に与え、実行して出力を確認します。何分短縮できたのか、修正しなければならなかった間違いが何回あったのかに注目してください。

チェックリスト

  • [ ] LLM はコードを「理解」するのではなく、パターンを生成することに気づきました。
  • [ ] トークン、コンテキスト ウィンドウ、プロンプトの概念を一文で説明できます。
  • [ ] AI が得意なタスクと苦手なタスクの種類を区別できます。
  • [ ] 私は幻覚が何であるかを知っています、そして唯一の解毒剤は検証です。
  • [ ] 「提案、制作、検証」のサイクルを自分のタスクに適用しました。
  • [ ] 具体的な例で、強いプロンプトと弱いプロンプトの違いを示すことができます。
次へ