AIは私たちを2020年のアーキテクチャに閉じ込めるのか？

AIコーディングアシスタントを使うたびに、同じことに気づきます。それはSpringに非常に精通しているということです。アノテーション、プロファイル、@Autowired、そしてビーンがビーンに配線されるコールスタック駆動のダンス全体です。AIはこれを20年間見てきました。プロファイル固有のビーンが実行時にどのように選択されるかを推測しなければならない場合でも、うまく予測します。これは、まさにそのパターンの例を何千も見てきたからです。

これは、新しいアーキテクチャに取り組む人にとって厄介な疑問を提起します。AIが2020年代のパターンにこれほど流暢であるなら、業界全体がそのパターンにロックされたままになるのでしょうか？AIは保守的な力として、新しいアイデアがどれだけ優れていても、ソフトウェアアーキテクチャをトレーニングデータの重心に向かって静かに引き戻すのでしょうか？

私は自分のプロジェクトをテストケースとして、それを確かめたいと思いました。

賭け：明示的なインデックスは暗黙的なインデックスに勝る

OfficeFloorバージョン4は、AI時代に真に興味深いと思う機能を追加しました。RESTエンドポイントをYAMLファイルで定義でき、既存のSpring Bootコードと一緒に配置し、ディレクトリ構造がURL構造に従います。ファイルgreeting.POST.ymlはPOST /greetingを定義します。ファイルgreeting/{name}.GET.ymlはGET /greeting/{name}を定義します。そのファイル内で、リクエストを処理する小さな関数を構成します。

各関数は、これまでと同様にSpringによって依存性注入を受け取ります。OfficeFloorはSpringのDI、永続化、セキュリティ、アクチュエータのセットアップを置き換えません。変更されるのはフローです。典型的な@RestControllerでは、検証、ビジネスロジック、監査が実行される順序は暗黙的です。それはコールスタック（if文やどのメソッドがどのメソッドを呼び出すか）に存在します。それを理解するにはコードを読む必要があります。変更するにはさらにコードを読む必要があります。なぜなら、配線はデータとしてどこにも書き留められておらず、制御フローにコンパイルされているからです。

OfficeFloor YAMLバージョンでは、その配線はファイルそのものです。条件分岐、順序、エラーフロー：それらは宣言され、隠されていません。チェーン内のどの関数も他の関数を知りません。クラス内から関係を記述するアノテーションはありません。YAMLは、エンドポイントがどのように動作するかの完全で読みやすい仕様であり、ディレクトリツリー内のエンドポイント自身のURLパスの隣にあります。

これは本質的に関数注入であり、依存性注入が数十年前に行ったのと同じ動きですが、一段階上です。DIは「何に依存しているか」を命令型コンストラクタコードから取り出し、明示的で設定可能な第一級の関心事にしました。関数注入は「次に何が起こるか」を暗黙的なコールスタックから取り出し、それも明示的で設定可能にします。これは私が何年も書いてきた「結合制御の反転」アイデアの続きです。依存性注入は結合問題の一部しか解決していませんでした。制御フローの結合は常に存在していましたが、見えなかっただけです。

コードを読む人間にとって、これは洗剤のように感じられるかもしれません。おそらく後退でさえあるでしょう。これこそが、業界が最初にアノテーションをコードの隣に置くことを選んだ理由です。開発者は配線を実装の近くに置き、別の記述子ファイルには置きたくなかったのです。その好みは、人間が主要な読者でありナビゲーションを行う場合に意味がありました。

しかしAIアシスタントは上から下まで読む人間ではありません。AIアシスタントは、正確で外科的な変更を行うために必要な最小限のコンテキストを見つけようとしています。それは検索とナビゲーションの問題であり、スタイルの問題ではありません。エンドポイントの実行パス内のすべての関数を順序付きで、明示的な条件分岐とともに名前付けるYAMLファイルは、検索インデックスです。AIは、そのエンドポイントに関連するすべてを見つけたと確信するために、コードベースの残りを読む必要はありません。1つの小さなファイルを開けば、そのURLの動作契約全体がそこにあります。

少なくとも理論上はそうです。それが、ほとんど別の方法でのみ訓練されたモデルに対して実際に有効かどうかを知りたかったのです。

実験：Spring PetClinic RESTの変換

これを実際にテストするために、おもちゃの例ではなく、Springコミュニティが長年使用してきたPetClinicサンプルアプリの長年のリファレンスREST実装であるSpring PetClinic RESTを採用し、AIと協力してそのエンドポイントをOfficeFloor REST YAMLアプローチに変換しました。

最初の試行では成功しませんでした。クリーンな変換を得るまでに約5回の反復が必要でした。ボトルネックはOfficeFloorのランタイムでも、AIのコーディング能力でもありませんでした。ドキュメントでした。各試行でチュートリアルのギャップが明らかになりました。私にとって自明だったために暗黙のままにしていた前提、YAMLスキーマの可能性が詳述されていない箇所、Spring @RestControllerスタイルの動作をマッピングする方法のエッジケースなどです。AIの混乱をシグナルとして使用しました。AIが間違って推測したり、間違った質問をした場所こそ、チュートリアルに別の段落、別の例、別の明示的なルールが必要な場所でした。5ラウンドの「AIが行き詰まり、チュートリアルを修正し、再試行」を経て、変換は問題なく完了しました。

最終的な動作変換を録画しました。こちらでご覧いただけます：