AI にコードを書かせる時代こそ基本が効く ― Matt Pocock 氏のワークショップに学ぶ、AI コーディングの進め方

AI にコードを書かせる時代こそ、ソフトウェア工学の基本が効く。ロンドンの AI Engineer で、マット・ポーコックさんが示した開発の流れを、8つの場面で見ていきます。

ポーコックさんの出発点です。AI は新しいパラダイムだと言われますが、人と働くために大切だった、ソフトウェア工学の基本は、AI にもよく効く。このワークショップは、それを確かめる流れになっています。

仕様書を書き、AI にコードへ変えさせ、結果が悪ければ仕様書だけを直す。この、仕様書からコードへ、というやり方を試したが、うまくいかなかった、と言います。コードを理解し、形を整え続ける必要があるからです。

代わりに使うのが、AI に自分を質問攻めにさせる、Grill Me です。数十の質問で設計の穴を埋め、AI と設計の考えを共有する。共有できていれば、まとめの文書は読み込まなくてよい、という考えです。

AI は、データベース、API、画面と、層ごとに作りたがります。これでは、全部がつながるまで確かめられません。そこで、全部の層を細く貫く、垂直スライスに分け、早くから動作を確かめます。

計画は人のデイシフト、実装は AI のナイトシフト。人が昼のうちに課題を並べておけば、AI は人の手を離れて、作業を進められる、というたとえです。

実装では、まず失敗するテストを書かせ、それを通すコードを書かせる、テスト駆動開発を使います。テストや型チェックのないコードベースでは、AI は手探りで書くしかない。ループの質が、出来の上限を決めます。

人の役目は、QA とコードレビューです。ポーコックさんは、QA で自分の好みやセンスを持ち込むと言います。すべてを自動にすると、センスのない、質の低いアプリになりやすい、という指摘です。

最後はコードベースの形です。小さなファイルが入り組む、浅いモジュールでは、AI は依存をたどれず、テストの境目も引けません。小さな入口に多くの機能を持つ、深いモジュールに寄せると、テストしやすくなります。

仕様書から直行せず、質問攻めで設計を共有し、垂直スライスとテストで確かめ、深いモジュールに寄せる。悪いコードベースからは、悪いエージェントしか生まれない。AI の時代こそ、名著に書かれてきた基本が効く、というのが結論です。