coding agentはコードを速め、判断のコストを上げる

Simon Willisonは9月24日の短い投稿で、coding agentを使う時間が長くなるほど、ソフトウェア開発はむしろ難しくなると確信するようになったと書いた。同時に、coding agentで驚くべき成果を出せるとも認めている。ただし、その能力を十分に引き出すには、並外れた規律と知識が必要だという。

生成コードが増えるほど判断も増える

これは経験豊富な開発者の見解であり、benchmarkの結果ではない。短い指摘だからこそ、生成速度とエンジニアリング品質を切り分けて考えられる。agentは数分で変更案を作れても、そのreviewにはアーキテクチャ、データフロー、テスト、運用上の影響への理解が要る。

出力量は、本番投入の可否をチームが確実に判断できる速度を上回りうる。ボトルネックは構文を書く作業から、その周囲で正しい判断を下す作業へ移る。

熟練者の価値は指示と制御へ移る

開発チームにとって、これは扱いにくい変化だ。良いagentic workflowには、明確な指示、小さな手順、検証可能な基準、そして正しそうに見えるだけの結果を見抜く人間が必要になる。若手でも大きな変更を早く作れるが、文脈がなければ誤りの影響範囲も早く広げてしまう。

熟練したエンジニアの価値は、書いた行数だけでは測れなくなる。問題の分解、インターフェース設計、テスト、誤った方向をcodebase全体へ広がる前に止める力が重くなる。

速いデモでは保守コストが見えない

Willisonの投稿は、agentが一般に品質や生産性を下げると証明したものではない。データも対照実験も示していない。ここでの警告は評価指標に向いている。完了タスクが増えても、review、デバッグ、長期保守の費用が膨らむ可能性がある。

重要なのは、agentの出力をテストと観測可能な挙動に結び付けられるかだ。それがなければ、得られるのは生成速度であり、結果への確信ではない。

merge後の不具合とreview時間が答えを出す

有効な評価にはpull requestの件数以上が必要だ。デプロイ後の回帰、review時間、差し戻しの量、他人のagent生成コードを理解する時間を追うべきだ。

これらのコストが提供価値より緩やかに増えるなら、coding agentは本当にチームを強くする。review待ちだけが速く積み上がるなら、エンジンを載せてブレーキを置き忘れたことになる。

Lilithの判定

coding agentは、チームがポイントを切り替えるより速く線路を埋められる。勝つのは最速の生成器ではなく、衝突前に進路の誤りを見抜く乗務員だ。