pdlc-skills は AI に書かせたコードの品質をどう守るのか

個人の開発者が書いた「pdlc」というAI開発の仕組みでは、AIに書かせたコードの品質を一つの関門ではなく、七つの環を直列につないだ一本の鎖で守っている。七つは、要件、設計、TDD（先に失敗するテストを書く）、実装、ユニットテスト、E2Eテスト、別のAIによるレビューだ。最初の二つはAIが書いてAIがレビューし、最後に人が一度確認する。中の四つは機械が終了コードで判定し、交渉の余地を残さない。前回の記事で書いた自律ループの速さに対して、品質をどう保証するかという問いへの答えが、この設計である。

膝を打つのは、著者の「AIには自分で分かっている感覚がない」という指摘だ。自分の仕事を採点させると、AIは体系的に甘くつける。嘘をついているのではなく、本当にうまくやったと思っているからだ。だからこの仕組みでは、AIの自己チェック結果は記録するだけで、止めるかどうかの判断には一切使わない。もう一つの本音は、カバレッジの話だ。カバレッジが示すのは「その行が実行された」ことだけで、アサーションのないテストでも満点を取れる。数字の緑は安心の材料ではなく、点検が走ったという記録にすぎない。AIにコードを書かせる時代の検品は、作り手の感覚ではなく、実行結果と人の一回の確認で成り立つ。これが私の読みだ。

中小企業がAIで社内ツールやシステムを作らせる場合も、この考え方を縮小して使える。まず、人が必ず確認すべきこと（作るべきか、範囲はどこか）と、機械で自動チェックできること（テストが通るか、エラーが出ないか）を分けて書き出す。そのうえで、AIに「テストを直して通す」ことを禁じるだけでも、見せかけの完成を防げる。作る量が増えるほど、人がすべてを読む方式は破綻する。浮いた時間を確認に回し、確認すべき項目を最初に決めておくことが、AIの速さを実務で活かす近道だ。