Как AI меняет профессию
DevOps и SRE в 2026 году:грейды, навыки, инструменты и будущее

Главное из интервью

• AI не уничтожает DevOps — он сдвигает ценность от написания кода и запоминания команд к пониманию концептов, архитектурному мышлению и бизнес-контексту.
• Kubernetes останется ключевой технологией на годы вперёд, потому что именно на нём будут запускаться инференсы AI-моделей и AI-агенты.
• Когнитивная нагрузка инженера не снижается, а растёт — скорость генерации кода опережает способность человека его валидировать.
• Грейды переживают инфляцию: то, что раньше делал мидл, теперь делает AI за минуты, а от людей ждут архитектурного мышления на каждом уровне.
• Значение теоретических сертификаций растёт, а практические экзамены обесцениваются — потому что AI решает практический экзамен по Kubernetes за 10 минут на 100%.

В DevOps технологически мало что поменялось (не считая AI)

Если вынести за скобки генеративный AI, технологический ландшафт DevOps за три года изменился не так уж сильно. Облака остаются. Kubernetes остаётся. Terraform остаётся. AI меняет не стек — он меняет то, как инженеры с этим стеком работают.

Главное изменение — не в инструментах, а в том, что роль DevOps расширяется. Раньше найти человека, который одновременно знает инфраструктуру и пишет хороший код, было почти невозможно — это были «уникумы и суперстары». Теперь AI берёт на себя написание кода, но читать его стало критически важно.

Мы превращаемся в оркестраторов взаимодействия с агентами

Виктор описывает конкретный сдвиг в своей повседневной работе как Solutions Architect. Раньше подготовка proof of concept для клиента требовала длительного расчёта. Теперь, с AI-инструментами, работа не упрощается — но ускоряется в разы.

Ключевой поворот: создавать стало легко, а вот валидировать — сложнее. Раньше важным hard skill было знать, как в Terraform сделать конкатенацию строк или работать с модулями. Теперь основной навык — прочитать и оценить. Потому что AI генерирует быстрее, чем человек успевает проверять.

Виктор настроил себе полноценную AI-экосистему: Deep Research, Fact Checker, подключения к Outlook, внутренней системе репортинга, Slack. Когда приходит клиент с задачей, AI собирает материалы, ищет предыдущие истории взаимодействия, подтягивает лучшие практики — всё в одном месте. Но решения принимает человек.

Фундаментальные знания не обесцениваются

Один из самых ярких примеров провала — кейс основателя одного крупного онлайн-сообщества для специалистов по работе с данными. Человек хорошо знает данные, но плохо знает Terraform. Решил сэкономить 5 долларов и задеплоить новый функционал в существующую инфраструктуру вместо создания отдельного окружения. AI предупреждал: не надо так делать, но человек его проигнорировал. Поскольку он не подключил старый Terraform state, инструмент решил, что ресурсов не существует, и удалил всю базу данных.

Этот кейс Виктор использует как аргумент в пользу harness — настроенного персонального окружения для работы с AI.

Важно не выбрать лучшую модель, а настроить своё окружение

Виктор использует термин harness — это персональная экосистема инженера для работы с AI.

Виктор — фанат CLI-инструментов: «Для меня, как человека, выросшего из терминала, Claude Code в CLI — это родное». CLI можно интегрировать в CI/CD-процесс, а IDE-based инструменты — нет.

Можно ли пускать AI в продакшн-инфраструктуру?

AI в режиме советчика — уже продакшн-ready. Виктор рассказывает, что крупные компании внедряют DevOps-агентов для диагностики инцидентов: вместо того чтобы в 2 часа ночи полусонным разбираться, где что сломалось, инженер получает предварительный анализ — «Вася вчера вкоммитил вот эту штуку, и теперь она на продакшене сломала нам всё».

Но человек остаётся финальным звеном для любых изменений. Причина не только в ограничениях моделей — человек хранит контекст, который не попадает ни в какие RAG-системы.

Профессия по грейдам: от джуна до хеда

Джуниоры: «Я бы подумал, стоит ли вам идти в IT»

Инфляция грейдов сильнее всего бьёт по джунам: если раньше джун мог за 6–9 месяцев обучения зайти в проект и приносить пользу, то теперь планка выше. AI закрывает рутинные задачи, которые раньше были точкой входа в профессию: написать простой Jenkins job, переложить файлы из точки А в точку Б и так далее.

Что делать джуну:

• Фокусироваться на концептах, а не синтаксисе — операционные системы, сети, контейнеризация, Kubernetes. Не запоминать команды и флаги, а понимать, как вещи работают и какие у них ограничения
• Использовать AI как парного программиста — он напишет код лучше вас, но вы должны разбираться, что и почему он делает. «Не принимать на чистую монету, что он сделал, а разбираться, почему так, а не иначе, что на самом деле лучше работает и какие есть риски»
• Доводить проекты до конца — не «один промпт сделал», а полноценные пет-проекты с пониманием, что под капотом, какие технологии выбраны и почему

Мидлы: больше системного дизайна, меньше хардкодинга

