自動プログラミングは、特定のユースケースにおいて、使い手が適切であれば、ソフトウェア開発を劇的に高速化します。私の経験では、その出力は最高水準の手書きのコードが持つ構造的な品質や、複雑さを抑える巧みさには届きません。しかし、すべてのソフトウェアが卓越しているわけではありません。適切にマネジメントすれば、自動プログラミングの成果は多くの場合、平均的に丁寧に書かれた手書きのコードの品質を上回るというのが私の実感です。

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

従来、ソフトウェアのテストは、局所的なテストと結合テストからなるテストスイートによって行われてきました（Redisを例に考えてみてください。SET foo 10を実行した後にGET foo => 10が返るかを確かめることと、その状況でレプリケーションが正しく動くかを確かめることはまったく別の話です）。さらに、通常は手作業で実施されるQAパスがあり、実行可能なテストスイートでは拾いきれない抜け穴をカバーします。コードのすべての行をカバーしても、すべての状態をカバーしたことにはならないことはよく知られています。加えて、結合テストは構造的に困難です。タイミングの問題、環境のセットアップ、自動では判定できず目視でしか確認できない品質面の出力などが絡み、時間や運用上の制約から、多くのテスト機会が十分に活かされないままになっています。

LLMは、既存のテスト手法に加えて、QAを行うための新しい方法を提供してくれます。発想はシンプルで、AIエージェントにQAエンジニアとして新リリースの手動テストを一通り実行させるためのMarkdownファイルを用意するというものです。たとえば、DwarfStar（オープンウェイトLLM向けの推論エンジン）の場合、私は次のような手法を使っています。Markdownファイルの中で、エージェントに対して、すでにリリース済みのバージョンから積み重なった新規コミットをまず確認するように指示します。そのうえで、実施すべき項目のリストを渡します。たとえば次のようなものです。

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

といった具合です。特筆すべきは、速度のリグレッション確認において、以前の期待速度をエージェントに逐一教える必要がない点です。期待値はリリースや最適化のたびに変わる流動的なものだからです。同様に、分散推論の結合テストについても、細かい指示は必要ありません。ファイルの冒頭にSSHの接続先や使用するキー、パスなどを書いておくだけで済みます。

エージェントには、追加されたコミットを踏まえて、とりわけその観点からQA項目の長いリストをチェックするように求めます。まず変更内容を精査し、どこに影響が及びうるかを特定することから始め、そのうえで特定のリグレッションを見つけ出すことに特化したQAパスを実行するのです。

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

こうしたアプローチによるテストは、ソフトウェア品質のより心理的な側面にまで踏み込むこともできます。エージェントに対して、ユーザーの視点から見て驚きを与えるような新機能や、ドキュメントが不足している箇所、全体的に作りが雑に感じられる部分を洗い出すように頼むのです。これらは従来、すべて手作業で行う必要があり、しかもほとんどの場合、ほぼスキップされてきた事柄です。

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