自社ESLint Rulesのすゝめ。汎用ルールではAIコーディングは制せない

DRANK

結論からいうと、生成AIにコードを書かせるなら、自社ESLint Rulesをつくった方がいいです。汎用のESLint Rulesは、多くのプロジェクトに共通する事故を止めてくれます。ただし、私たち固有の「ComponentにはLifecycle以外のメソッドを置かない」までは知りようがありません。生成AIに守らせたいのは、言語としての正しさだけでなく、このプロジェクトでの書き方です。私がそれを痛感したのは、エラーが起きている箇所を生成AIに直させた時でした。返ってきたコードは、処理全体がtry-catchで囲まれていました。エラーは消えました。正確には、見えなくなっただけでした。「全体をtry-catchで囲わないで」とプロンプトに書いても、別のタスクではまた囲う。そこで私は、お願いするのをやめました。違反したらCIが落ちる、自社ESLint Ruleをつくりました。しかも今は、そのRule自体も生成AIでつくれます。コードを書く量は増え、ガードレールをつくるコストは下がった。だったら、同じレビューコメントを人間が繰り返す必要はありません。AIがtry-catchで隠蔽するので、Ruleで止めた生成AIへ修正を指示した時、よく返ってきたのが次のコードです。// ❌ 処理全体をtry-catch…