「無駄な努力をしない」知性が消える——LLMが失わせる”Laziness”という開発者の最重要スキル

GitHub CopilotやChatGPTがコードを書く時代、開発者の生産性は飛躍的に向上した——そう信じられてきた。しかし、ソフトウェアエンジニアのブライアン・カントリル氏が投じた一石は、技術業界に静かな波紋を広げている。「AIにはプログラマーの美徳である”怠惰”がない」という指摘だ。この一見矛盾した主張は、AI時代の開発現場が直面する本質的な問題を浮き彫りにしている。

「怠惰」はバグではなく、仕様である

プログラミング界の古典『プログラミングPerl』の著者ラリー・ウォールは、優れたプログラマーの三大美徳として「怠惰(Laziness)」「短気(Impatience)」「傲慢(Hubris)」を挙げた。特に「怠惰」とは、無駄な労力を避けるために全体を俯瞰し、より効率的な解決策を模索する知的態度を指す。

カントリル氏が問題視するのは、LLM（大規模言語モデル）が持つ「とにかく動くコードを生成する」という性質だ。AIは問われたタスクに対して即座にコードを返すが、そこには「本当にこの実装が必要か？」「もっとシンプルな方法はないか？」という批判的思考が欠けている。人間のプログラマーなら「このコードを書かずに済ませる方法」を先に考えるところを、AIは躊躇なくコードを量産する。

コード生成の高速化が招く「思考の外部委託」

AIによるコード生成が日常化すると、開発者は徐々に「考える前に生成する」習慣に陥る。これは単なる効率化ではなく、問題解決のプロセス自体の変質を意味する。

従来の開発では、コードを書く前に以下のような思考プロセスが存在した：

• この機能は本当に必要か？既存のライブラリで代替できないか？
• 将来的な保守性を考えたとき、どの設計が最もシンプルか？
• パフォーマンス要件を満たす最小限の実装は何か？

しかしLLMを使うと、こうした熟考のステップを飛ばして即座に「動くコード」が手に入る。結果として、システム全体の複雑性は増大し、技術的負債が蓄積していく。カントリル氏は、この現象を「思考の外部委託」と呼び、長期的な開発能力の低下を危惧している。

「書かないコード」こそが最高のコード

ソフトウェア工学の格言に「最良のコードは書かれないコード」というものがある。これは冗談ではなく、保守性・セキュリティ・パフォーマンスの観点から見た真理だ。コードは存在するだけでバグの温床となり、保守コストを生み出す。

人間のプログラマーが持つ「怠惰」は、この原則を本能的に理解している。面倒なコードを書きたくないからこそ、問題の本質を見極め、既存のツールや設計パターンを駆使して最小限の実装で済ませようとする。この「書かない努力」こそが、システムをシンプルに保つ最大の要因だった。

対照的に、LLMは「コードを書くこと」に対してコストを感じない。プロンプトに応じて無限にコードを生成できるため、「本当にこれが必要か」という自問自答が生まれない。この非対称性が、AI支援開発における最大の落とし穴となっている。

求められる新しい開発者像：「AIの怠惰」を代行する人間

カントリル氏の指摘は、単なるAI批判ではない。むしろ、AI時代に必要とされる開発者スキルの再定義を促している。今後のプログラマーに求められるのは、コーディング速度ではなく「何を書かないか」を判断する能力だ。

具体的には以下のようなスキルセットが重要になる：

• AIが生成したコードを批判的に評価し、不要な部分を削除する「編集力」
• システム全体のアーキテクチャを俯瞰し、最適な抽象化レベルを選択する「設計力」
• 「この機能は本当に必要か」を問い続ける「本質思考力」

AIはコーディングのアシスタントであって、思考の代替ではない。この境界線を明確に保てる開発者こそが、AI時代に真の価値を発揮する。

まとめ：「怠惰」を取り戻す開発文化の構築を

AIコード生成ツールの普及は、開発者から「考える時間」を奪いつつある。しかし本当に失われるべきでないのは、コーディング速度ではなく、「無駄な努力をしない」という知的態度——つまり「怠惰」だ。

技術コミュニティには今、この美徳を意識的に保存し、次世代に継承する責任がある。コードレビューでは「何を書いたか」だけでなく「何を書かなかったか」を評価し、設計ドキュメントでは「なぜこの実装を選ばなかったか」を明記する。こうした文化的実践が、AI時代のソフトウェア品質を支える基盤となるだろう。

カントリル氏の警告は、技術進歩の影で失われつつある、プログラミングの本質的価値への呼びかけだ。AIと共存する開発者は、機械が持たない「怠惰」という美徳を、これまで以上に意識的に発揮する必要がある。