「carrel.」の開発に使ったハーネスの話
carrel.というアプリについては過去の記事[1]を参照のこと。
この carrel.というアプリを作るにあたって、エージェント用ハーネスを適当に用意して Opus 5 に作らせたので、そのハーネスについて簡単にメモする。
作成したハーネス自体も GitHub で管理している。
開発フローとして Design Doc を書いてもらって、その内容をレビューした後に実装をしてもらうというフローを強制するようにした。 Design Doc は、実装の意思決定によって後戻りするのが大変になる点などを先にレビューして手戻りを減らすためのものである。 例えば次の記事などが Design Doc の例として参考になる。
前職ではある程度不確実性があったり大きな機能になることが予想されるものは Design Doc を書きそれをレビューしてから開発に移っており、その手法を取り込んでみた形になる。
また、エージェントが使うアカウントが私のアカウントと共通だと PR を自分で approve できなくて不便なので、AI 用の Bot 用アカウントとして GitHub App を作成した。 そのアカウント経由で git のコミットをするように強制する仕組みも入れておいた。
このハーネスを利用した開発の様子などは carrel.の GitHub のリポジトリなどを確認してほしい。 Design Doc をレビューして、個別の実装タスクは Issue に切り分けて PR を出して実装を進めていっている様子がわかる。
ハーネスありで開発してみたが、正直ヘタなハーネスはいらないくらい近年のコーディングエージェントはちゃんとしていると思う。 Design Doc を書いてレビューが通ってから開発するワークフローとか、AI 用の GitHub アカウントを使ってもらうための仕組みを作ったのと、あとはコーディング規約としてはコメントの付け方を指示しているくらいである。 なんか下手なことをするより Fable とか使ってコードを作らせた方が良い気もしてならない。
今回の開発ではデータの持ち方などについて Design Doc で確認して握っておいて、それ以外についてはだいぶレビューも素通りで開発した。 実装の PR レビューはほとんどノールックで approve するだけになってしまった。
自分しか使わないアプリなのでコードを読まなくてもまあ動いてくれれば良いかなという感じで。 仕事のコードだったら理解している責任があるからまだちゃんと読むけれども、この手の自分しか使わない適当なアプリになるとコードをちゃんと読まずに開発を任せてしまうことも十分考えられる程度には AI のコーディング力が強くなっている。
次に何か適当な開発をする場合にはもはやハーネスをこだわらずにとりあえず作ってもらって実装内容について解説させて、気に入らないところは作り直させるとかのほうが面倒がなくてよかったりするかもしれない。
しかし、こうやってとりあえず動けばよいやで作られたプログラムは、ちゃんとアプリやコード品質に真正面から本気で向き合ったソフトに比べればいまいちなそこそこのソフトになるのだろうなとも思う。 磨き抜かれた素晴らしいソフトにはならない気がしている。 開発に本気で作られたものではないというのには寂しさはあるが、別に元々磨き抜かれた素晴らしいソフトなんて世の中に多くもなかったし。 今回のような自分が適当に雑に使うためだけのソフトであれば、使い勝手を磨き上げる必要もないだろうし。