『 Beyond Vibe Coding 』読書メモ
全体を通して印象に残ったポイント
- 偶有的な複雑さをAIに任せ、本質的な複雑さに人間が取り組む
- Vibe Codingによってプロトタイピングの速度は格段に上がり、フィードバックからの学びや意思決定が迅速になる
- プロトタイプでなく製品を構築するコードの場合、AIの出力を全てレビューし、説明できないコードはマージしない
雑感
Vibe CodingとAI支援エンジニアリングを対比して、Vibe Codingの課題を補うものとしてAI支援エンジニアリングを説明している。Vibe Codingはプロトタイピングを爆速化するが、セキュリティリスクや保守性に対するリスクが比較的高い。AI支援エンジニアリングでは、開発する前に計画を立て、受入基準を定義する。AI支援エンジニアリングは、いわゆる「速度」はVibe Codingに劣るが、生産性を向上させつつ、成果の信頼性も維持・向上させることができる。
Vibe CodingとAI支援エンジニアリングは排他的ではなく、グラデーション[1]。開発者は用途に応じてそのグラデーションのどの地点の方法を使うか選択する。Vibe Codingでプロトタイピングを加速させ、選択や意思決定を迅速化する。AI支援エンジニアリングでプロダクトコード実現の生産性を加速させつつ信頼性も維持・向上させる。
信頼性を維持・向上させることも狙う場合、AIが生成したコードをレビューすることが重要となる。この点は本書で何度も出てくる。AIをジュニア開発者として扱う、AIのコードはインターン生が書いて帰ったもののように扱う、というように。プロダクトコードにマージするものについては、説明できないものはマージしない、この規律が大事になる。説明できないものはバグを生む可能性もあり、セキュリティリスクも高まり、保守性も損なうリスクが有る。
「70%問題」が提示されている。ソフトウェアエンジニアリングの70%の部分はAIによって生産性が爆上げ（turbo boost）されるが、残りの30%は思慮深い開発者の持つスキルが依然必要だという。前者の部分は偶有的な複雑さであり、後者は本質的な複雑さである。（ In Fred Brooks’s classic terms, AI tackles the incidental but not the intrinsic difficulties of development. （第三章））数値は比喩的なものだろうが、この境界の線引きは分かりやすい。業務等でこれはAIに任せられるのか？任せるべきか？と疑問に思ったら、理論的には、偶有的な複雑さであれば任せられると考えることができる。なお、最終章では、モデルの改善により30%の部分はより少なくなる可能性が指摘されている。
「70%問題」については下記ページでも説明されている。
セキュリティ・保守性・信頼性に関する具体的なプラクティスが紹介されている。例えば、コードレビュー戦略として、「早く書いたのだから、早くマージしよう」という思い込みで手を抜いてはいけない、という指摘がある。この思い込みは、AIで高速にコードを記述できるようになったことによる弊害だ。レビューがボトルネックになると、「焦り」のようなものが出てくる可能性はある。他にも、AI利用によって起こり得る課題やその対処案について具体的に紹介されている。
9章では、Vibe Codingの倫理的影響について書かれている。例えば、銀行のソフトウェア開発において、AIが学習データの偏見に基づいた不公平な融資判断を促すコードを生成する可能性が指摘されている。自分はこのような可能性を考えたことがなかったので新鮮だった。他にも医療のケースなどが紹介されている。
下記ページでは、本書の著者がAI支援開発について簡潔かつ具体的なアプローチを紹介している。
-
本書ではスペクトラム。スペクトラムはあまり日常会話で使わない気がするので、この読書メモでは、同じような意味の「グラデーション」を選択した。 ↩︎
Discussion