エーアイ使えというトップダウン圧が日に日に高まり無視できなくなってきた。重い腰をあげ考える: 下手に成果を狙ってきちんとした「プロジェクト」にやると破滅しそうなので、成果を気にせず色々試して遊んでみるのがよさそうだ。なぜなら、今なら成果がでなくても「エーアイしてました」と言えば大目に見てもらえそうだから。

「エーアイする」にも LLM の API を叩いてなんかをがんばる AI engineering 路線と、エーアイではない職業人としてエーアイを道具として使う AI literate 路線がある。前者はマジで成果がでなさすぎて厳しそうなので（エーアイエンジニアではないので）、とりあえず後者。

というわけで vibecoding というか gemini-cli で agentic coding. HN などで様々な経験談を読んだ雰囲気から、one-shot 的にバーンと waterfall generation するのではなく細かく指示しつつインクリメンタルに書かせてみる。つまり自分が普段やるように働かせてみる。

題材としては、アプリ内である telemetry データおよびデータ収集コードが経年劣化でゴミになっているので、きちんと整理したデータモデルをクリーンな API で集め、後ろの pipeline もメンテしやすいよう直す、という中規模プロジェクト。「クリーンな telemetry API を作る」というのは比較的自己完結した仕事なのと、それで古い instrumentation を置き換える作業もわりかし単純。なので Gemini オメーそんくらいできんだろ、と煽ってみる。

世の中の保守的(?) vibecoding 勢は、まずきちんと計画を立てさせる、あるいは立ててあげるのが大事だという。これはまず design doc を書けという派閥と大体同じである。

自分はそっちの派閥ではなく、POC を作って雰囲気を眺めるのが大事だと思っているので、そういう意向を GEMINI.md に書く: とりあえず minimum に proto を定義し、それらを Dagger で inject して何箇所かで instrument してみたり最終的な telemetry の proto に詰めてみたり、あと隠すためのフラグを足したりしましょう、というのを箇条書きする。ついでに「これらは後で考える」というリストも書いておき、気が散らないようにする。誰の? Gemini… が理解できるかどうかはしらないが、自分のために書いておく。

いくつかの重要な名詞を相談して決めドキュメントに反映し、proto を生成させる。そしてラッパーが必要だったと気づき計画を書き換えてそれも作らせる。

ついでに自分の趣味を押し付けるために個人の意向を書いた GEMINI.md を切り出し、それは別に育てることにする。たとえば「インラインにコメント書くな鬱陶しい」「テストは言われなくても書きなさい」「モック使うんじゃねーリアルクラスを使え」などの指示がある。（※きちんと会社員語で書いてます。）

更にこの機能の計画とは別にアプリのビルドの仕方やコードの奇妙な流儀なども、いちいちコードを読ませているとキリがないしセッションを切るとすぐ忘れるので、コードのツリーの中に GEMINI.md を置き、そこに書いておく。きっと他の人もいるような気がするので。

など、教育用資料を揃えつつダメだしをしつつ、少しずつ作業を進めていく。

というようなことを二三日やった段階での first impression:

• コードを書けるのは感心するが、別に速くはない。
  • これは一つにはウェブやアプリの画面のような boilerplate の多い仕事ではなく、telemetry のデータモデルと API を proto と Kotlin で定義するというわりかしニッチな仕事をしている影響な気がする。決まったパターンというものがない。
  • あと、レガシーコードベースへの適応度の差がある。Gemini なんもわかってない。自分はわかってる（半分は自分がつくってしまったゴミの始末なので・・・）
  • 別の言い方をすると、自分は作りたいものがわりかしはっきりしている。それを design.md なり prompt なりに自然言語で書くヒマがあったらコード書いたほうが速い。
  • あと Gemni はしょーもないミスをして「あれおかしいな？」「そうかそうか」とかいいながら試行錯誤を繰り返す。ビルドやテストが速いコードベースならいいが、レガシーコードなので単体テストの部分実行すらビミョーに遅い。
  • LMM 自体のレイテンシもなんか遅い。ビルドが遅くてもモデルが 10x 速かったら体感はちがうと思う。(ただこれは Gemini as product が悪いのかはわからない。社内バージョンは微妙に throttle されてるんじゃないかと疑っている。)
