AIはインフラエンジニアを置き換えるのではなく、その仕事の層を一段ずつ食べていく
AI and Infrastructure Engineering
インフラエンジニアの視点から、AIが日々の業務をどう変えたかを振り返る。KubernetesがAnsibleを置き換えたように、AIはHelmチャートやTerraformモジュールの生成を担い、エンジニアはその上の層、すなわち「方向性を決める」作業に集中できるようになった。しかし、基礎スキルの衰えという代償もあり、AIが最終的にその層まで侵食する可能性についても言及する。
Kubernetesはインフラエンジニアを置き換えなかった。それは彼らの仕事の層を置き換え、彼らを一段上に押し上げた。AIもエンジニアリングを置き換えるとは思わない。それはまだ「方向性を与える」層のすぐ下を食べているところだと思う。
HNでの議論
40- frio
> 正直なトレードオフ
> それは仮説上のコストではない - それは
> しかし、それはまさにその
これらはAIが書いた記事であることを強く示す兆候です。みんなが「これはAIだ」と言うのに疲れているのは分かっています。それは記事の内容について議論することを妨げるからです。しかし、AIについての記事が（どうやら）AIによって書かれ、AIの美徳を称賛しているというのは、私にとっては議論を前進させているようには思えません。
- cassianoleal
> 4年前、私はネストされたforループを手書きしました - 4レベル深く、別のAWSアカウントのリージョンとアベイラビリティゾーンにまたがってサブネットにタグを付けました - そして構文を正しくするのに約1時間かかりました
私はこの種のエンジニアにはAIが必要だと本当に思います。また、彼らと同じチームで働かなくて済むことを願っています。経験を積むと、ローカル変数でこの種のデータをいじるのではなく、コードベースの他の部分に変更を加えることを学びます。それは非常にトラブルシューティングが難しく、非常に壊れやすく、読み返して理解するのが悪夢です。
- anon7000
KubernetesでLLMを扱った私の経験と一致します。彼らはボイラープレートのyamlを書くのが素晴らしく、kubectlを使ってクラスタを監視・デバッグするのも素晴らしいです（もちろんガードレールと読み取り専用権限を設定して）。ステージング/テストクラスタがあれば、変更を適用させることもできれば、非常に速いフィードバックループを得られます。これは、高度に構造化され、文書化され、意見が明確なフレームワークがLLMの性能を引き出す良い例です。構造が多ければ多いほど、主観的な問題が発生する余地が少なくなります。
- skinfaxi
> KubernetesはAnsibleを殺したのでしょうか？まあ、そうかもしれません。私は何年もAnsibleプレイブックを書いていません - 今すぐ渡されたら、モジュールの構文を初めて見たかのように睨みつけるでしょう - 設定管理が重要でなくなったからではなく、Kubernetesがサーバー管理を簡単にしたので、自分でノードイメージを構築するのをやめて、クラウドプロバイダーが提供するもの、つまりAWS AMIをそのまま使うようになったからです。そして、ノードにSSHしてデバッグしたのはいつが最後でしょうか？
K8sがAnsibleを殺したのは、簡単さのためではありません。Ansibleが時代遅れになったのは、マシンを作って変更するというアプローチから、望む変更を加えた状態でインスタンス化するというアプローチに移行したからです。Ansibleはサーバーをその場で継続的に更新する場合に意味がありますが、変更があったときに新しい設定で新しいユニットを起動する場合には、明らかに役立ちません。この場合でも、基盤となるスキルは同じままです。
- thelastgallon
これは、彼が基盤となるレイヤーで数十年の実務経験を持ち、各抽象化レイヤーが何を解決するのか、そして抽象化間の相互作用を理解しているからです。筋肉記憶にないため、最下層のトラブルシューティングは最速ではないかもしれませんが、それでも推論できます。AIは、必要な経験（時間がかかる）を持っていれば生産性を向上させることができます。
しかし、AIネイティブは、AIを使用する最上位レイヤーでさえ、どのレイヤーの知識も持っていません。彼らはプロンプトの方法などを学ぶだけで、何が行われているかについては何も学びません。これは、飛行機がほとんど自動操縦であるため、誰でもパイロットになれるのと同じです。