Enzyme からの移行は 2 週間で完了しました。本来は 5 年かかるはずでした。

最近、AI を使って、数年にわたるエンジニアリング作業を 1 スプリント程度で完了させました。 その方法と、それがなぜ可能性についての考え方を変えたのかをご紹介します。

5 年間の問題

2022年、Asana はフロントエンドのテストスイートを、古くなったテストライブラリの Enzyme から React Testing Library (RTL) に移行する作業を開始しました。 Enzyme はコミュニティのサポートを失い、React の新しいバージョンとの互換性も低下していました。また、ユーザーが実際に見たり操作したりするものではなく、実装の詳細に密接に結びついたテストが推奨されていました。 RTL によって、私たちはより良いモデルに向かうことができました。つまり、内部ではなく、動作をテストすることです。

移行は数年間にわたって着実に進められました。 複数のエンジニアが数年間にわたって取り組むプロジェクトがいくつか設けられ、 製品チームは、それぞれの担当分野で少しずつ作業を進めていきました。 これらの作業はすべて重要なものでした。 しかし、そのペースでは、完了までにまだ約5 年かかることが予想されました。

そこで、意図的に非現実的な目標を設定しました。1 週間で移行全体を完了できたらどうでしょうか。

そして、その目標に近づくことができました。 エンジニアリングに費やした時間は約 1 週間半でした。 Enzyme は現在、コードベースから完全に削除されています。

実際の経過

アプローチは恥ずかしいほどシンプルでした。 OpenAI の Codex と超高度推論の最先端モデルを使用し、一度に最大 4 つのエージェントを実行し、それぞれを異なるディレクトリに向けました。 マシンをスリープ状態にしないようにし、エージェントを昼夜問わず実行させ、毎朝と毎晩チェックして進捗をレビューし、プルリクエストをオープンにしました。

プロンプト全文は次のとおりです。

/目標リポジトリを Enzyme テストから React Testing Library スタイルのテストに移行したい。 コードベースの既存のルールとベストプラクティスに従ってください。 /directory内の Enzyme を使用するすべてのファイルを、React Testing Library を使用するように移行してください。 [test command]で変更内容をテストしてください。 一般的に、変換が簡単なファイルを最初に移行するようにしてください。

5 文。 それだけです。

また、より洗練された設定も試しました。作業を追跡可能なチケットに分割したり、エージェントに進行中のメモファイルを保持させたり、サブエージェントを生成してさらに並列化させたり、RTLの規則に関するはるかに詳細なプロンプトを作成したりしました。 ほとんどすべてが状況を悪化させました。 シンプルさが勝ちました。

5 文のプロンプトで十分だった理由

これが最も重要な部分です。これは、OpenAI が最近「Harness engineering」で述べたのと同じ考え方です。エージェントのアウトプットの質は、与えられた環境の質に大きく依存するということです。

私たちのコードベースには、RTLを採用するという当初の決定、よく設計されたテストヘルパー、明確な規則、参考にできる実際の例など、長年にわたる優れたセンスがすでに組み込まれていました。 モデルには、私たちがそれらを説明する必要はありませんでした。すでにそこにあり、読み取ることができたのです。 私たちは目標を提供するだけで、エージェントに実行させました。

タスク自体も、これが機能するための適切な形をしていました。明確で検証可能な「完了」の定義 (Enzyme は不要)、そしてタイプチェック、lint、テスト、CI など、ミスを即座に検出できる高速なフィードバックループ。 優れたハーネス、明確に定義された問題、最小限の手引き。

障害となったもの

問題のほとんどはモデルのせいではなく、私たちのせいでした。

• 最近作成された社内文書やエージェント向けガイダンスの中には、依然として Enzyme を推奨パターンとして示すものがあり、エージェントを誤った方向に積極的に誘導していました。 古いドキュメントは、もはや単なる些細な迷惑ではなく、それを読むすべてのエージェントにとって誤解を招くトレーニング資料です。

• 低速で不安定なツール (時には 10 分以上かかる lint ステップ、CI とローカルチェックの不一致) が、最も介入が必要な部分であることがわかりました。 ボトルネックは、エージェントであることはほとんどなく、当社のインフラストラクチャが原因でした。

ハーネスが製品になった

このプロジェクトから得られたより明確な教訓の 1 つは、AI はエンジニアリングのセンスの必要性を排除するのではなく、それを増幅させるということです。 コードベースにクリーンな例と明確なルールがあれば、クリーンで整ったアウトプットが生まれます。 不自然なパターンもコピーされました。 ドキュメントについても同じことが言えます。古いガイダンスは、人間だけが読んでいたときにはまったく問題にならなかったものが、今では負担になっています。

希望を与えてくれる反対側の見方は、この現象が逆方向にも作用するということです。 良い例が広がります。 明確なドキュメントはエージェントを正しく誘導します。 コードを取り巻くドキュメント、ルール、フィードバックループといった「ハーネス」に投資することは、今回の移行だけでなく、今後のすべての移行で利益をもたらします。

次のステップ

私たちは、これが Asana にとって何を意味するかについて楽観的です。しかし、不安を感じる人もいることも理解しています。エンジニアのアイデンティティの多くは、手作業でコードを書くことに結びついているからです。 私の希望は、これにより、私たちが技術に対する関心を失うのではなく、むしろ高めることができ、長期にわたる移行、書き換え、パフォーマンスの問題など、常に何年もかかるものと静かに想定してきたバックログに対して、より野心的になれることです。

こうした問題のすべてが、数年から 1 週間に短縮されるわけではありません。 しかし、そうなるものもあるでしょう。 ここで問うべきは、「AI を使っているか？」という単純な質問ではありません。 「週末にエージェントにこの作業を指示し、月曜日には結果を確認したことがあるか？」ということです。

興味のある方のために、さらにいくつかの詳細をご紹介します。

• 移行全体の作業時間は約 1 週間半で、2 カレンダー週間にわたって行われました。

• モデルの使用コストは約 11,000 ドル、インフラにはさらに 1,000 ドルかかりました。

• その 12,000 ドルを大局的に捉えるために (簡単な計算): この作業は最終的に、当初のフレームワーク移行そのものを超えたメリットをもたらしました。 また、プロジェクト期間中にテストカバレッジの改善、不十分なテストの修正、レガシーテストインフラストラクチャのクリーンアップも行いました。 その全範囲を手作業で完了するには、フル稼働のエンジニアリング工数でおよそ 600 万ドルかかっていたと推定されます。

• その過程で、いくつかの思いがけない成果も得られました。たとえば、Enzyme 以前のさらに古いテストフレームワークがコードベースの一部にまだ残っていることを忘れていたのですが、それをクリーンアップすることができました。

このブログ記事は、Asana と OpenAI の継続的なコラボレーションおよびパートナーシップの一環として、Codex がより大規模で野心的なエンジニアリング作業にどのように取り組めるかを探るものです。