1 
2初めてコーディング エージェントが実際にバグを修正するとき、その反応はほとんど常に同じで、熱意と疑惑が入り混じったものになります。いいですね、確かに。しかし、その後、差分を見て自分に問いかけます。「分かったが、彼はいったい何を触ったのだろうか? 彼を信頼してもいいだろうか? 明日も同じように触るのだろうか?」
3 
4そこからが面白い部分の始まりだと思います。エージェントが関数を作成するときではなく、リポジトリの読み取り、パッチの作成、テストの実行、PR のオープン、レビュー コメントの後に戻ってくるなどの作業全体を引き受けるのに十分な能力を身につけたときです。 Codex は、バックグラウンド作業、個別のワークツリー、統合ブラウザ、自動化、プラグイン、メモリ、より明示的な権限制御など、まさにその方向に向かって進んでいます。
5 
6重要なのは、誰もコードを読まなくなる未来を想像しないことです。それは恐ろしい未来になるだろうし、かなりナイーブなものになるだろう。重要なのは、エージェントにすべてを任せるのではなく、多くのことができるエージェントとどのように連携するかを考えることです。
7 
8## 習慣の変化
9 
10従来のオートコンプリートでは、常にハンドルを握っていました。 AIがセリフを提案して、あなたが決めました。しかし、エージェントとの関係は変わります。あなたが彼に目標を与えると、彼は自分で複数のステップを経ていきます。
11 
12これは強力ですが、問題を転換します。問題はもはや「モデルはプログラムできるか?」というだけではありません。質問は次のようになります。
13 
14- 私は彼に十分な範囲を与えただろうか？
15- 結果を確認する方法を知っていますか？
16- 隔離された環境で作業しているのでしょうか?
17- 最終審査はやはり人道的で慎重なものなのでしょうか？
18 
19健全なワークフローは、魔法の杖よりも次のようになります。
20 
21```mermaid
22flowchart LR
23    Idea[ヒューマンタスク] --> Scope[小規模で検証可能な目的]
24    Scope --> Agent[分離されたワークツリー内のエージェント]
25    Agent --> Checks[テスト、lint、ビルド、ブラウザ]
26    Checks --> Review[人間によるレビュー]
27    Review --> Merge[マージまたは新しいイテレーション]
28    Review --> Iterate[差分に関する正確なコメント]
29    Iterate --> Agent
30```
31 
32「エージェントがすべてを構築する」よりもロマンチックではありませんが、はるかにうまく機能します。また、人間との付き合いが上手なチームの仕事のやり方でもあります。つまり、明確なタスク、素早いフィードバック、明確な説明責任です。
33 
34## 良いプロンプトはほぼ良いチケットです
35 
36最も危険なプロンプトは、「請求書ページを修正してください」、「アーキテクチャを改善してください」、「認証モジュールをクリーンアップしてください」という、あいまいだが確信に満ちたプロンプトです。これらは生産的であるように聞こえ、巨大な差分を生成するリクエストです。しかしその後、あなたは考古学をやっていることに気づきます。
37 
38役に立つプロンプトはもっと退屈です。たとえば、テーブルが `app/(dashboard)/invoices/page.tsx` にあり、クエリが `src/server/invoices.ts` にあり、同様のパターンが `app/(dashboard)/reports` にすでに存在することを認識して、請求書ページの CSV エクスポートを実装します。
39 
40次に、明確な制約を追加します。データベース スキーマを変更しないこと、小さなユーティリティで十分な場合は依存関係を追加しないこと、既存の UI スタイルを維持することです。そして、`npm test -- invoices` と `npm run build` の検証で終了します。
41 
42この種のブリーフは、「AI に対してより適切に説明する」ためのものではありません。これは何よりも、何を委任しているのかを明確にするために役立ちます。具体的に書き留めることができない場合は、そのタスクがエージェントにとってまだ準備ができていない可能性があります。
43 
44## 私が喜んで任せる3つの仕事
45 
461 つ目は繰り返しですが検証可能な作業です。テストの追加、新しい内部 API への呼び出しの移行、インポートの更新、非推奨のコンポーネントの置き換え、TypeScript エラーの修正です。ここでは、エージェントは時間を節約でき、リスクは制御可能です。
47 
482 つ目は探索的な作業です。「この合計が計算される場所を見つけてください」、「このテストが脆弱である理由を説明してください」、「バグを再現して、どのファイルが影響を受けていると思われるかを教えてください」。パッチがすぐに生成されない場合でも、有用な偵察を行うことができます。
49 
503 つ目は定期的なメンテナンス作業です。小規模な依存関係の更新、古い機能フラグのクリーンアップ、ブロックされた PR の概要、忘れられた TODO のチェックです。華やかさはありませんが、まさに積み重なりがちな仕事です。
51 
52## 私が人間らしく続ける3つの仕事
53 
54製品の決定は依然として人間によるものです。変更によってユーザーの支払い方法、データの削除方法、価格の確認方法、または権限の理解方法が変わる場合は、責任者が必要です。
55 
56認証、ロール、トークン、機密データのログ記録、データベースの移行など、セキュリティ境界にも人間の注意が必要です。エージェントは実装を支援できますが、唯一の意思決定者である必要はありません。
57 
58最後に、私は建築的なセンスを必要とするものはすべて人間的なものにしておきます。エージェントはリファクタリングを提案できますが、抽象化が本当に必要なのか、それとも存在しない問題を磨き上げているだけなのかを理解するのは依然として仕事です。
59 
60## レビューは任意ではありません
61 
62エージェントが優れている場合、CI の緑を信頼する誘惑に陥ります。それは理解できます。問題が始まるのもこの時期です。
63 
64私は常に少なくとも 5 つのことに注目しています。
65 
661. パッチは要求されたタスクのみを解決しますか?
672. 彼は関係のないファイルに触れたのでしょうか?
683. テストの対象となるのは、斬新な行動ですか、それとも単なる幸運な偶然ですか?
694. コードはローカルのパターンに従っていますか?
705. エラーはプロジェクトの残りの部分と同様に処理されますか?
71 
72何かが間違っている場合、フィードバックは具体的である必要があります。 「直す」というのは怠惰です。より良い方法: このユーティリティは `parseMoney` を `src/lib/money.ts` に複製します。その関数を再利用し、EUR の場合のテストを追加し、課金モジュールのパブリック API は変更しないでください。
73 
74エージェントは、検証可能な小さなコメントに対してよりよく反応します。不思議なことに、人々も同様です。
75 
76## 努力する価値のあるガードレール
77 
78エージェントがファイルを読み取り、コードを記述し、コマンドを実行できる場合は、強力なプロセスとして扱う必要があります。被害妄想は必要ありませんが、衛生管理は必要です。
79 
80別のワークツリーまたはブランチを使用します。そのため、差分を比較し、失敗した実験を破棄し、エージェントの作業と自分が行っていた作業を混同することがなくなります。
81 
82権限を制限します。 `rg`、`git diff`、`npm test`、`npm run build` などのコマンドは非常に無料です。デプロイメント、データベースの移行、シークレットへのアクセス、および破壊的なコマンドは明示的に行う必要があります。
83 
84必要のないときはネットワーク アクセスを減らします。多くのタスクでは、公式ドキュメント、パッケージ レジストリ、および特定の内部サービスで十分です。表面積が小さくなると、驚きも少​​なくなります。
85 
86アクションを追跡します。パッチがレビューに到着すると、プロンプト、実行されたコマンド、合格したテスト、および変更されたファイルを再構築できるはずです。官僚主義を生み出すためではなく、何か問題が起こった場合に何が起こったのかを理解できるようにするためです。
87 
88## チームとして始める簡単な方法
89 
90もし私が小さなチームにエージェントを導入するとしたら、大きな変革を起こさずに始めるでしょう。
91 
92範囲が明確な問題には `agent-ready` ラベルを作成します。コンテキスト、制約、検証コマンドを含むテンプレートを追加します。理想的には数百行以内の小規模な PR をお願いします。目に見える変更については、テストまたはスクリーンショットが必要になります。そして何よりも、私はマージの責任者を残しておきたいと考えています。
93 
942 週間後、どのタスクが実際にスピードアップしたか、どのレビューが多かったのか、どのプロンプトがわかりにくかったのか、コードベースのどの部分が脆弱すぎて委任できなかったのかなどのデータを確認しました。
95 
96「今日からエージェントと一緒にすべてをやってみます」ほど派手なアプローチではありませんが、後悔することなく 3 週目を迎えることができる方法です。
97 
98## 最も人間的な部分
99 
100面白いのは、エージェントが自律的になるにつれて、適切なチケットを作成する、小さなカットを行う、テストを作成する、差分を読み取る、トレードオフを伝えるといった古典的なスキルが再び重要になることです。エージェントは、すでにうまく働く方法を知っている人々を加速させます。また、不適切に委任した人々の混乱も増幅します。
101 
102いいえ、私はマルチエージェントのワークフローがエンジニアリングをやめる近道だとは考えていません。私はこれらを、何を構築するかを決定し、それが動作することを確認し、システムを理解しやすくしておくなど、重要な部分により多くのエネルギーを移す方法だと考えています。
103 
104エージェントは優れた非同期同僚になる可能性があります。しかし、非同期の同僚が役に立つためには、コンテキスト、境界線、レビューが必要です。他のみんなと同じように。
105 
106## 役立つ情報源
107 
108- [(ほぼ) すべてのコーデックス - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [OpenAI で Codex を安全に実行する](https://openai.com/index/running-codex-safely/)
110- [Codex の紹介 - OpenAI](https://openai.com/index/introducing-codex/)
111- [GitHub Copilot コーディング エージェントの新機能](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112