最初のAIタスクを選ぶ

検証できるタスクを選ぶ

最初の有用なタスクでは、自分たちの環境でツールがどう動くかを学びます。同時に、確認できる結果を得る必要があります。既知の不具合に対する小さな修正なら、両方の条件を満たすことが多くあります。

見栄えのよいデモになるという理由だけで選ばないでください。大規模な再設計は、目に見える変更を多数生む一方で、誤った仮定を隠すことがあります。小さなタスクでも、エージェントが指示を読み、範囲を守り、確認の失敗を正確に報告するか分かります。

最も簡単なタスクを選ぶ必要はありません。チームが正しい結果を見分け、その理由を説明できるタスクを選びます。

レポート用アプリでの、架空の依頼を三つ考えます。

説明のタスクでは、推論と証拠を確認できます。回帰テストでは、制御された操作が加わります。アーキテクチャのタスクは後に役立つかもしれませんが、作業指示書とレビューの仕組みをさらに整える必要があります。

最初の演習には回帰テストを選びます。架空の日付とローカルブランチを使います。本番アクセス、依存関係のアップグレード、無関係なリファクタリングは対象外と明示してください。

「日付の処理を改善する」では、解釈の余地が大きすぎます。「入力に暦上存在しない日付が含まれていたら、バリデーションエラーを返す。有効な日付では、文書化された出力を維持する」と具体的に示します。

有効な入力と無効な入力の例を追加します。既存のテストコマンドを示してください。ファイルを変更する前に、現在の動作を調べるよう依頼します。不具合の簡潔な説明と、変更後の証拠を求めます。

成果と活動を分けます。「エージェントがテストを書いた」は活動を表します。「テストが既知の不具合を検出して失敗する」は証拠を表します。正しいコードでも誤ったコードでも成功するテストでは、意図した保護を確認できません。

演習中は、追加のコンテキストが必要になった箇所を記録します。関連するリポジトリの指示を読んでいるか確認してください。対象外のファイルを変更しないか、新しい証拠なしに失敗した方法を繰り返さないかも観察します。

細かい選択をすべて即座に修正する必要はありません。許可された、元に戻せる作業を完了させて、結果を評価します。次の操作が境界を越える場合や、未解決の要件を確定しないと作業を続けられない場合は介入してください。

完了時には差分をレビューし、関連する確認を実行します。エージェントの作業時間だけでなく、自分の準備とレビューの時間も記録します。観察した内容は、次のタスクの選択と作業指示の改善に役立ちます。

演習が成功したら、複雑さの要素を一つ増やします。一つの関数から、関連する二つのモジュールへ広げる方法もあります。文書化された連携を追加する方法もあります。権限と検証要件は明示したままにします。

失敗した場合は、範囲を広げる前に原因を特定します。コンテキスト不足、不明確な要件、使えないテスト環境、モデルの限界では、それぞれ異なる修正が必要です。自律性を高めるだけでは、この四つすべては解決しません。

試作品を使い続けるなら、保守の責任者を決めます。コードを変更しなくても、新しい脆弱性情報への対応が必要になることがあります。継続的な脆弱性管理を参照してください。