自動プログラミングは、特定のユースケースにおいて、使い手さえ選べば、ソフトウェアの記述を劇的に高速化する。私の経験では、その出力は最高の手書きコードが持つ構造的な品質や複雑さの抑制には及ばない。とはいえ、すべてのソフトウェアが卓越しているわけではない。適切に管理すれば、自動プログラミングは多くの場合、そこそこに書かれた手書きのコードの品質を上回るというのが私の実感だ。

とはいえ、AIで新しいソフトウェアを書く場合、品質と時間の間にはトレードオフが存在する。私が手がけたある種のプロジェクトでは、このトレードオフは苛烈なものになり得る。つまり、本来なら何ヶ月もかかるプロジェクトが数週間で完了してしまうのだ。一方で、LLMが品質を一切犠牲にすることなく、プロセスを自動化するための純粋により強力な手段を切り開く領域もある。その一つが、ソフトウェアのQAとテストだ。

従来、ソフトウェアは、局所的なスコープのテストと統合テストからなるテストスイートを使ってテストされてきた（Redisを例に考えてみてほしい。SET foo 10に対してGET foo => 10が返るかをテストすることと、そのケースでレプリケーションが正しく動くかをテストすることは別物だ）。さらに、通常は手作業で実行されるQAパスによって、実行可能なテストスイートの抜け穴を補ってきた。コードのすべての行をカバーしたからといって、起こりうるすべての状態をカバーしたことにはならないのは周知の事実だ。さらに、統合テストは構造的に難しい。タイミングの問題やセットアップの違い、目視でしか確認できない品質面の出力といった要素があり、時間的・ロジスティクス的な制約から、多くのテスト機会が十分に活かされないままになっている。

LLMは、既存のテスト手法に上乗せする形で、QAを行う新たな方法を提供してくれる。発想は、AIエージェントにQAエンジニアとして新リリースの手動テストを多数実行させるためのMarkdownファイルを用意するというものだ。たとえば、DwarfStar（オープンウェイトLLM向けの推論エンジン）のケースでは、私は次のようなアプローチをとっている。Markdownファイルの中で、エージェントに対して、すでにリリース済みのバージョンの上に積み重なった新たなコミットが何であるかを確認するよう指示する。その上で、モデルに実行すべきことのリストを伝える。例えば次のようなものだ。

• MacBook AとMacBook Bの間で分散推論が正しく動作することを確認する。出力に一貫性があること、両方のマシンにあるすべてのGGUFファイルで推論が動作することなどを確認する……
• 今回のリリースで速度のリグレッションが発生していないことを確認する。

といった具合だ。特筆すべきは、速度のリグレッションの確認では、以前の期待速度がどれくらいだったかをエージェントに教える必要がないことだ。それはリリースや最適化のたびに変わる流動的な目標だからだ。同様に、分散推論の統合テストについても、細かい指示は必要ない。ファイルの冒頭にSSHエンドポイントや使用するキー、パスなどを書いておくだけでよい。

エージェントには、長いQA項目のリストを、*とりわけ*追加されたコミットを踏まえてチェックするよう求める。まず変更内容を精査し、影響を受けそうな箇所を特定することから始め、QAパスが特定のリグレッションを狙って絞り込まれるようにするのだ。

Redis Arraysのケースでは、同様の手法を用い、エージェントに大規模な配列ベースのRedisアプリケーションを構築させ、レプリケーションと永続化を備えた本番環境をセットアップさせ、数日間にわたって多数のユーザーによる利用をシミュレートさせ、何か異常がないかをチェックさせた。

こうしたアプローチによるテストは、ソフトウェア品質のより心理的な側面にも踏み込むことができる。ユーザー視点から見て驚きを与えたり、ドキュメントが不足していたり、総じて雑な印象を与える新機能をすべて洗い出すようエージェントに求めるのだ。これらは以前はすべて手作業で実行する必要があり、ほとんどの場合、ほぼスキップされていたことだ。

自動QAの導入によって、ソフトウェアの新リリースにおける品質の水準が引き上げられ、ひいては自動プログラミングによって高速に生成されたコードの品質低下を、ある程度相殺してくれるのではないかと感じている。