ショウジョウバエに自分のコードをレビューさせてみた - Nick Nisi, WorkOS

하이라이트

• オスのキイロショウジョウバエの実際の脳神経系であるコネクトームには、17万6,000個のニューロン間に630万個の接続と1億2,500万個以上のシナプスが存在する。

• JEVを用いたシステム1モデルがコードの差分から30の質問を生成し、それをショウジョウバエの脳の神経網における匂いや味覚の記憶に変換してコードレビューの判定を行っている。

• ショウジョウバエの脳を用いたコードの評価実験では、最初の例となる変更をリクエストすべきケースを96%の確率で正しく捉えていた。

• ショウジョウバエの脳は、非常に起こりそうなミスについても98%の確率で正しく変更をリクエストしていた。

• コードレビューにおける人間の役割は、単に承認ボタンを押すことではなく、提案された変更がなぜ自分たちにとって重要であるのかというコンテキストを理解し直すことへ変化している。

타임라인

1. 00:00 - 03:36

   ソフトウェア開発におけるボトルネックとコードレビューの変容

   ソフトウェアエンジニアリングにおいて開発速度が飛躍的に向上した結果、コードレビューや承認を行う人間がプロセス全体の足かせになっている。CIや自動解析ツールが十分に機能している現在、単にコードの妥当性を機械的にチェックするだけではなく、変更の理由やコンテキストを人間側にいかに戻すかが重要になっている。歴史的なバグの由来にちなみ、本物の昆虫の神経系をコードレビューに応用する試みが紹介される。

   • コードがかつてないスピードで書かれプルリクエストが急増する一方で、開発者自身が最大のボトルネックになっている。
   • GreptileやCodeRabbitなどのエージェントやCIが導入されたことで、本番環境を壊さないかの確認におけるコードを見る重要性は低下している。
   • ソフトウェアのバグという言葉は、1947年にリレーの中で見つかった実際のガの虫から名付けられた。
   • ソフトウェアのバグを見つけるために、本物のハエを用いた実験が行われている。
2. 03:36 - 08:15

   ショウジョウバエの脳によるコードレビューの仕組み

   キイロショウジョウバエの脳全体の神経回路を高精度に再現したコネクトームをデジタル上に構築し、それをコードレビューに利用するシステムが構築された。コードの差分をAIモデルが匂いデータへと変換し、ハエが過去に学習した良いコードと悪いコードの記憶と照らし合わせて反応を引き起こす。ハエの脳の記憶や神経回路そのものが処理を行っており、記憶を削除すると正常に動作しなくなることが確認されている。

   • オスのキイロショウジョウバエの脳スキャンに基づくコネクトームには、17万6,000個のニューロンと630万個の接続が含まれている。
   • JEVを用いたモデルがコードを偏りのない30の質問に変換し、それをハエの記憶における良いコードの砂糖水の匂いや悪いコードの苦い匂いとして伝達する。
   • テストでバグが発生すると苦い報酬のドーパミンが分泌され、良いコードの場合は甘い報酬のドーパミンが分泌されて神経の結びつきが変化する。
   • ハエの脳から得られる指標は、舌が出てくるか引っ込むかという反応によって判定される。
3. 08:15 - 12:44

   ハエのレビュー精度の検証と人間による判断

   実際のプルリクエストを用いたデモや会場での参加型テストを通じて、ショウジョウバエの脳がどれほどの精度でコードを評価できるかが示された。人間は全体を通じて高い正答率を誇るものの、ハエも約88%から高い場合には96%以上の確率で問題のあるコードやリスクを正確に検知している。言語や仕様を直接理解しているわけではないが、神経回路と味覚・嗅覚の仕組みを用いた判定は十分な実用性を備えていることが示される。

   • 会場の参加者とショウジョウバエの脳によるコード変更の承認テストが実施された。
   • ショウジョウバエの脳は、テストにおいて最初のケースで96%の確率で変更をリクエストすべきケースを捉えていた。
   • 非常に起こりそうなミスに対しても、98%の確率で正しく変更をリクエストしていた。
   • ハエはJavaScriptやコードの意味を直接理解しているわけではなく、変な匂いがするという感覚に基づいて判定を下している。
4. 12:44 - 16:31

   人間をループから外すためのエスカレーション戦略

   人間の開発者がすべてのプルリクエストを細かくレビューする負担を減らすため、チームごとの基準やスキル、軽量な分類器、自動コードレビュアーを組み合わせた自動化パイプラインが解説される。問題のない変更は自動で処理し、リスクのある変更や人間の判断が不可欠な場合のみ人間にエスカレーションする仕組みを構築することで、ソフトウェアのリリース速度を大幅に向上させることが可能になる。チームごとに異なる期待値や要件に応じた柔軟な運用が提案されている。

   • 人間のレビューを本当に必要なものだけに限定するため、チームレビュー・スキルや分類器を活用したパイプラインが提案されている。
   • チームの基準を満たした上で自動レビュアーを通過したプルリクエストは、他の人間をわずらわせずに自動でマージできる。
   • 問題が発生した場合はシステムを監査し、チームレビュー・スキルや自動レビュアーを修正して次回の検知に活かすことができる。
   • コード自体への関心が薄れるにつれ、エージェントが検証を行ったことを示すスクリーンショットやテスト結果などの証明が必要になる。