最後にここを更新してから4ヶ月ほど経過したので何かを書こうと思う。
前回の日記から仕事内容が変わった。 以前は機械学習で色々やるチームにいた訳だが、 今度は特定の製品（機能）を作るチームに変わった。 機械学習が得意でも好きでもない私にとってはいい変化だと信じたい。
チームの変化をきっかけに、私のAIの使い方がすっかり変わってしまった。 立派なAI丸投げ太郎になってしまったのだ。 新しい製品をゼロから作るのであれば今まで通りでも良かったのだが、 複数のサーバと複数のバッチジョブから成るシステムを渡されて 「それじゃ、このシステム全体に渡る変更をお願い。急ぎでね。」 などと言われてしまうと私の能力ではAIに頼らざるを得なかったのだ。 以前のやり方だとソースコードを読む事前調査だけで大幅な時間を消費してしまう。
まずdesign doc (設計書) を書くために、 どこを変更すべきかAIに調査してもらい、どのように変更すべきかAIに相談して、 私の書いた下手な英語をAIにもう少しマシな英語に直してもらった。 最初からAIにすべて書いてもらえばいい気もするが、 私の名前でdesign docを書くのに私の文体からかけ離れていると気持ち悪いので、 まず私が下書きを書くことできちんと下手な英語にした。 design docに付いたコメントへの返信もAIに相談した。もうこれ私いらんやん。
design docで合意が取れてコードを書き始める段階になると、 AIへの丸投げは加速する。「この部分作っといて」と言うだけだ。 前回の日記を書いたときは細かいやり方まで指示したうえでAIにコードを書かせたが、 今回はどのやり方がいいのか私の頭の中に答えがないので、AIの自主性を尊重した。 要するに丸投げである。一応言い訳をしておくと、 細かい指示を出さない方がAIはいい仕事をするという研究もあるらしい。しらんけど。 この方針はあんまりだろと思ったときはAIに口出しするとちゃんと直してくれた。 やり方が2種類あり、どちらの方針がいいか分からないときは、 両方のコードを書いてもらったりもした。 人間に仕事を頼むときに「試しに両方のコード書いてみて」とは言いづらいので、 これはAI特有の仕事の頼み方かもしれない。 コードを書かせる前の段階ではどちらの方針が良いと断言しなかったAIが、 コードを書き終えるとこちらの方針のほうが良いと断言したりして面白い。 もっと賢いモデルを使うとコードを書く前に判断できるのかも知れないが。 code reviewを受けるときもAIは大活躍する。 面倒なリファクタリングを求められたとき、以前であれば言い訳、 もとい正当な理由を説明することで リファクタリングを後回しすることも少なくなかったが、 AIに任せるとその手の仕事は瞬時にこなしてくれる。もうこれ私いらんやん。
そんなわけで、立派なAI丸投げ太郎になってしまったのだが、 この結果何が起こるかまでは現時点では分からない。 今後時間が経過することで明らかになるだろう。 いずれここに書き記すことができたらと思う。 なお、この日記は私がEmacsで心を込めて1文字ずつ書いている。
2026-10-31