• 余暇で小さな Django アプリを Claude Code に書かせた時の印象とはだいぶちがう。
  • 余暇プロジェクトでは細かいことをいわなくても Claude は雑な指示からよろしくやってくれた。これは Claude の賢さだけでなく、Django というのがオープンソースですごく標準化されたフレームワークらしいフレームワークだからだと思う。
  • あと既存のコードが歩かないかの違いも当然大きい。このレガシーコード、pretrain corpus には入ってないですからねえ・・・。
  • あとは自分は Django 素人だったので出てきたコードに対する好みがなかった。Django 上級者だとダメ出しの余地はあったのではないだろうか。
  • そんなかんじでマイクロマネジせず「こういうことする API はやして」「ページつくって」とか指示するだけなので、LLM の裁量が大きく一度に沢山のコードを書けた。
  • テストをするにしても一瞬で終わるのでイテレーションが速い。Python だからビルドもないし。
  • あと HTML や CSS はたとえテンプレート機能をつかっても boilerplaty なので「沢山コードを書いてくれた」という感覚が強いのかもしれない。

そんなかんじで現状の生産性は当社比 1/4 みたいな勢い。どうしたものか。

• 諦めてスーパー補完や in-editor chat を使った生成など、小規模なコード生成だけを使う。これだとできることはわかっているが、面白くないので保留。
• 自分でコードを書くという点だと Gemini とターミナル上で押問答するよりダメコードを書かせてそれを手で直す方がいい気はしている。細かい指示だしてると nitpicky review をやってる気がしてきて、というか実際やっているので、うんざりしてしまう。人間相手の時は書き手の意思を尊重してなるべく nitpick しないんだけど、Gemini 相手にはまだそういう態度は取れない。それはきっと、 pretrain に使ったインターネットの平均的なコードがゴミだから、だと思う。殺されそうな発言だが。
• GEMINI.md aka 教育用資料を拡充していく。これどのくらい効き目があるんだろうね。読んでくれるかわからない人間相手になにか書くよりはよっぽど有意義に感じる一方、抽象度高めの指示がどのくらい理解・通用しているのかは疑わしい。ほんとはこういうのは真面目にデータセットをつくって eval すべきなんだろうけど、そういうのはエーアイ部門の人がやってください。
• GEMINI.md 以外の context engineering をがんばる。たとえば session の最初に重要関連コードを明示的に全部読ませてみる。Cline/Copilot とかコレが前提だったところを agentic coding はモデルが勝手にやってくれることになっていた、が、あいつらが figure out するのを待つのはダルいので明示的に指示するのがいい気がしてきた。
• 得意分野を見極め、得意なことをやらせる。たとえばデータモデルとか API みたいな自分の意見がわりかし crystalize されているので、それを自然言語で意思疎通するのには虚しさである。一方でそうやって定義した API を使いアプリに instrumentation を足していく作業は、半機械的作業なのでエーアイ向きな気がする。
• なんとかして一撃で書いてもらうコード量を増やす・・・のは、まだ難しいかなあ。途中経過をみながら価値判断をするのに、一撃がでかくなると経過がなくなってしまう。
• 並列度を上げる。これはなんというか、ビルド待ちの間に別の仕事ができるかという話と同じで、自分の結論は「できない」であった。このへんは個人差あるんだろうけれど。あと一撃の粒度が上がってくると違うのだろうな。
• あとは LLM の出してくるイモコードを micromanage-nitpick せず受け入れる。・・・というのはたぶん将来的には正しいのだろうけれど。I’m not there yet.

というわけでレガシーコード相手のニッチ作業で agentic coding を「生産的」といえるところまで持っていくのは厳しい戦いに感じているが、まあしばらくやってみます。一般的な LLM リテラシーおよび gemini-cli のコードを読んでおいたのはメンタルモデルの構築に役立っている。

あと「プログラミングの将来は・・・」みたいなよくある意見や雑念はゼロではないけれど、そういうこと言ってると気が散るので今はどこまでいけるかのゲームに集中したい。