結論
つまらない結論だが、AIにゴミを入力してもゴミしか出力しない。
失敗した
試しに、これまで人の手で開発していたシステム（そこそこ複雑で大規模）を、AIに全任せしてみた。
開発も、レビューも、テストも。
ちゃんと要件を伝えれば、あとは既存のコードを読んでくれて仕様も理解してくれるし、少なくともバグは人が書くよりも減るだろう
という淡い期待は泡に消えていった。
最初は安定稼働してたけど、あるとき急に色んなバグが発生しだした。
そんな初歩的なエラー？これまでのコード読んだら分かるでしょ？
AIが全部やってくれるって言ったじゃん。（誰かが。）
当たり前のことを、ちゃんと理解していなかった。
AIは入力に対して応えるだけ。
もしAIに既存のコードを見て仕様を理解してほしいなら、そう言わないといけない。
リグレッションがないようにして欲しいなら、「リグレッションがないようにして」
と言わないといけない。
まあそんなレベルは今後のAIの進化で解消されると思うかもしれないけれど、
言わなければ伝わらないぞ。言わなければ、伝わらない。
僕に足りなかった言語化
設計書や要件定義書をちゃんと書くとかはAIに関係なく当たり前だとして、
もし、AIが新しく参画したプロジェクトのチームメンバーだと考えれば、
今までは人間同士の会話で完結していた以下の内容を、仲間外れにせずAIにも教えてあげないといけない。
現場の言語化
現場視察やヒアリングをして知ったこと、感じたことを全部書く。
めんどくさいけど簡単だ。
課題の言語化
起きている問題や、解決したい課題を書く。
具体的な観点から抽象的な観点まで、全部書く。
本当の課題ってなんだろうみたいな哲学に悩まさせることもあるけど、頑張る。
特例の言語化
プロジェクトや会社特有の事情やルールを書く。
「徐々に覚えればいいよ」
というのは人間の新人にしか通用しない。
今、全部、叩き込む。
意思決定の言語化
会議や喫煙所、飲み会にはちゃんとAIも呼んでるか？
プロジェクトの話をしたのに呼んでなかったのなら、せめて話した内容を教えてあげよう。
じゃなきゃ飲み会は禁止。
評価の言語化
成果物に対してのエンジニアや現場からの評価を丁寧に全部書く。
レビューも含む。
もし評価ができなければ、自分がシステムを何も分かっていないということなので出直す。
まとめ
よし、出直そう