概要
https://bufferings.hatenablog.com/entry/2025/10/02/235024
詳細内容
## どのくらい生成AIに任せているかをあらわす指標
https://bufferings.hatenablog.com/entry/2025/10/02/235024
生成AIにコーディングを任せる度合いは「生成されたコードを自分が読んでいない割合」で測れるという指標を提示し、生産性と保守性のトレードオフに基づいたAI活用戦略の重要性を強調する。
**Content Type**: Opinion & Commentary
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:5/5
**Main Journal**: 84/100 | **Annex Potential**: 85/100 | **Overall**: 84/100
**Topics**: [[生成AIコーディング, 開発者ワークフロー, コードレビュー, 保守性, 生産性]]
生成AIによるコーディングにおける委任の度合いを測る独自の指標として、「生成されたコードを自分が読んでいない割合」が提唱されています。この指標は、生成AIの活用によって高まる生産性と、コードの理解度や保守性との間に存在するトレードオフを明確化します。
著者は、生成されたコードを読む割合が低いほど生産性は向上しやすいものの、長期的な運用や改修が困難になるリスクを指摘します。これはウェブアプリケーション開発において特に重要であり、プロダクションコードは人間が完全に読み込み、理解する「左側」（低委任）に位置づけるべきだと強調されています。一方で、開発中の使い捨てツールやプロトタイプは、コードを全く読まない「右側」（高委任）で利用することで、非エンジニアでも迅速に作成可能となる利点があります。
自動テストやボイラープレートコード、ドキュメントなどは中間的な位置付けとなり、各プロジェクトやコードの重要性に応じて、どこまでAIに委ねるかをエンジニアが判断する戦略的なアプローチが求められます。Cursorのような対話中心のツールは「左側」に、Devinのようにプルリクエストベースで広範囲を自動化するツールは「右側」に適性があるとしつつも、どのツールでも柔軟に活用できると補足されています。
エンジニアの役割は、単にコードを書くことから、生成AIが作成したコードのレビューと品質保証、そしてシステム全体の保守性を考慮した適切な委任範囲の判断へと変化していくことが示唆されています。コードを書く量は減り、AIが生成したコードを読む量が増えるという未来が到来するものの、製品開発における中核的なコードについては、今後10年程度は「全く読まなくても良い世界」は訪れないだろうと現実的な見通しを提示しており、エンジニアがコード理解に努める重要性を訴えかけています。