機能を一つ足すにも、不具合を一つ直すにも、たいてい同じ道を行く。編集ソフトを開き、ファイルを探し、書き換え、試験を走らせる。一日中端末の中で働く人にとって、この道には真ん中に居心地の悪い継ぎ目がある。助手との会話は一つの窓、コードは別の窓。行き来するのに、どちらの仕事よりも多くの注意を取られる。

Aider は会話を端末へ移す。企画のフォルダに入り、道具を起動し、同僚に話すように欲しいものを語る。この関数に引数の検査を足す、この三つのクラスから共通の筋を抜き出す。コードを読み、ファイルを書き換え、試験を走らせ、編集ソフトが一度も現れないまま仕事を終える。数万人が見守り、数百万回導入されているところを見ると、その継ぎ目は外す値があったらしい。

変更はすべてコミット、後悔は命令一つ

多くの人が夢中になる設計は単純だ。保管庫に対する変更のたびに、書かれた説明を添えて版の管理へコミットする。変える前がどうで、変えた後がどうか、どちらも履歴に残る。だからいつでもきれいな戻り道がある。壊れたら、いつもの道具が差分を見せて戻してくれる。「どのファイルに触ったのか」で悩む必要はない。

作者はこの原則を作品全体に通しており、開発者の集まりでの評価の高さの大きな部分はそこにある。そしてこれは小さな規律でありながら、仕事の心理を変える。エージェントに課題を渡すことが、賭けではなく枝を切ることに近づく。

まず地図を描き、それから手を動かす

大きな保管庫を前にすると、道具はまず文法の解析器で保管庫全体を解き、地図を作る。どのファイルがあり、どのクラスがあり、どの関数があり、互いにどう呼び合うか。原文のすべてをモデルに渡すのではなく、まず骨組みを見せ、そのうえで必要なファイルを正確に選ばせる。

これが、大きな企画を理屈ではなく実務にしている。別のモードは「考える」と「行う」を分ける。強いモデルが変更を計画し、速いモデルがその計画を実行する。判断が要る所は品質、要らない所は速さ、費用は課題の難しさに比例したまま。

どのモデルでも、百を超える言語

どの提供元もひいきしない。商用のモデルも、自分の機械で動く手元のモデルも繋げられ、後者ならコードは機械の外へ出ない。手入れをしている人たちの推薦には、名ではなく値打ちで選んだ組み合わせも入っている。当たり前であるべき立場だが、実際には珍しい。

言語の覆いは百を超え、よくあるスクリプト言語や仕組みの言語から、ウェブの裏側や古い企業の仕組みで使われるものまで届く。検査と試験も同じ輪の中にある。道具が自分でリンターと試験の一式を走らせ、見つけた問題を直してから仕事を戻す。望みを声に出して書かせることさえできる。作り話に聞こえるのは、三度目に使うまでのことだ。

自分自身で作られている

疑う人を納得させる細部は、開発の進め方にある。作者はこの道具を使って自分自身のおよそ八十八パーセントを書いた。履歴には三千を超えるコミットが、共著者としてこの道具を指す行を添えている。これほど自分自身に使われる道具の品質の主張は、どんな基準でも太刀打ちできない。疑う人は履歴を読めばよい。

作品はゆるい許諾で完全に公開され、本身は何も請求しない。払うのは実際に呼んだモデルの分だけ。閲覧画面の中にしか存在しないモデルの場合にも対応し、その形の取り決めにかつて必要だった複写と貼り付けを省く。

だれに向くか

もともと端末に住んでいて、編集ソフトへの切り替えを煩わしく思う開発者が最も多くを得るが、引きはもっと広い。Aider が差し出しているのは働き方だ。どの試みも記録され、どの誤りも戻せ、モデルは横の会話窓ではなく保管庫の参加者になる。場所が少し変わるだけにしては、意外に大きな違いである。