後年参照するため不定期でエーアイ使用状況を記録しておく試み。(前回: Claude Code - 2025-04-11, 仕事で Vibecoding してみるターン #1 - 2025-08-14)

ホビー用途。

子供の漢字練習プリントを Anki (spaced repetition) 方式で生成したいと思い、Electron アプリを作った。ウェブでなく Electron なのはセキュリティの担保がめんどくさいため(機密情報とかないけど VM を abuse されるだけで困る)。コードは数千行程度のトイプログラムだが、実用できており満足。

Claude Code に React で書かせているにも関わらず自分は React を全然わかっておらず、Road To React という本で入門した。まさかエーアイのコードを読むために React 入門するとは思わなかった。（薄くていい本でした。)

生成されたコードは、今のところ全部目を通している。コミット単位のレビューはだるいので、何個か機能を作らせたあと事後的にレビューして気に入らないところを直させている。

レビュー、全然やりたくないね。めんどくさいだけで何も楽しくない。仕事では諦めてやってるけどホビーでやるもんじゃねーわ。エーアイも human in the loop で律速されたら本気だせないだろうし、コードは見ないでなんらかの定量的な品質メトリックを最適化するのが未来なのだろう。定量的指標があれば RLVR もはかどることでしょう。

冷やかしも兼ね、人間の手間を減らすという名目でコードを gemini-cli にレビューさせ、そのフィードバックを Claude に渡し「納得したのだけ直して」といったら 10 個の指摘のうち 2 個だけ直し、あと 8 個は「やりすぎですね」とかいってスルーしており笑ってしまった。好きにしてくれや。ただウェブ素人としてレビュー結果は勉強になる瞬間もあるので今後も非定期にやらせたい。

Claude Opus の書くコードの印象は、いまいちなときもあるが、基本的にウェブプログラマとしては自分(=素人)より 100x 有能である。ついでに人間だってしょっちゅうダメなコードを書いていることを我々職業プログラマは知っている。

細部や好みを差し置くと、一万行もないトイプログラムならコンテクスト溢れのような問題があまり起きないので、単純に「わー便利」というかんじ。何も難しさがない。この問題は Sonnet 3.7 とかでも行けた可能性すらあるが、Opus 4.6 だともはやまったく危なげがない。もうちょっと大きいコードだとどうなるのか試してみたいけど、他のアプリを考えないとダメだな。

洗練の余地が大きいとはいえ特段困っていないせいもあり、プロンプト (CLAUDE.md, skills) はがんばってない。ホビーだからと心の中で言い訳している。数ヶ月待つだけでモデルが勝手に賢くなったりもするし。

そうはいっても現状の自分のやりかたは原始的でダサいとは思う。

Claude Code の中の人 や Gas Town のような覚醒した人々が使う並列セッションも、やってない。結果をみながら直させているので並列化できない。あと強い subscription に入ってない。沢山の部下をこき使うみたいなメタファもうんざり。

以上ホビー。以下仕事用途。

Agentic coding は、使ってない。これは Gemini 縛りで Claude を使えないからという面もあるし、それ以上に触っているコードが大規模レガシーコードだから、という面もある。以前（2.5, 3.0 時代) 試したがあまりに不毛だったので諦めた。最新版(3.1)はまだ試してない。

最近の仕事は、バグを直すついでに壊れやすいコードを時間をかけテストカバレッジを増やしつつリファクタリングしている。手で。眼の前のクソコードが自分の力いい感じになっていく満足感、もう一年だか数年だかしたら得られない体験かもしれないので、今のうちに楽しんでおきたい。

といいつつ自分の眼の前にあるこの特定のコードをさわることは、というか自分の眼の前のバグを直すのは、今はまだエーアイにはできなそうだなと思う。というか、ぶっちゃけ自分以外のチームメイトでも正しく直せる人いるのかな・・・というかんじ。なぜならレガシーコードだから。

レガシーコード、微妙な壊れやすいスレッドモデルの想定があちこちにあり、ちょっといじるとすぐデッドロックしたりレースコンディションで壊れたりする。そういうコードがアプリのあちこちにあり、壊れるとテニュアの長い自分のところに回されてくる。そもそもバグを確実に再現する方法すらなく、スタックトレースやログを睨みカンで直さないといけない。

こういうAI不可能コードはジョブセキュリティと見ることもできなくはないけれど、ダメだね。昔からクソコードはチームの velocity を下げると広く知られているわけだが、エーアイにバーっと書かせたいならコードの壊れやすさは致命的である。エーアイが周りのコードの雰囲気にあわせカンで書いてもだいたい動き、壊れたらテストが知らせてくれる、というコードベースでないとエーアイをスケールできない。別の言い方をすると、クソコードの生産性被害がエーアイによって（相対的に）増幅される。

別の言い方をするとコード品質を含む技術負債の返済・抑制はエーアイ加速時代の前提条件と言える。が、その投資判断をするのは自分ではなくもうちょっと偉い人であり、自分のような下々が「エーアイのためにコード綺麗にしましょう」とかいっても誰も信じてくれなそうので、しらね。賢い L6 L7 連れてきてがんばってください。それまで下々たるわたくしはエーアイ使わなず手工業がでがんばりますので。

仕事はさておき、ホビーとしての「エーアイに良いコードを書かせる」ゲームは割と楽しんでます。