Мидлам (3–5 лет опыта) Виктор советует переходить от написания кода к проектированию систем. Читать книги по System Design Interview. Сдать сертификации — причём теоретические, а не практические (подробнее об этом ниже). И обязательно настроить свой harness.

Сеньоры: «Потратьте время, разберитесь, сделайте свой harness»

Совет для сеньоров Виктор формулирует прямо: если не освоите AI-инструменты, потеряете конкурентное преимущество на рынке.

Тех-лиды: оркестраторы людей и AI

Тех-лид превращается в «погонщика AI-агентов», но с расширенной ответственностью. Если раньше он ревьюил код, написанный людьми, то теперь ревьюит код, который люди сгенерировали через AI. Объём пул-реквестов растёт, а качество проверки должно оставаться высоким.

Хеды и руководители: ничего не меняется

Самая сложная работа — это работа с людьми. Поэтому для менеджеров ничего не поменяется.

Главная ошибка кандидатов на DevOps-позиции

Самая частая ошибка — сразу бросаться в решение. Не спрашивать — а зачем меня об этом просят?

Роль исполнителя уходит — AI отлично справляется с выполнением инструкций. Ценность человека в понимании, почему нужно делать именно так, а не иначе.

Hard skills: ключевые навыки DevOps в 2026

• Kubernetes. Без вариантов. На нём будут запускаться AI-агенты и инференсы моделей. В последних релизах Kubernetes появляются сэндбоксы для AI-агентов. Альтернатив нет
• Сети. Одна из самых сложных и недооценённых областей. Дизайн сетей, маршрутизация, протоколы (BGP, DNS, разница между UDP и TCP), понимание, чем Application Load Balancer отличается от Network Load Balancer. «На сетях строится весь интернет. Amazon падал в 2025 году — проблема была с DNS»
• Безопасность / DevSecOps. С ростом скорости разработки через AI растёт количество уязвимостей. Появляются новые векторы атак — prompt injection, jailbreak моделей. Плюс, если все генерируют код через одни и те же модели, у всех одинаковые проблемы в коде
• LLM Ops. Новое направление внутри DevOps — люди, которые понимают, как запускать и скейлить инференсы моделей в продакшене

Ренессанс теоретических сертификаций

Практические экзамены обесцениваются. Там нужно помнить команды и флаги — AI справляется с этим лучше человека.

А вот на теоретическом экзамене (например, AWS Solutions Architect) дают высокоуровневые сценарии, и нужно концептуально понимать, какие проблемы возникнут при выборе того или иного сервиса, какие ограничения у SQS против Kafka, когда выбрать ECS, а когда EKS. Это AI пока делает хуже.

Инструменты: что пробовать, что пропускать

• Claude Code — инструмент №1, который Виктор Ведмич рекомендует каждому DevOps-инженеру.
• MCP — переоценён. Сам Anthropic, по словам Ведмича, признал, что MCP был сделан на скорую руку. MCP нужен только для жёсткой авторизации к внешним ресурсам — база данных, закрытые API. Для всего остального — CLI + скиллы.

  Есть такой проект «Anything's a CLI». Всё запихнуть в CLI и через скилл рассказать, как с этим CLI работать. Поэтому MCP не нужен. MCP сейчас нужен только если нужно ходить куда-то с жёсткой авторизацией.

  — Виктор Ведмич
• Локальные модели — пока не для продакшн-разработки. Хороши для экспериментов и быстрых задач вроде summary сообщений из Slack. Но генерировать код через локальный Qwen «не стоит — вы расстроитесь и скажете, этот AI тупой как пробка». Для серьёзной работы — большие модели от Anthropic, OpenAI, или китайские (GLM, Minimax, Qwen).
• Бонус: книга «AI Engineering: Building Applications with Foundation Models» (Chip Huyen) — рекомендация Виктора Ведмича для тех, кто хочет разобраться в AI-инженерии.

Будущее DevOps — прогноз от Виктора Ведмича на 2029 год

• DevOps останется. Кто-то должен отвечать за продакшн, деплоить, хостить, запускать. Особенно в легаси-системах, куда контекстного окна модели может не хватить.
• Dev в DevOps станет реальным. Шутка про «YAML-программистов» закончится — нужно будет писать Python, JavaScript, что угодно для решения бизнес-задач.
• Код обесценится. Важными останутся только идея и контекст. Компании будут чаще делать внутренние решения вместо покупки универсальных продуктов, потому что разработка подешевеет кратно — вместо 100 разработчиков нужно будет 10 с подписками на AI.
• Количество IT-специалистов в мире (~27 млн) будет медленно снижаться. Виктор предполагает не обвал, а плавный тренд на снижение.

На вопрос «пошёл бы ты сам в DevOps с нуля в 2026?» Ведмич отвечает: да, но с фокусом на LLM Ops — инфраструктуру для запуска и масштабирования моделей. «Разбираться, как запускаются модели, как это скейлить, как делать своих агентов — я бы сместил фокус в такой LLM Ops + DevOps».

Где найти Виктора Ведмича