アメリカの方で政府機関のコードをCOBOLから他の言語にするみたいなことをやる不確かな噂がありますが、それとは全く関係がない話です。もっともっと規模が小さいやつ。使ったのはCline(Claude 3.7 Sonnet)です。以下、AIとはClineのことを指します。
やってみたのはTypeScriptのライブラリからGoへの移植。対象は、https://github.com/mizchi/readability 。
とはいえこちらもWIPとあるように、まだやりきれてない箇所があるので、本家の https://github.com/mozilla/readability を元にした方が良かったかもしれない。ただ書き直されていると言う点や、元コードからAIで整理されていると言う点はポーティングに有利だったかもしれない。
なんでreadabilityをGoに移植したかと言う説明をする。AIがコーディングする場合、AIはうろ覚えの知識で勘でコードを書いているような動き見せる。AIが勘で書いたコードというのは見た目がもっともらしいものの、しばしば間違っている場合がある。テストコードを用いて検証したり、静的型付け言語であればコンパイル時に検証できるものの、これでは書いては直しのサイクルが発生し、時間とトークンを消費する。AIはここが高速にできるので成り立っていると感じるものの、最初から通るコード、もしくはそれに近いコードが書けたらそれに越したことはない。 一方で、AIはコンテキストにかなり性能を引きずられる面がある。正解に近い、あるいはお手本になるようなコードがコンテキストとして読めていれば、正しいコードが出力される確率が上がる。というわけで、コードを書く際に横目に公式ドキュメントを置いて書いてほしいのだが、それを引っ張ってきてAIに読ませるようなMCP等を書くのに必要なのであった。私はGoの方が得意なのでGoでこう言うライブラリが欲しかったと言うのもあるし、Goなら比較的低リソースでクローラー等を動かせるでしょう。
こんな感じで、あくまで個人的かつ実用的な目的でありAIでやったのはそこにあったからという感じである。でも皆さんが聞きたいのはAIでどのようにやり、そしてうまく行ったのか行かなかったのかと言う話であろう。
結果
なんか動いているように見えるし、本家mozilla/readabilityのテストケースを一つパスしているので、なんとなく大丈夫な気がするが、何せ全てをAIで書いているので自信がない。 かかった費用としては多分$30ぐらい。期間は3日ぐらいで休み休みやっています。人間がやったのは最初の計画時の壁打ちで、そのあとは「次のタスクを始めましょう」と最初のプロンプトを打ったり、時々Goのことでつまづいてそうだったら教えるぐらい。
手法
そもそもこれはGitHub Copilot Chat Agent Modeの実験だったので、プロンプトが .github/copilot-instructions.mdにあり、Rate Limitに引っかかるのでClineに切り替えた関係上、.clinerulesは上記のファイルにsymlinkしている。
それはさておき、このファイルを読むと色々ルールが書いてあるが、一番効いたのは「external-docsと言うディレクトリを置いたので、そこにガンガンgit cloneしてこいである」。先ほども言ったように、参考になるコードさえあればそれなりに書けるのである。なので自分で必要だと思ったら落としてこいと言っている。今回は最初にmizchi/readabilityを、その後にfixtureで使用しているファイルの元ネタが気になったのでそれを聞いたら勝手にmozilla/readabilityをcloneしてきてこれと同一であると述べた。
あとはTASKS.mdとMEMO.mdを作ってもらい、最初にTASKS.mdで計画を立てつつ、覚えていた方が良いことがあればMEMO.mdに書いてと促した。MEMO.mdの旨は.clinerulesにはないが、タブで開きっぱなしだったのでそれで見てもらってたかもしれない。
TASKS.mdで立てた計画はほとんど変更なしに最後まで動いた。普通のプログラミングを伴う開発は実装中に計画が狂うことがしばしばであるが、今回は移植という作業なのでやるべきことが最初から決まっていると言える。まずタスクを分解した上で計画を遂行するパターンがかなり効果的なので全てをAIがこなすことが可能だったかもしれないと考察する。
つまづいた点
Go 1.24から開発に用いるツールの管理がかなり良くなった。go get -tool <tool location>でバージョン管理に取り込め、またそれをgo tool <tool name>で呼び出せる。しかしLLMのカットオフの時期としておそらくこの知識は獲得していないだろう。なのでgo installでグローバルに突っ込もうとしたりしてなかなか大変だった。
人間でも言語のライブラリエコシステムやツールチェインを身につけるのは少し骨が折れる。環境構築やルール作りもAIは苦手なので、そこら辺は人間がまだやる仕事のように思える。
また、言語の漸進的な進化に対してLLMのインターネット等の情報から事前学習を行うという手法はあまり有利ではないように思える。例えばGoは1.18からgenericsが使用できるが、これをAIが有効に使えた場面を見たことがないし、genericsを使用するライブラリを使うのは苦手なように思える。苦手というのは最初に通らないコードを書いていることが多い。一方でGo 1.7から導入されているContextは苦もなく使えているので時間が解決するかもしれないし、しかしAIばかりがコードを書きAIが現時点で得意なコードのみがインターネットに溢れるようになったら、いつまで経っても得意にならないかもしれない。
それで？
こうやって雑に移植がある程度機能するのはいいが、開発をやっているという感覚がないし、コードに対するオーナーシップも薄い。OSSにおいてコードのオーナーシップはメンテナンスの頻度やissue対応に影響してくる。多分こんな雑実装であるものにそんなに人は頼ってこないとは思うが。。。
このやり方が機能する規模の限界があるように思える。その点細かいライブラリが多いJavaScript/TypeScriptをGo等に移植するのは容易になるだろう。しかしRustのような設計レベルで書き方を変えないといけないものもあるだろう。その場合は可能かもしれないが、時間とトークンを消費することになると私は予測する。
また、AI雑ライブラリをうっかり使ってしまって、バグ修正や機能要望をしたものの、作者が飽きたりトークン代を払う金が無い等で対応されないケースも出てくるだろう。しかし人間がみんながみんな継続してパッションを持って手で書いてOSS等を書いているわけでは無いのである。その時はあなたがトークン代を払って問題を解決する未来が来るかもしれない。
