AI未導入エンジニアが有利と20年SE

著者の論拠は、ソフトウェア開発への直接的な類推に基づいている。「この一覧画面をいい感じに作って」という粗い指示だけをプログラマーに渡せば、意図に合わないものが出てくる——例えば並び順が逆になっていたり、レコード件数が多い場合の表示挙動が考慮されていなかったりする——そしてそれはプログラマーのせいではない。著者によれば、同じ構図がAIにも当てはまる。「ログを集計するスクリプトを作って」と頼めば、実際のログ形式に合わず、集計したい項目も欠け、ライブラリの制約も無視した、もっともらしいコードが出てくる。目的と環境、ログのサンプル数行を加えれば、そのまま動く確率はぐっと上がる。違いはAIの能力ではなく、与える情報の量と目的の明確さにある。

著者はこれを、より長いエンジニアリングの伝統の中に位置づけてもいる。本の核心は、エンジニアが昔から知っている「決めてから作る」順番、すなわちウォーターフォールであり、著者は今「仕様駆動開発（SDD）」と呼ばれているものも同じものだと考えている。新しい技術を学ぶ本ではなく、すでに持っている力を新しい相手に向ける本である。

MCPやカスタムスキル、エージェントループ、ハーネスを追いかけない理由として著者が挙げるのは三つ。それらは目的ではなく手段であること。実際に必要になったときはAI自身が設定を案内してくれること。凝った設定は短命に終わりがちな一方、目的を伝え、材料を渡し、選択肢を引き出し、文書にまとめ、人間が検証するという基本のやり取りは、どのAIやサービスを使っても引き継がれること。つまり賭け金は、読者がツールへの習熟ではなく、指示の質と目的の定義をボトルネックとして捉えるかどうかにかかっている。根拠として示されるのは、著者自身が半年で十数件のプロジェクトを回した経験である。機密データを扱う読者は、共有可能な業務情報とそうでない情報の線引きが後の章に委ねられていることに留意するだろう。