CONTENTS
出来上がったもの
制作日数はおよそ７日、かかった費用はおよそ１００ドル。 後から見ると結構かかってるな。
コードのほとんどは Roo Code によって生成した。 Roo Code によらないコードは CI/CD の設定のような、他のプロジェクトから流用している部分くらいだ。
なぜそうしようと思ったか
CLINE に全部賭けろ | Zenn を読んで試してみた。 この人の言うことならなんでも信用しようという人が何人かいるが、mizchi さんもその一人だ。
AI アシスタントの導入は二の足を踏んでいた。 特にソースコードが学習の対象となることで、プロダクションのコードを書かせることが難しいのではないかと考えていたためだ。
今回、学習させることになんの問題もない既存の shell script を wasm で再実装する形でやることにした。
使ってみた感想
思っていたよりも多くのことができることに驚いた。 Roo Code を使うメリットに比べれば、ソースコードが学習の対象になる、ということは障壁だと感じないほどの有能さを感じた。
今後、プロダクションコードは Roo Code を使用して書くことになるだろう。
Roo Code に、より多くのことを任せるのはかなり大きなリスクだろう。 しかし、人間ができることは全てやらせる、これに意味があるのだと感じる。
とはいえ、自動でなんでもやらせるのは怖いので、今回は Read、Edit、Browser のみ許可してコードを生成させた。 これはワークスペースのファイルの読み取り、書き込みと、ブラウザの操作を自動で許可する設定だ。 それ以外は「やってもいいか」と聞かれるので Approve / Reject を都度選択する形になる。
ただ、今回は基本 Approve する感じで進めたので、Roo Code が持っている選択肢をほとんど制限なくやらせる形になった。
得意なこと
細かい仕様が決定している場合、その通りにコードを生成してくれる。 特に、既存のソースコードから別言語への移植はほぼ指示することなく完璧なコードを生成してくれた。
ドキュメントも十分満足できる精度で生成してくれる。 ドキュメントは人間には保守できない分野だと考えている。 機械がこれを担う未来がきた。 コードの変更に伴ってドキュメントを変更することは人間にとっては厳しいタスクだが、Roo Code はこれを自動でやってくれる。
テストケースに関して、ホワイトボックステスト（内部構造を理解した上でのテスト）はある程度テストケースを自動で生成してくれる。 いくつか注文をつければ、網羅的なテストケースを生成してくれるので、もはやカバレッジを気にしなくていいように感じる。 もちろん、生成されたテストケースをよく確認するという前提においてだが。
リファクタリングの提案を特定のソースコードに対してさせるといくつか改善案を提示してくれる。 その後、実施するものを指示してあげるとうまくリファクタリングしてくれる。 これを繰り返すことで、ほとんど自動でリファクタリングが完了する。
人間が書くとめんどくさいコードも Roo Code なら問題なく生成してくれる。 人間がソースコードを書かないことを前提にした場合、これまで面倒なためにやらなかったようなコードを生成するようになる可能性を感じる。 これが良い方向に働くか悪い方向に傾くかは人間の判断次第だろう。
Roo Code が生成したコードを丸ごと却下しても Roo Code は文句を言わずに次のタスクを開始してくれる。 もし人間なら、指示されて書いたコードを丸ごと捨てられたらかなり厳しい関係性になる。 Roo Code ならそんなことは気にする必要はない。 もちろん、そのトークン分の金額は飛んでいくが。
苦手なこと
Roo Code にとって統合テストや E2E テストのような、抽象的なテストを通すことはかなり難しいタスクのようだ。 数回の試行でうまくいかなかった場合、そのテストを通すためだけの修正を加えて「諦める」ことがある。 テストを通すための修正に対してはしっかり目を光らせておく必要がある。 複雑な原因で失敗するテストを通すのはまだ人間が行わなければならない。
使用していないフィールドがあった時に、「これは何に使うの」みたいな皮肉的な質問を出したら、それを無理やり使うような修正を始めた。 「必要ないので削除」のような、明確な指示を出さないとコードの生成はうまくいかない。
「いい感じに」というような曖昧な指示はほとんど受け付けない。 無理やりコードを生成させると、酷い品質のコードを生成する。 うまくコードを生成させるためには、具体的な指示を出さなければならない。
上手く使う方法
多くの情報を読み取らせると、多くの時間とトークンを消費する。 コードを生成するための情報を少なくする工夫が必要になる。 ソースコードを短く保ち、依存性をスッキリさせ、必要なサマリをドキュメントに書いておく。 人間が書く場合と同様の、良い習慣を守ってコードを生成するとうまくいく。
最初から完成形のコードを生成させようとするとうまくいかない。 始めは単に動くコードを生成し、その後リファクタリングを繰り返す。 これもまた人間が書く場合と同様の手順でコードを生成するとうまくいく。
Roo Code はコードを大幅に変更する可能性がある。 コードの生成を指示する前に git commit しておき、いつでも restore できるようにしておく必要がある。
Roo Code が生成するコードに癖があるように感じる。 Rust で clone を多用するとか、TypeScript で console.log を多用するとか。 プロジェクトが大きい場合、コーディング規約をまとめておき、それを読ませる工夫が必要になるだろう。
まとめ
AI アシスタントの使用によってプログラミングの方法が大幅に変化すると感じる。 自分でコードを書くことはなくなり、AI アシスタントの生成したコードを整える仕事になる。 例えていえば、Pull Request を出してもらって、レビュアーとして鬼詰めする感じ。
コード生成を通して感じたのは、プロジェクトの目的がだんだん明確に意識されていくような感覚。 どのような目的でコードを生成するのか。 生成されたコードを分析して、どのような目的に合致することを確認するのか。
これが多分、ドメインの探索なのだと感じる。 これまで、ソースコードという詳細に潜らないといけなかったのが、より抽象的な観点からプロジェクト全体のことを考えてコードのことを考えられるようになる。
おそらく、これがこれからのプログラマの仕事なのだろう。
