Jules の最も鋭い批評家かつ最も貴重なパートナーのご紹介

Jules のような AI コーディング エージェントは、ユーザーが他の業務に集中している間に、コードを構築、リファクタリング、スキャフォールディングできます。その利便性と使いやすさは魅力的ですが、軽微なバグ、エッジケースの見落とし、未テストの前提条件が含まれる可能性があります。そのため、Jules では、コードを表示する前にレビューと批評を行う新しい機能を導入します。

批評家拡張生成

その役割はシンプルかつ高機能です。Jules がビルド中に、批評家機能が異議を唱えます。提案されたすべての変更は、完了前に敵対的レビューを受けます。批評家機能を Jules のピアレビュアーと考えてください。コード品質の原則に精通しており、不必要な作業を行っている場合は恐れることなく指摘します。

その批評は、批評家拡張生成と呼ばれるコード生成プロセスに直接統合されます。この最初のバージョンでは、1 回の処理で最終出力を評価するワンショット プロセスです。今後のマイルストーンでは、ツール呼び出しを使用したり、サブタスクの後や計画を立てる前にトリガーできる、真のマルチステップ エージェントを目指していますが、今のところは完成した生成を一度にレビューします。マルチステップ調査機能を活用し、批評家機能が外部ツール（コード インタープリタや検索エンジンなど）を使用して出力を検証し、それらの結果から学びます。

批評家機能とは

批評家機能はコードを修正することはありません。フラグを立て、改善のために Jules に返します。次に例を示します。

• すべてのテストを通過しているものの、軽微なロジックエラーが発生するパッチ: 「出力は想定されるケースと一致するが、未知の入力に対しては失敗する」

• コンパイルされたが、必須フィールドが通知なしに削除されている変更: 「関数のシグネチャが更新されたが、すべてのパラメータが処理されていない」

• 動作するが非効率的なアプローチを使用するコード: 「アルゴリズムは正しい結果を生成するが、無駄な O(n²) の複雑さを伴う」

これはパッチ生成後、送信前に行われるため（引き続きフラグ付けされている場合は複数回発生する可能性があります）、Jules はリアルタイムで再計画できます。Google の目標は、PR の削減、テスト カバレッジの向上、セキュリティの強化です。

リンターやテストとの違い

リンターは、狭い固定のルールに従います。テストは、特定のアサーションを検証します。批評家機能は、コードの背後にある意図とコンテキストを理解します。これは、ゴールド スタンダードの実装を必要とせずに正確性と堅牢性を判断する、参照フリーの評価方法に近いものです。

また、モデルが他のモデルの作業の品質と正確性を評価する LLM-as-a-judge の研究からもヒントを得ています。この種の自動判断は、生成と緊密に統合され、レビューをライブ フィードバック ループに変換する場合に特に役立ちます。

仕組み

1: Jules にプロンプトを入力してタスクを開始します。

2: 批評家機能は、候補パッチとその説明を 1 回の処理でレビューし、全体的な判断を下します。

3: Jules は完了する前にフィードバックに対処します。その後、批評家機能は更新されたパッチを再度確認し、さらなる問題がなくなるまで必要と思われるものにフラグを立て続けることができます。

4: ユーザーが、すでに内部でレビューされたコードを受け取ります。

これは、「アクター」が生成し、「批評家」が評価する actor-critic 強化学習（RL）を取り入れています。RL では、このループは学習シグナルに基づいてアクターと批評家を更新します。使用している LLM-as-critic セットアップも、パターンは似ており、提案してから評価します。しかし、学習パラメータを更新する代わりに、フィードバックは現在の状態と次のステップに影響を与えます。この同じ原則は、批評家の評価が再トレーニングなしに品質を導くという LLM-as-a-judge の研究の基盤となっています。

重要である理由

迅速なイテレーションの世界で、批評家機能はレビューをプロセスの早い段階に移動させ、生成の一環として組み込みます。つまり、ユーザーがレビューするコードは、すでに調査、調整、ストレステストが行われていることになります。もちろん常に、生成されたコードは使用する前に慎重に確認する必要があります。

優れたデベロッパーはコードを書くだけでなく、そのコードを疑問視します。Jules も同様のことができるようになったのです。