AI 会取代基础设施工程师吗？
AI and Infrastructure Engineering
现在许多公司都在推行全员 AI 化，要求在每个仓库中编写 AGENTS.md 以便 Agent 能理解项目上下文。这让我想起当年 Kubernetes 取代 Ansible 时的场景：它没有消灭基础设施工程师，而是将工作单元从“机器”提升到了“工作负载”，将底层的重复劳动自动化。如今，AI 正在做同样的事，它帮我快速生成 Helm charts 和 Terraform 模块，省去了查阅文档和编写基础语法的时间。但我依然需要决定架构的最终形态、处理 SSH 调试等深层问题。代价是，我对 HCL 等底层语法的记忆正在生疏，就像新一代工程师不再手写服务器镜像一样。AI 正在吞噬“执行”这一层，但“决策”是否也会随之消失？
Kubernetes 并没有取代基础设施工程师，它只是替换了他们工作中的一层，并将他们向上提升了一层。
HN 评论区
38- frio
> 诚实的权衡
> 这不是一个假设性的成本——它是
> 但这正是
这些都是 AI 撰写文章的明显迹象。我知道大家都厌倦了人们说“这是 AI 写的”，因为这无助于讨论文章本身的内容，但关于 AI 的文章，（看起来！）由 AI 撰写，又在吹捧 AI 的好处——在我看来，这并不能真正推动讨论向前发展。
- cassianoleal
> 四年前，我手写了一个嵌套四层深的 for 循环，在另一个 AWS 账户中跨区域和可用区标记子网——光是把语法写对就花了我大约一个小时
我确实认为这类工程师需要 AI。我也希望不要和他们在同一个团队工作。经验会让你学会在代码库的其他部分进行修改，而不是像这样对局部变量进行数据摆弄——这极其难以排查故障，而且非常脆弱——更不用说读起来和理解起来简直是噩梦。
- anon7000
这与我使用 LLM 处理 Kubernetes 的经验相符。它们在编写样板 yaml 方面非常出色，在使用 kubectl 监控和调试集群方面也表现极佳（当然，前提是设置了护栏和只读权限）。如果你有一个 staging/test 集群，如果你允许它应用更改，你可以获得极快的反馈循环。
这是一个很好的例子，说明高度结构化、文档完善、观点明确的框架如何帮助 LLM 表现出色。当周围有更多结构时，主观问题的空间就变小了。
- skinfaxi
> Kubernetes 杀死 Ansible 了吗？某种程度上是的。我已经好几年没写过 Ansible playbook 了——如果你现在给我一份，我会眯着眼看模块语法，就像我从未见过一样——这并不是因为配置管理不再重要，而是因为 Kubernetes 让服务器管理变得足够简单，以至于我们完全停止构建自己的节点镜像了——我们直接使用云提供商提供的内容，一个为我们构建的 AWS AMI，不问任何问题。我上一次 SSH 进入节点调试问题是什么时候？
K8s 并没有因为易用性而杀死 Ansible。Ansible 之所以过时，是因为我们不再创建一台机器然后修改它，而是直接实例化一台带有我们所需更改的机器。当你持续更新一台现有机器的配置时，Ansible 是有意义的；而当你每次更改配置时都启动一个新单元时，它的用处就大大减少了。即使在这种情况下，底层技能仍然是相同的。
- purpleidea
对于大多数用户来说，Kubernetes 增加了复杂性和成本，但没有增加价值。我们越早意识到这一点，就越早开始思考事情应该如何构建。无论你是否拥有 LLM，都与此无关。LLM 会乐意地帮你更快地构建垃圾！
也许人们终于会意识到，他们需要开始重新思考基础设施自动化。我正在这么做。