Некоторые статьи пишутся легко. Про Kubernetes, про GitOps, про очередного «убийцу Docker» - сел, налил кофе, открыл терминал, понеслось. А некоторые статьи пишутся с нервным смешком человека, который видел слишком многое...

Эта заметка - из второй категории.

В 2025-2026 году в ИТ появился новый тип руководителя.

Раньше был «Excel-директор». Человек, который сводил всю реальность к зелёным и красным ячейкам. Потом был «Agile-директор», который пытался лечить архитектурные проблемы ежедневными стендапами и наклейками на стенах.

Теперь появился новый подвид.

«LLM-директор».

Человек, который открыл DeepSeek или ChatGPT, пару раз написал «Как масштабировать платформу?» и внезапно решил, что теперь понимает инфраструктуру, разработку, безопасность, базы данных, DevOps, SRE и вообще всё устройство современной ИТ-компании.

И вот здесь начинается самое интересное.

Главная проблема ИИ в управлении

Сама по себе идея использовать ИИ для помощи руководителю - абсолютно нормальная.

Проблема не в модели. Проблема в том, что большинство стратегических вопросов невозможно нормально сформулировать без огромного количества контекста.

И это прекрасно описывает мысль:

«Нехватка контекста и внутренние противоречия в постановке задачи не останавливают модель - она замещает их допущениями, которые явно не озвучивает.»

Это фундаментальная проблема всех больших языковых моделей.

Если инженер задаёт вопрос:

  • какая у нас нагрузка?
  • какой SLA?
  • какие ограничения сети?
  • какой бюджет?
  • какая задержка между датацентрами?
  • как устроен CI/CD?
  • сколько команд?
  • где узкое место?

…то ИИ может помочь.

Но когда ТОП пишет:

«Как нам оптимизировать инфраструктуру и сократить расходы?»

Модель начинает фантазировать. Потому что у неё нет:

  • реальной архитектуры,
  • цифр,
  • бизнес-контекста,
  • понимания процессов,
  • политических ограничений,
  • технического долга,
  • знаний о людях.

Но модель обязана ответить. И она отвечает уверенно.

Вот это особенно опасно!

ИИ не говорит «я не знаю»

Большая языковая модель устроена так, чтобы выглядеть убедительно.

Она не сидит и не думает:

«Хм, у меня мало данных».

Она статистически продолжает текст. И если вопрос сформулирован плохо - ответ получается красивым, структурированным и абсолютно оторванным от реальности.

Опытный инженер это видит сразу. ТОП-менеджер без технического бэкграунда - нет.

И тут начинается магия корпоративного цирка.

Кейс №1. «Давайте перепишем всё на микросервисы»

Классика последних лет.

Компания с:

  • 10 разработчиками,
  • одной базой данных,
  • двумя виртуалками,
  • монолитом,
  • 30 RPS нагрузки.

ТОП идёт в ИИ и спрашивает:

«Как нам стать технологичнее?»

ИИ отвечает:

  • микросервисы,
  • Kubernetes,
  • event-driven architecture,
  • service mesh,
  • Kafka,
  • multi-region,
  • zero trust.

Через неделю начинается архитектурный комитет.

Через месяц:

  • 17 сервисов,
  • 3 DevOps,
  • 2 SRE,
  • вечные проблемы с сетью,
  • latency,
  • distributed tracing,
  • и разработчики, которые раньше релизили по кнопке, а теперь чинят YAML до двух ночи.

При этом исходная проблема была:

  • отсутствие тестов,
  • плохой CI,
  • один PostgreSQL без репликации с не оптимизированными индексами.

Но это же слишком скучно.

А «давайте внедрим service mesh» - звучит солидно.

Кейс №2. «DeepSeek сказал, что PostgreSQL не масштабируется»

Это уже реальная история из индустрии. Руководитель приносит инженерам распечатку ответа ИИ:

«PostgreSQL плохо подходит для высоконагруженных систем.»

После чего начинается:

  • обсуждение Cassandra,
  • MongoDB,
  • TiDB,
  • CockroachDB,
  • Yugabyte,
  • распределённых транзакций,
  • и прочего инфраструктурного шаманства.

Хотя у компании:

  • 500 RPS,
  • половина запросов без индексов,
  • N+1 запросы,
  • ORM - адище в коде,
  • и SELECT * FROM table без LIMIT.

PostgreSQL там вообще страдает последним.

Но ИИ сказал. А значит - надо делать «современную архитектуру».

Кейс №3. «Мы будем экономить на инженерах»

Это вообще отдельный жанр.

ТОП читает:

«ИИ заменит программистов.»

После чего:

  • замораживает найм,
  • увольняет синьоров,
  • нанимает джунов,
  • заставляет всех «использовать AI-first подход».

Через полгода:

  • кодовая база превращается в кладбище копипасты,
  • никто не понимает архитектуру,
  • production падает от race condition,
  • CI ломается от сгенерированных bash-скриптов и пайплайнов,
  • Kubernetes-манифесты выглядят как древние шумерские проклятия.

