AI-инженер: почему ИИ не заменит инфраструктурных инженеров, а поднимет их на уровень выше
AI and Infrastructure Engineering
Инженер из omegion.dev рассуждает о влиянии ИИ на инфраструктурную инженерию. Он сравнивает нынешний переход с тем, как Kubernetes заменил ручное управление серверами, но не самих инженеров. Автор признает, что Claude теперь генерирует Helm-чарты и Terraform-модули, а он сам стал менее искусен в ручном написании кода. Однако он утверждает, что ключевые решения по-прежнему остаются за человеком. В конце он задается вопросом, как долго это продлится, если агенты получат полный контекст всей инфраструктуры.
Я не думаю, что ИИ заменит инженерию — я думаю, он все еще занят поеданием слоя чуть ниже «давать направление», и я не до конца уверен, что это последний слой, который он съест.
- frio
> Честный компромисс
> Это не гипотетическая цена — это
> Но именно это и есть
Это явные признаки статьи, написанной ИИ. Я знаю, что все устали от людей, которые говорят "это ИИ", так как это вредно для обсуждения содержания статьи, но статьи об ИИ, (по-видимому!) написанные ИИ, восхваляющие достоинства ИИ — тоже, честно говоря, не способствуют продвижению дискуссии.
- cassianoleal
> Четыре года назад я вручную написал вложенный цикл for — четыре уровня глубиной, размечая подсети в разных регионах и зонах доступности в другом AWS-аккаунте — и у меня ушло около часа, чтобы добиться правильного синтаксиса.
Я действительно верю, что такому инженеру нужен ИИ. Я также надеюсь, что мне не придется работать с ними в одной команде. Опыт учит тебя вносить изменения в другие части кодовой базы, а не заниматься такой обработкой данных на локальных переменных, которую невероятно сложно отлаживать и которая очень хрупкая — не говоря уже о том, что это кошмар для чтения и понимания.
- anon7000
Это совпадает с моим опытом работы с LLM на Kubernetes. Они отлично пишут шаблонный YAML и фантастически используют kubectl для мониторинга и отладки кластеров (конечно, с ограничениями прав и режимом только для чтения). Если у вас есть стендовый/тестовый кластер, вы можете получить очень быстрый цикл обратной связи, если позволите ему также применять изменения.
Это хороший пример того, как высокоструктурированные, хорошо документированные, с четкими правилами фреймворки помогают LLM хорошо работать. Просто меньше места для субъективных проблем, когда вокруг больше структуры.
- skinfaxi
> Убил ли Kubernetes Ansible? Вроде да. Я не писал плейбуки Ansible годами — если бы вы дали мне его прямо сейчас, я бы щурился на синтаксис модулей, как будто никогда его не видел — не потому, что управление конфигурацией перестало иметь значение, а потому, что Kubernetes сделал управление серверами настолько простым, что мы вообще перестали создавать собственные образы узлов — мы просто используем то, что дает облачный провайдер, AMI AWS, созданный для нас, без вопросов. И когда я в последний раз заходил по SSH на узел, чтобы что-то отладить?
K8s убил Ansible не из-за простоты. Ansible устарел, потому что мы перешли от создания машины и ее изменения к созданию экземпляра с нужными изменениями. Ansible имеет смысл, когда вы постоянно обновляете сервер на месте, и становится определенно менее полезным, когда вы поднимаете новый экземпляр с новой конфигурацией при каждом изменении. Даже в этом случае базовые навыки остаются теми же.
- purpleidea
Для большинства пользователей Kubernetes добавил сложность и стоимость, но не ценность. Чем скорее мы это осознаем, тем скорее начнем думать о том, как все должно быть построено. Наличие LLM не имеет к этому никакого отношения. LLM с радостью поможет вам строить вашу ерунду еще быстрее!
Может быть, люди наконец поймут, что им нужно переосмыслить автоматизацию инфраструктуры. Я уже переосмысливаю.