ソフトウェアの成長が、私たちの理解を追い越すとき

コーディングエージェントに仕事を頼みます。しばらくすると、機能が動き、テストも通っています。差分は数十のファイルに及び、新しい構造が導入され、明示的には頼んでいなかった問題もいくつか修正されています。

結果はよさそうです。何度か試しても目立った問題は見つからないので、次の仕事に進みます。

それでも、答えの出ていない問いが残ります。なぜこの実装なのでしょうか。どの振る舞いが自分の要件から生まれ、どの振る舞いがエージェントの選択によるものなのでしょうか。次にシステムのこの部分を変えるとき、何を守る必要があるのでしょうか。

ソフトウェアは前に進みました。自分の理解は、始めたときのままです。

1. ソフトウェアが変わっても、理解を保つには

ソフトウェアはコードや動作中のプロセスとして存在しますが、それを形作る人々の理解の中にも存在します。何のためにあるのか。なぜこのように動くのか。どの選択は守る必要があり、どの選択は変えられるのか。その理解があるからこそ、私たちは時間をかけてソフトウェアを形作り続けられます。

すべての実装の詳細を理解する必要はありません。個々の関数を知らなくても、ソフトウェアをどういうものにしたいかを把握し、変更が自分の意図に沿っているかを判断し、沿っていなければ介入することはできます。

従来の開発でも、複雑さやチームの人員交代によって、理解と実装が離れてしまうことはあります。一方で、設計、コーディング、デバッグ、修正は、作業を進めながら理解を築き、正す機会を何度も与えてくれます。

コーディングエージェントは、その速度を変えます。以前なら私たち自身の関与が必要だった多くの手順を飛ばし、大規模な実装を自力で作れます。ソフトウェアは変わり続けます。私たちの理解が、それに合わせて変わるとは限りません。

機能が先に完成し、理解は後から取り組む仕事になります。変更を読み、理由を尋ね、ほかに何に影響するかを調べる。コーディングで節約した時間の一部は、こうした仕事に使われます。エージェントは生成を続けられ、私たちが理解しなければならないことも積み上がっていきます。

さらに難しい変化もあります。ソフトウェアが頼んだとおりに進んでいても、自分にとってなじみのないものになっていくのです。一日中、仕事を割り振り、質問に答え、結果を確認します。どのエージェントも前進していますが、それらの変更がどう組み合わさるのかは、自分で整理しなければなりません。自分の手で作ることで育つ感覚——今どこまでできていて、次にどう変えればよいかという把握——は、仕事が終わっただけでは自然に得られません。

自分の作品が、次第になじみのないものになっていきます。何を頼んだかは覚えていても、なぜ結果が今の形になっているのか、以前の決定は今も守られているのか、次の変更は何に影響するのかを説明するのが難しくなります。何を作り、なぜそう動き、どう変えればよいかを理解し続ける、その連続性が途切れ始めます。作品を形作り続けることも難しくなります。

2. AIが優秀になっても、決める権利は消えない

自然な対応の一つは、モデルをもっと信頼できるものにすることです。よりよいコードを書き、エラーをよりよく見つけ、検証をより徹底する。モデルが十分に優秀になったら、人はなお、自分の作品をどういうものにするかを理解し、決める必要があるのでしょうか。

自分の作品の方向を決める権利は、AIが間違いを犯し続けることを前提にはしていません。

「コードはAIが書けても、アーキテクチャは人が設計しなければならない」。この答えは、今のところ私たちが優位に立つ能力に、人の役割を結びつけています。モデルがアーキテクチャの設計にも優れるようになったら、どうでしょうか。検証やシステムの理解に役割を移しても、同じ問いに行き着きます。モデルがそれにも優れるようになったら、人は関与する理由を失うのでしょうか。

この議論を極限まで進めてみます。AIが汎用人工知能に達したとしましょう。複雑なシステムを理解し、優れた技術上の選択をし、私たちよりも徹底して実装を確かめられます。そのとき、私たちが作るものについて、すべての決定を委ねるべきなのでしょうか。

自分の意図に沿って作り、自分の作品の方向を選びたい人がいる限り、この問いは残ります。

よりよい決定ができるというだけで、他人の代わりに決める権利が生まれるわけではありません。

多くの判断をAIに委ねつつ、ある決定は自分の手元に残しておくこともできます。助言を受け入れ、考えを変え、以前の選択が間違っていたと認めることもできます。大事なのは、理解したうえで選ぶことです。ソフトウェアがすでに変わったことを、後から知るだけではありません。

自分の作品の方向を決める権利は、AIより能力が高いことに左右されません。その権利を行使したい人が、まだ何人いるかにも左右されません。ほとんどの人がすべてを委ねることに満足していても、そうではない人には、自分のソフトウェアをどういうものにするかを決める権利があります。

自分の作品の作者であり続けたい人が一人でもいる限り、その人の意図をどうすれば有効なまま保てるのか、私たちは答えを見つける必要があります。

3. ソフトウェアを形作り続けるために必要なこと

最初のアイデアが動くソフトウェアになった後も、作者としての関わりは続きます。重要な選択を理解し、方向を変え、自分の意図に反する結果を拒み、作品を修正し続けられる必要があります。その方向を決める権利は、実際にできることに結びついていなければなりません。

エージェントが仕事を終えたとき、結果にどんな重要な選択が含まれているかも知らずに「承認」をクリックすることしかできないなら、主導権は限られています。結果を拒否できても変える方法が見つからない場合や、昨日明示した要件が今日の実装ではいつの間にか守られなくなっている場合も同じです。仕事を承認し続けていても、自分の意図に沿って形作る力を失いつつあるかもしれません。

その力を保つには、次のような具体的な問いに答えられる必要があります。

