利益:
- 明確な入出力および制約定義を使用して AI に関数、クラス、モジュールを作成する機能
- AI をペア プログラミング パートナーとして使用し、検証可能な小さな単位で段階的に進める能力
- AI によって生成されたコードをコンパイルし、小さなサンプルで実行することで、ロジックやエッジ ケースのエラーを検出する機能
ペア プログラミングとは、2 人の開発者が同じ問題に取り組み、1 人が執筆し、もう 1 人が改訂することです。 AI を使用したコーディングは、まさにこの関係のデジタル バージョンです。方向、制約、受け入れ基準を設定するのはあなたです。 AI がクイックドラフトを作成します。各ステップをコンパイルしてテストすることで検証します。ここでの最大の罠は、AI に「このアプリケーションを最初から最後まで書いてください」と指示し、200 行のブロックを盲目的に受け入れることです。優れたペア プログラミングは小さなステップで進められます。各ステップは理解しやすく、テスト可能で、元に戻すことができる必要があります。
この単元では、明確な入出力契約を使用して関数、クラス、モジュールを出力する方法を学びます。 AI を段階的にガイドする方法。また、生成されるコードを実行することでロジック エラーやエッジ ケース エラーを捕捉する方法を、小さな例とともに見ていきます。目標は速度ではなく、速度の検証です。
概念: 入出力規約: 関数が受け取る入力と、関数が約束する出力およびエラー動作の明確な定義。エッジケース: 通常ではないが実際に発生する可能性のある入力 (空、ゼロ、負、非常に大きい、null)。インクリメンタル開発: 小さな作業部分を進め、各ステップを検証します。
ネットコントラクトを使用したコードの印刷
高品質コードの基本は、作業を開始する前に「何を望むか」を正確に定義することです。 AI に関数を記述するときは、言語とバージョン、入力の種類と意味、出力、エラー条件、制約 (パフォーマンス、外部ライブラリの禁止、スタイル) の 5 つの要素を AI に指定します。これにより、AI による推測が防止されます。
- 契約書を書きます。入力、出力、エラー、制約。
- 小さな単位でお願いします。単一の責任を持つ機能。それは巨大なモジュールではありません。
- テストブロックをリクエストします。コードの横にいくつかのサンプル実行/テストを追加します。
- コンパイルして実行します。エッジケースで試して、出力を目で確認してください。
- 次のステップに進みます。部分が確認できたら、それを基に構築していきます。
短縮された関数プロンプト: 「TypeScript 5 の関数を作成します。目的: ショッピング カート内の商品の合計金額を計算します。入力: { 価格: 数値、数量: 数値 }[] 配列。出力: 数値 (合計)。ルール: 数量または価格が負の場合はエラーをスローします。空の配列の場合は 0 を返します。小数点エラーの場合は金額を小数点以下 2 桁に丸めます。外部ライブラリは使用しないでください。関数の下に 5 つのテスト ケースを追加します (通常、空、負の数量、小数点の価格、単一)アイテム）。」
AIをペアとして導く
ペアプログラミングの進歩は、1 つの大きな要求ではなく、対話によって進められます。まず、スケルトンをリクエストして実行します。次にエッジ状態を追加します。それからバグを修正してください。このアプローチにより、コードが理解しやすくなり、すべてのステップで制御できるようになります。
増分進行プロンプト: 「CSV ファイルを読み取り、行をオブジェクトに変換するリーダーを作成します。各ステップを確認せずに、ステップバイステップで次のステップに進みましょう。ステップ 1: ファイルを行に分割し、ヘッダー行を分離するスケルトンを記述するだけです。型変換やエラー処理はまだ追加しないでください。短くして説明してください。」
コードプロンプトを説明して正当化します。「今書いた関数を、1 行ずつではなく、決定ごとに説明してください。どのような設計上の決定を下し、その理由、どのエッジケースをどのように処理したのか、どのケースを意図的に除外したのか。コード内の見逃してはならない 3 つの前提条件を挙げてください。」
ヒント: AI が生成したコードを理解せずに受け入れないでください。 「これを説明してください、どのような仮定を立てましたか？」この質問により、隠されたエラーが明らかになり、コードはユーザーの責任であるため、そのコードを擁護することができます。理解できないコードを本番環境に導入することは、署名せずに契約書を送信するようなものです。
弱いプロンプト / 強いプロンプト
WEAK:「ソート関数を作成します。」(結果: どの言語、何をソートしているか、安定しているか、パフォーマンスの制約は何か、あいまいでおそらく要件に適合しないコード。)STRONG:「Java 17 の場合、List<Employee> オブジェクトを最初に部門 (アルファベット順) でソートし、次に給与 (降順) でソートするメソッドを作成します。元のリストを置き換えず、新しいリストを返します。NULL 部門を最後にします。コメント行でメソッドに 4 つのサンプルを含むメイン テスト ブロックを追加することを指定します。
強力なプロンプト。並べ替え基準 (2 レベル)、副作用ルール (元の置換)、NULL 動作、およびテストの期待値が含まれます。これらの詳細がなければ、AI はもっともらしいが不正確な解決策を生成します。たとえば、元のリストが破損し、他の場所でサイレント エラーが発生する可能性があります。
エッジケースと小規模サンプルによる検証
幸せなシナリオで機能するコードは、正しいコードではありません。生成された各機能を意識的に強制します。
エッジケースタイプ
サンプル入力
予想される動作
空白の入力
空の配列/文字列
エラーではなく、論理的に空の結果です
ゼロ/マイナス
0、-1
定義された正しい行動
大きな価値
数百万のレコード
オーバーフロー/パフォーマンス制御
null/未定義
スペースがありません
制御されたエラーまたはデフォルト
重複/異常
繰り返し、逆の順序
正しい結果
ミニケース
ケース 1 — サイレント丸めエラー。 AI は、10 進数 (float) 型でお金を集める関数を作成します。 0.1 + 0.2 は 0.30000000000000004 になります。このエラーは、エンジニアが「2 桁に四捨五入し、ペニーの整数を使用する」というルールを追加すると解決します。 3 行ルールにより、月次調整における数千ペニーの差異が防止されます。
ケース 2 — 副作用の罠。 AI はリストを「ソート」するメソッドを作成しますが、元のリストはその場で変更されます。別のモジュールが同じリストを使用しているため、予期しない動作が発生します。 「オリジナルを変更」制約がプロンプトに含まれていた場合、エラーは発生しません。コードレビューに引っかかり、2時間のデバッグができなくなります。
ケース 3 — 段階的に収益を上げます。開発者は 150 行のインポート モジュールを一度に印刷します。彼は間違いを見つけても、それがどこから来たのかを見つけることができません。別の開発者は、同じ作業を 5 つの小さなステップに分割し、各ステップを 2 分でテストし、3 番目のステップでエラーをすぐに発見しました。
よくある間違い
- 1 回のリクエストで大きなブロックを印刷します。理解やデバッグが難しい危険なコードが生まれてしまいます。
- 契約せずにコードを要求する。入出力エラーがあいまいだとAIが推測して間違ってしまいます。
- 幸せなシナリオをテストしているだけです。空、null、負、および大きな入力が試行されない場合、エラーは運用環境に残されます。
- 理解せずに受け入れること。開示しないコードは弁護できない負債です。
- 副作用やお金/日付などのデリケートなタイプは無視します。時代を超越した歴史を持つ変動資金は、典型的な間違いの原因です。
要約すると
AI を使用してコードを記述することは、規律あるペア プログラミングです。明確な契約、小さなステップ、各ステップでのビルドとテストです。入出力エラー制約のカルテットを最初から与えることで、コードの品質が決まります。生成されるコードを説明し、エッジケースを適用すると、幸せなシナリオの下に隠れていたエラーが表面化します。スピードの源は盲目的に受け入れることではありません。迅速なドラフトと迅速な検証です。
アプリケーションタスク
小規模だが実際の関数 (バスケットの合計、日付の差、テキスト解析など) を選択します。短縮された関数プロンプトを使用して印刷します。その隣に少なくとも 5 つのテスト シナリオを追加します。コードを実行し、表をガイドとして使用して 5 つのエッジ ケースを意識的に試してください。少なくとも 1 つのエッジ ケースでバグを見つけ (そうでない場合は、関数を強制する新しい入力を設計します)、AI で修正し、修正が機能したことを再テストして検証します。
チェックリスト
- [ ] 入力、出力、エラー、制約を含むコントラクトを作成しました。
- [ ] 1 つの大きなブロックではなく、小さなステップでコードを生成しました。
- [ ] コードの隣にテスト/サンプル実行ブロックを追加しました。
- [ ] 私は少なくとも 5 つのエッジケースを意識的にテストしました。
- [ ] AI にコードを説明し、その前提を確認しました。
- [ ] 見つかったエラーを修正し、再テストして修正を確認しました。