それに賛成！時には問題に対してトークン燃料を投げる価値があるし、進めながら検証していくのもアリだよね。

何も謝ることはないと思うよ。彼は数週間前にそれについて書いてたしね。 https://simonwillison.net/2026/Feb/7/software-factory/

本当に良いテストが必要だよ。変な方法でバグるからね（経験豊富なプログラマーはコーディング中に脳内でループを回してると思う）。いいニュースは、エージェントは新しいテストを追加したりバグを見つけたりするのが得意だってこと。そういうのをやろう。ユニットテストやプレイライトもやってみて。ウェブドライビングで全てをテストするのはエージェント以前は狂気の沙汰だったけど、今は十分可能だよ。

テストハーネスのポイントは、私にとっても本当に印象に残っている。ブラウザの自動化作業にエージェントループを使っていて、そのドメインには自然なバリデーションシグナルがある。つまり、ブラウザセッションが実際のユーザーのように振る舞うか、そうでないか。そういう二元的なフィードバックがループをきれいに閉じる。私たちの場合、"正しく振る舞う"には2つのレイヤーがあって、機能的（正しくナビゲートできたか？）と行動的（検出システムにとって人間に見えるか？）。エージェントは最初のレイヤーには問題ないけど、2つ目には直感がない。行動的バリデーションをループに組み込むことが、実際に役立つものにした。セッション間の.mdのスクラッチパッドは過小評価されている。私たちはそれを短い決定ログに形式化した。何が起こったかの要約ではなく、明白でない選択とその理由だけ。次のセッションにおいて「私たちはXを試した」と「私たちはXを試したが、Yのせいで失敗したのでZを使う」というのは大きな違いだ。

「テストハーネスが全てだよ。作業を検証する方法がなければ、ループは迷走する」これがAIコーディングエージェントを使う上で最も重要なポイントだね。彼らは本当に魔法のような機械で、多くの開発や一般的なコンピューティング、データ収集のタスクを簡単にこなせるけど、決定論的で実行可能なチェックやテストがなければ、ループの一回目から次の回にかけて何も保証できないよ。

最後に試したのはいつ？エージェントに大きなタスクをやらせるのは、去年の終わりまでずっと当たり外れがあったと思う。ここ数ヶ月で彼らがかなり良くなったのを感じてる（私だけじゃないけど）。コーディングアシスタントが得意なことの私の経験は、スマートオートコンプリートから、ターゲットを絞った変更/追加、そしてフルエンジニアリングへと変わったよ。

私もあなたと同じような状況だったけど、DHHがエージェントの使い方を変えたって投稿を見てから変わった。彼がLex Fridmanとのトークで話していたアプローチは私のと似ていて、ハイプの中で一つの常識の核のように感じた。だから、彼がアプローチを変えたと言ったとき、もう一度見直してみた。今は毎日エージェント（Claude code）を使ってるし、毎日コードも書いてるよ。（この立場を強化するために、OpenCodeのDax Raadも同じことを言ってる）。モデルがプロダクションのコードベースを持つことができるとは思えないし、エンジニアは責任を持つために十分なスキルを維持する必要があると思ってる。エージェントは多くのことに役立つけど、通常は先行事例がたくさんあるパターン化されたコードに限る。CCはポーラーズコードを書くのが一貫して苦手だと思う。正直、エージェントを使うのは全然楽しくないし、誰もがこれがどうなるかを本当に知っているとは思えない。でも、自分でツールを使うことで、ハイプの中で現実感が強くなった気がする。

私の経験では、単一のエージェントからの最初のイテレーションの出力は、私が責任を持ちたくないものだよ。「もうコードを書かない」というのとつながるのは、出力を改善するためのイテレーティブなプロセスだね：1) エージェント間でレビューのループを持つ（別の「レビュアー」エージェントを生成する）ことと、明確なテスト/評価基準が、結果をかなり改善してくれた。2) 手動でレビューして改善の指示を出すことが、私が責任を持てるコードを得るためには必要だよ。

これをうまく調整するのはちょっと難しい時もあるよね。私の経験では、これはタスクによって大きく変わるし、良いフィットと悪いフィットの間には大きな溝がある。人によっては、その溝の片側だけで作業して、もう片側に戸惑うこともあると思う。