Agentic Coding is a Trap¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
エージェントに実装を丸投げし、人間はオーケストレーターとして計画とレビューだけを担う、というAgentic Codingの流行に警鐘を鳴らす記事。 問題はAIが役に立たないことではなく、コードに触れる摩擦を失うことで、AIを監督するために必要な判断力やデバッグ力そのものが萎縮すること。 著者はAIを主役にするのではなく、計画、調査、補助的な生成へ降格させ、自分が実装と理解に関わり続ける使い方を提案している。
本文¶
Agentic Codingへの違和感¶
業界では、AIがコードを書き、人間は要件定義、計画、レビュー、ステアリングをするオーケストレーターになる、という言説が広がっている。 著者は、この流れがコードとの距離を広げ、生成された大量のコードを十分に理解・レビューできない状態を作ると指摘する。
トレードオフとして挙げられているもの:
- AIの非決定性を抑えるため、周辺システムの複雑性が増える
- 開発者のスキルが萎縮する
- ベンダーロックインが進む
- tokenコストが読みにくく、組織運用コストが不安定になる
高い抽象化とは違う¶
Agentic Codingは「抽象度が上がっただけ」と語られがちだが、著者は疑っている。 高い曖昧さは高い抽象化ではない。
FORTRAN、コンパイラ、クラウドなどの移行でも、開発者は新しい抽象化に警戒した。 しかし今回の違いは、すでに認知的な影響やスキル萎縮が観測されている点。
Juniorは、コードを書く摩擦を経験する前に、生成コードのレビュー役へ移される。 レビューは重要だが、コードを書き、壊し、デバッグする経験の半分にはならない。
監督者のパラドックス¶
AIをうまく使うには監督が必要。 しかし監督には、AIの過剰利用で萎縮しうるコーディングスキルや批判的思考が必要。
著者は、これは矛盾だと述べる。 AIエージェントを管理するために必要な能力を、AIエージェントの常用によって弱めてしまう。
LLMは間違った部分を加速する¶
著者は、良い開発者の優先順位を次のように見る。
- コードとコードベースの関係を理解する
- 標準や設計方針に沿っているか確認する
- 目的を満たす最小限のコードにする
- 速く仕上げる
Agentic Codingはこの順序を反転しがち。 コード量と速度を増やすが、理解、簡潔さ、設計上の整合性を軽視しやすい。
Coding === Planning¶
コードを書くことは、単なる作業ではなく計画そのもの。 型を書き、関数の関係を試し、フォルダ構造を動かしてみることで、そもそも何を作るべきかが見える。
巨大な仕様を書いてからAIに投げるだけでは、曖昧さをLLMが推測で埋める。 その結果、レビュー、修正、再生成、token消費が増え、作っているものとの距離がさらに開く。
著者の使い方¶
著者はAIを使わないとは言っていない。 むしろ、AIは強力な学習・調査・補助ツールとして使えると述べる。
ただし使い方は「AIを主役にする」のではなく「AIを補助役に降格する」。
- LLMに仕様や計画を補助させるが、実装には自分が関わる
- モデルに頼むときも擬似コードを書き、要求と生成コードの距離を縮める
- 調査、ドキュメント生成、局所的な補助に使う
- 1回でレビューできない量を生成させない
- 自分ができないことを丸投げしない
要約すると、AIをStar TrekのDataではなく、Ship's Computerとして使う、という比喩。
要点¶
- Agentic Codingの危険は、AIがコードを書くことより、人間がコードに触れる摩擦を失うことにある。
- 監督に必要なスキルを、過剰なAI利用が弱めるというパラドックスがある。
- コードを書くことは、設計や計画の一部であり、単なる作業ではない。
- AIは補助役として使い、レビューできる量、自分が理解できる範囲に制限する。