ソフトウェアをどういうものにしたいかは、今も明確ですか。
今の実装が、自分の要件にどう応えているかを確認できますか。
自分の重要な決定と、エージェントが行った選択を区別できますか。
方向を変えるとき、どのような影響がありそうかを理解し、介入できますか。
次に実装が変わった後も、自分が明示的に下した決定は守られますか。

個人用の執筆ツールを考えてみましょう。内容を端末内に保存する、という明確な要件があります。ファイルの整理方法、保存の実装、多くの内部的な詳細はエージェントに任せます。その後、複数の端末で使いやすくするために、エージェントがクラウド同期を提案します。

内容を端末の外に出してよいかどうかは、すでに自分が下した決定に関わります。その選択が見えるようになっていて、それによって何が変わるのかを理解できてこそ、受け入れるか拒むかを決められます。結果がより便利で、より信頼できるものになっていても、元の要件からは外れているかもしれません。

テストは、ソフトウェアが特定の振る舞いをすることを確かめる助けになります。それでも、その振る舞いを受け入れられるか、守りたい決定に沿っているかは、自分で判断する必要があります。

エージェントは同期を実装し、データが正しく転送されることを確認し、バグを直せます。けれども、内容を端末の外に出すべきか、どんな根拠があればその変更を受け入れられるか、問題が起きたら誰が責任を負うかは、実装そのものとは別に、明確な答えが必要です。自分の判断が、仕事の進む先と止まる時点を決められなければなりません。すべてが終わった後の署名にとどまっていてはならないのです。

4. コードをすべて読めば、作者であり続けられるのか

コードレビューは、直接的な答えを示します。エージェントがコードを書き、人が読んで、何をするのかを確認します。

コードには、モデルの報告では触れられない振る舞い、保守に影響する構造、実装を詳しく調べなければ判断できない問題が含まれていることがあります。

しかし生成が速くなるにつれて、すべての変更を読む方法で、主導権を持ち続けることはできるのでしょうか。

一行ずつ読まなくても、一日の仕事は埋まってしまうことがあります。曖昧な要件を明確にし、結果がどこで意図からずれたかを見つけ、何を根拠に正しさを確認するかを決め、エージェントを軌道に戻す。どの段階にも経験と集中力が求められます。ほとんどコードを読んでいないのに、一日中気を張って働いている。その両方は同時に起こり得ます。

コードを読むことは、理解を築く機会でもあります。同僚の変更をレビューすることで、チームは、システムが今何をするのか、なぜそう設計されたのか、今後の変更で何に気をつけるべきかを学べます。読むコードが減るなら、その理解を育てる別の方法が必要です。

とはいえ、変更が積み上がり、承認前にざっと目を通すことしかできない状況では、レビューの手順を残しても、理解が保たれるとは限りません。限られた注意力は、判断が必要なところに向けなければなりません。重要な設計上のトレードオフ、影響の大きい変更、まだ不確かな結果です。

どの選択を、継続して理解しておく必要があるのでしょうか。どの実装の詳細は、必要になったときに調べればよいのでしょうか。細部に注意力を使い果たし、実際に自分の判断が必要な決定を見落とすことを、どうすれば避けられるでしょうか。

5. コードを長い仕様書に置き換えたらどうか

別の答えは、私たちの仕事を自然言語に移すことです。ソフトウェアがどう振る舞うべきかを記述し、エージェントにその仕様を実装してもらいます。あるいは、エージェントにコードの説明を頼み、システムを読みやすいドキュメントに変換します。

明確な要件は誤解を減らします。ドキュメントは背景を残します。よい説明は、なじみのないコードを理解しやすくします。しかし自然言語にすれば、読むコストが消えるわけではありません。

ソフトウェアに多くの振る舞いやトレードオフが含まれていれば、それらをすべて記述する文書も、実装とともに膨らんでいくかもしれません。読みきれないほどのコードから、読みきれないほどの文章へと移ることもあります。一文一文は対応するコードより理解しやすくても、全体の量は、使える時間と注意力を超えてしまうことがあります。

しかも、エージェントが仕様を増やし続け、私たちは承認するだけなら、それを「人が承認した文書」と呼んでも、人がそこに含まれるすべての決定を理解したことにはなりません。

ソフトウェアが実際にすること、エージェントがそれをどう説明するか、そして私たちが本当に理解し、支持すると決めたことは、それぞれ別のものです。

完全な記録と詳しい説明があっても、ソフトウェアをどう形作り続ければよいかは、なおわからないことがあります。大事なことを見つけ、今の実装でそれがどう成り立っているかを理解し、次に変えるときにどんな選択肢があるかを確認できる必要があります。

作者としての主導権を、人の手に残す

実装のコストが下がることで、より多くの人がアイデアをソフトウェアにできます。その人たちは、作ったものを理解し、形作り続けることもできるべきです。

この自由は、ソフトウェアだけのものではありません。どんな創作でも、作る人が、何をAIに委ね、何を自分で決めるかを選べるべきです。

Finite Groundの使命は、AIによって可能性が広がるなかで、人が自分の意図に沿って作り、作品を形作り続けられるようにすることです。

Noemaはその使命をソフトウェアに具体化し、実装が変わり続けても、人の意図が有効であり続けるようにします。

いつかAGIが人間の生活のあらゆる部分を引き受け、すべての人が自律性を手放す日が来たなら、この問いは成り立たなくなります。Finite Groundにも、存在する理由がなくなります。

その自律性を手放したくない人が一人でもいる限り、続けていく理由があります。

AIは、より多くのアイデアを世に送り出せます。そのアイデアをどういうものにするかを決める権利は、手放さずにいることを選んだ人々のものです。