Потому что ИИ отлично помогает инженеру. Но не заменяет инженера.

Это как экскаватор. Он усиливает строителя. Но если человек не понимает, как строить дом - экскаватор не спасёт. Он просто быстрее выкопает яму. Скорее - для бизнеса.

Самый страшный тип руководителя

Есть категория людей, которые:

  • ничего не понимают в разработке,
  • ничего не понимают в инфраструктуре,
  • ничего не понимают в архитектуре,
  • но получили инструмент, который пишет уверенным тоном.

И теперь им кажется, что они тоже всё понимают.

Это смертельно опасная комбинация. Потому что настоящий специалист обычно сомневается. А вот дилетант с ИИ - наоборот. Он становится ещё увереннее.

История с собеседованиями и DeepSeek

На одной из моих прошлых работ был замдиректора департамента.

Человек из тех, кто:

  • всегда говорит уверенно,
  • любит умные слова,
  • обожает «стратегическое видение»,
  • его любит руководство за «кручение фонариков» и прекрасные сказки о будущем,
  • смотрит на тебя и врет глядя в глаза,

Но при этом в инфраструктуре и разработке не понимает примерно ничего.

Вообще. Ноль.

Если дать ему SSH-доступ - есть риск, что он случайно удалит production, пытаясь выйти из vim.

Но зато у него появился DeepSeek. И это был катализатор катастрофы. Он начал ходить на технические собеседования. Общаться с инженерами. Наваливать лютого кринжа.

Сидит такой красивый с ноутбуком на собесе. Кандидат отвечает на вопрос.

А этот персонаж параллельно пишет вопрос в DeepSeek и сравнивает ответы. Причём буквально.

Не:

  • понимает ли кандидат тему,
  • умеет ли рассуждать,
  • знает ли ограничения,
  • видел ли production.

Нет. Он реально сравнивал текст.

Если кандидат говорил иначе, чем DeepSeek - значит кандидат «плавает».

Это выглядело настолько абсурдно, что иногда хотелось проверить, не скрытая ли это съёмка какого-то ИТ-шоу. Особенно смешно было на сложных инфраструктурных вопросах.

Например:

  • отказоустойчивость PostgreSQL,
  • quorum в etcd,
  • split-brain,
  • Kubernetes scheduler,
  • сетевые политики,
  • latency между зонами доступности.

Опытный инженер отвечает:

  • с нюансами,
  • с оговорками,
  • с зависимостями,
  • с реальными кейсами.

Потому что реальный production - грязный и сложный.

А DeepSeek выдаёт:

  • красивую,
  • гладкую,
  • усреднённую,
  • учебниковую формулировку.

И этот «великий технический мыслитель» выбирал вариант DeepSeek.

Потому что:

«Ну ИИ же так сказал».

В какой-то момент инженеры и разрабы уже начали специально троллить ситуацию и, чуть ли не делать ставки - на какой минуте будет очередной гениальный вопрос.

Можно было почти дословно предсказать:

  • какие фразы выдаст модель,
  • какие «архитектурные инсайты» через неделю появятся на встрече,
  • и какие модные слова будут вставлены в очередную презентацию.

Самое страшное - такие люди реально принимают решения!

Почему это происходит

Потому что ИИ даёт очень опасную иллюзию компетентности. Особенно управленцам.

Раньше, чтобы изображать техническую экспертизу, нужно было хотя бы:

  • читать книги,
  • ходить на конференции,
  • разговаривать с инженерами,
  • годами накапливать опыт.

Теперь достаточно открыть вкладку браузера или запустить приложеньку на мобильном телефоне.

И получить:

  • уверенный тон,
  • красивые списки,
  • структурированные ответы,
  • модные термины.

Для неподготовленного человека это выглядит как экспертность. Хотя часто это просто статистически правдоподобный текст.

Ирония всей ситуации

Самое смешное - хорошие инженеры тоже активно используют ИИ.

Очень активно. Но совсем иначе.

Инженер использует ИИ:

  • как помощника,
  • как поисковик нового поколения,
  • как ускоритель рутины,
  • как второе мнение,
  • как генератор идей.

Но не как оракула.

Опытный инфраструктурщик никогда не возьмёт production-решение из ответа модели без проверки.

Потому что любой инженер хотя бы раз видел:

  • несуществующие параметры Kubernetes,
  • выдуманные флаги systemd,
  • нерабочие Helm values,
  • фейковые Terraform ресурсы,
  • или советы уровня: «Просто отключите SSL для повышения производительности».

ИИ - это усилитель. А не источник истины.

Самая опасная фраза 2026 года

Вот эта:

«Я посоветовался с ИИ.»

Особенно если после неё идёт:

  • увольнение команды,
  • смена архитектуры,
  • миграция баз данных,
  • отказ от специалистов,
  • или «давайте всё перепишем».

Потому что ИИ не отвечает за последствия. Отвечать потом будут инженеры. Как обычно. В пятницу ночью. Под алерты Grafana. С кружкой остывшего кофе.

И с директором, который будет спрашивать:

«А почему production лежит? DeepSeek же сказал, что так будет лучше…»