AIを使わせようとする圧力
個人的には未だAIというものが好きにはなれていません。それは自分の仕事が奪われかねないという恐怖か、自分が好きな、プログラミングの美学をあれこれ考えるような楽しい時間が奪われることへの抵抗か、そんなところでしょうか。
そうはいっても、私たち開発者のところにも、「AIを製品に組み込んで製品価値を向上させよう」とか、「開発の中でAIを使って生産性をあげよう」とかそういった圧力は来るので、とりあえずAIと接触してみることにするのです。
プログラムの実装
さて、プログラムを実装してもらえると本当に楽になるので、まず実装をあれこれやってもらおうとするわけです。
「この範囲をこの設計に従って書いて」と言う依頼でもまあ、ちゃんと書いてはもらえるのですが、プロジェクトのコンテクストを与えないと、そのプロジェクトの中では浮いたコードが生成されます。
私自身は、「それがたとえひどい実装であっても、そのプロジェクトの社会通念と化しているならば従わなければならない」と考えています。これはどんなにひどくてもパターン化されているならば認知コストが減るからです。
と言うことで、何か実装をお願いするときは参考実装を与えるようにしています。バリデーションを実装させるときは他の似たようなバリデーションを、データアクセスを実装させるときは似たようなデータアクセスを...と言う感じです。 これだけでもコピペして必要な部分を修正して15分みたいな作業がちょっとした手直しだけで済んで1分とかになるので良いです。
設計のレビュー
最近はどちらかというと基本設計や詳細設計をする立場になっているので、設計のレビュワーになってもらっています。指摘がエラーハンドリングとかだけになっていればおおむね設計としての筋は良いだろうと判断しています。
自分は設計するだけで、実装は他の人がやる場合は、ある程度指摘が減った段階で、それを元にAIに実装してもらうときがあります。なんかそれっぽい画面とかが出来ていれば「まあ作れるやろ」の精神で設計書の作成完了にしています。
学習のために噛み砕いてもらう
自分にとってのAIの楽しい用途はこれです。たとえば、「MQTTってどういったもので、どう実装されているのだろうか」と思った時に、「XXを説明してください。簡単な実装をしてください。」ってお願いして、そのソースコードを眺めたり動かしたりしています。
製品に組み込むの部分は全く考えられていないのですよね。何か作るときに「AIで」と言う謎の道具の指定があるのがおかしいと言う話な気はしますが......
頑張ってAIと分かり合えればなと思います。
以上！