AI 時代の Internal Development Platform における抽象度のコントロール

ko-da-k.icon

AI が来る前、kubernetes や ECS みたいなところに Machine Learning Engineer や Data Scientist がオンラインサービングモデルや WebAPI をセルフサービスでホスティングするような基盤を作っていた。

当時考えていたことは、「どのようにインフラの実装詳細を隠蔽し、利用者のユーザビリティやニーズに対する拡張性を持つ DSL を定義するか」だった。（DSL といっても、いわゆる yaml 書くだけで OK みたいなやつの yaml schema どう組み立てるかという話が多かった。もしくは k8s の Custom Controller どう作るかとか)

例えば、トラフィックルーティングの仕組みを Istio で実現していたときに、Istio の設定をそのままユーザーに書かせることはできないのである程度の抽象化したレイヤーを提供する必要があった。

この抽象化レイヤーを複数のインフラ層にトランスパイルすることで、実装詳細をユーザー影響なく自由に切り替えるみたいなこともできていたので当時は満足していた。

しかし、今の時代は Agentic Coding が主流である。

Agentic Coding の場合、オレオレ DSL みたいなものはコンテキストとして持ち合わせていないので明示する必要がある。しかし、実装詳細を露出させると、AI はある程度の知識を持った状態であることから、自然言語から直接 kubernetes manifests や terraform 等のコードを直接書かせるほうが今の時代の Internal Development Platform としては親和性が高いのではないか。

AI に書かせる前提なら、kubernetes manifests も istio の設定も terraform も思いっきり露出させる方向の舵切りをして、Platform Engineer はそこのガードレールと自動レビュー、自動テストを徹底的に作り込むのが個人的に筋の良い方向なのではないかと思う

また、別の技術詳細に切り替えるような作業も AI の得意とするところであり、マイグレーション計画や並行稼働の設計さえちゃんとしておけば、オレオレ DSL みたいなものが必要になることがほぼないのが現状。

もう、Machine Learning Engineer や Data Scientist が Terraform も kubernetes も自然言語を経由して作れる時代になっている。一昔前の抽象度で IDP を作るとむしろ使いづらいものになっていきそうなので価値観を改めたい