AIとインフラストラクチャエンジニアリング

はじめに現在、企業全体でAIを全面的に採用しようという動きがあります。あらゆるコンテキストをAIに投入し、各リポジトリにAGENTS.mdやINSTRUCTIONS.mdを作成して、人間だけでなくエージェントでもプロジェクトを発見・貢献できるようにしようとしています。少し面白いのは、これまでチームメイトにREADMEを読んでもらったことすらないのに、今ではロボット向けに、かつてないほど質の高いドキュメントを書いていることです。これに伴う疑問は、当然ながら「エンジニアリングは不要になるのか？」ということです。スタックとそのインフラストラクチャに関するすべてのコンテキストが、エージェントが読める形でどこかに書き込まれたら、次は我々の番なのでしょうか？私はそれが正しい問い方だとは思いません。なぜなら、私たちはすでにそのバージョンの経験を生き抜いてきたからです。 以前にも経験済みKubernetesはAnsibleを廃止したのでしょうか？ある意味ではそうです。私は何年もAnsibleプレイブックを書いたことがありません。もし今、プレイブックを渡されても、設定管理が重要でなくなったのではなく、Kubernetesがサーバー管理を非常に容易にしたため、ノードイメージを自分で構築することをやめてしまったからです。AWSが提供するAMIをそのまま使い、何も疑問に思わなくなりました。そして、デバッグのためにノードにSSHしたのはいつ以来でしょうか？ほとんどありません。ノードに問題があれば、それを削除して、交換されたノードが同じ問題を抱えていないことを願います。その上のレイヤーも同様でした。ECS Fargate、Lambda、またはCloudflare Containersでコンテナを実行すると、どのノードに着地したかは本当に知らず、気にもしません。しかし、それは誰もそれをオーケストレーションしていないという意味ではありません。ワークロードをコンテナにすること、実行するイメージ、通信の許可範囲、スケーリング方法、失敗時の対応などを決定したのは、依然として私です。Kubernetesやサーバーレスコンテナは、その意思決定レイヤーをなくしたのではなく、作業単位を「マシン」から「ワークロード」へと引き上げ、その下のレイヤーはすべて静かに自動化されました。 Kubernetes、Fargate、またはCloudflareのコンテナプラットフォームがインフラストラクチャエンジニアを置き換えたと言う人はいないでしょう。それぞれが特定のレイヤーの手作業を置き換えました。カスタムイメージの構築、サーバーの手動パッチ適用、ワークロードがどのノードに着地したかを知ることなどです。そしてエンジニアは毎回、その上のレイヤーへと移動しました。AIもまた、レイヤーを一つ上に移動させて、同じことをしているのだと思います。 日々の変化私は毎日Claudeを使用してHelmチャートを生成し、Terraformモジュールを記述しています。それが私の日常から実際に削除されたのは、思考ではなく、検索作業です。もはやAWSプロバイダーの変更履歴を読んで、v5とv6の間に何が変わったかを調べることはありません。私が望むものを、どのような形状のモジュールやチャートにしたいかを記述すれば、Claudeがそのバージョンを生成してくれます。私が実際に本番に適用できる形にするには反復が必要ですが、一度その形になれば、特にリポジトリにAGENTS.mdがあれば、それが次回の例となります。 しばらく前に、その下のレイヤーでも同じことが起こりました。私は生のKubernetes YAMLを手書きするのではなく、Ansibleモジュールを手書きするのと同じように、Helmチャートを使用しています。さらに、Helmチャートさえも手書きしなくなっています。それが何をすべきかを指示し、Claudeがそれを記述します。 変わらないもの私は依然として、良いTerraformモジュールや適切に構造化されたHelmチャートがどのようなものかを知る必要があります。本当に問題が発生し、ポッドを削除することが選択肢にない場合に、ノードにSSHできる必要があります。上のレイヤーは下のレイヤーをなくすのではなく、触れる頻度を移動させるだけです。そして、物事の実際の形状を決定するのは、依然として私です。モジュールの最終的なバージョンがどのようなものになるか、1年後に保守可能かどうか、チャートがどのようにデプロイされバージョン管理されるかなどです。AIは時間のかかる部分を行います。私は依然として指示を出します。 失うスキル正直なトレードオフ：私は2年前よりも物事を構築しデバッグするのが速くなりましたが、そのスピードの根底にある基本的なスキルは明らかに鈍っています。HCL構文の記憶力は以前ほどではありません。4年前に、ネストされたforループを手書きしました。4段階の深さで、別のAWSアカウントの複数のリージョンとアベイラビリティゾーンにサブネットをタグ付けしました。構文を正しくするのに約1時間かかりました。 hcl locals { subnet_tags = merge([ for account, regions in var.accounts : merge([ for region, azs in regions : merge([ for az, subnets in azs : { for subnet_id, tags in subnets : "${account}/${region}/${az}/${subnet_id}" => tags } ]...) ]...) ]...) } サブネットのマップのマップのマップをフラット化するためだけに、4つのmerge呼び出しが積み重ねられています。Claudeは今、数秒で同等のものを記述します。もし今日、私がゼロからそれを生成するように頼まれたら、本当に座って考えなければならないでしょう。SSHで壊れたノードをデバッグするための私の反射神経は、それが唯一の方法だった頃よりも少し遅くなっています。それは仮説上のコストではなく、リアルタイムで起こっていると感じられるものです。Kubernetes以降にエンジニアリングを学んだ多くのエンジニアが、サーバーイメージを手作業でロールしたことを学ばなかったのと同じように、彼らはそれで問題ありませんでした。なぜなら、彼らはそれを必要としなかったからです。 今後の展開「私は依然として指示を出します」という部分が、どれだけ続くかについては、私はあまり確信が持てません。現在、スタックの長期的な形状を決定しているのは私です。なぜなら、私にはコンテキストがあり、エージェントにはないからです。少なくとも、リポジトリのAGENTS.mdに書き込まれている以上のコンテキストはありません。しかし、それはまさに、企業全体でのAI導入の動きが解決しようとしているギャップです。エージェントに、単一リポジトリだけでなく、全体のコンテキストを与えるのです。それが実際に機能すれば、インフラストラクチャ全体に対する真の長期的な視点を持つエージェント、つまり、このTerraformモジュールだけでなく、長年にわたるすべてのリポジトリでのすべての決定事項を把握したエージェントは、私がすべてのプロバイダーの変更履歴を読んだツールよりもデバッグできないのと同様に、私よりも優れた計画を立てるかもしれません。 Kubernetesはインフラストラクチャエンジニアを置き換えましたが、彼らの仕事の一部を置き換え、彼らを一つ上のレイヤーに移動させました。AIもエンジニアリングを置き換えるとは思いません。それはまだ「指示を出す」というレイヤーのすぐ下を食い尽くしている最中であり、それが最後に食い尽くされるレイヤーであるとは、私は完全には確信していません。 AI Kubernetes Terraform Helm Opinion