ИИ не заменяет инженеров: как сокращение команд разработки раздувает облачные расходы

by Дэвид Линтикум

Как быстро уничтожить компанию
мнение
7 апр. 2026 г. 6 мин

Замените всех своих инженеров на ИИ, а затем наблюдайте, как неэффективный код приводит к астрономическим счетам за облако, и никто толком не понимает, почему код, который хорошо выглядел на бумаге, не работает в реальном мире.

shutterstock 449579803 cloud explosion white powder black background

Фото: Jag_cz / Shutterstock

Слишком многие руководители сокращают команды разработчиков программного обеспечения, потому что поверили в фантазию о том, что ИИ теперь может создавать и поддерживать корпоративные приложения, а людям нужно лишь немного присматривать за машиной. Это не смелая идея. Это не дальновидность. Это безрассудство, и все больше руководителей будут расплачиваться за свои ошибки не только плохим кварталом.

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

Как эта история разваливается

Приложения часто работают, и это делает такой подход обманчиво эффективным. Демонстрация проходит успешно, и поначалу кажется, что функция работает как надо. Все поздравляют друг друга. Но затем система запускается в масштабе, и счет за облако взлетает до небес. То, что раньше стоило 10 000 долларов в месяц в AWS, внезапно подскакивает до 300 000 долларов или больше. В худших случаях компании сталкиваются с многомиллионными ежемесячными облачными расходами за системы, которые вообще не следовало строить таким образом.

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

Затем появляется мой любимый плохой аргумент от лагеря ИИ-хайпа: «Просто оптимизируйте это потом». Ладно. Кем? Эти компании уволили экспертов, которые понимали сложные системы, оставив после себя сгенерированный ИИ код, который никто до конца не понимает. Оставшиеся люди его не создавали, не знают его структуру и не могут безопасно его менять. Они застряли с приложениями, которые можно запускать по заоблачной цене, но нельзя надежно поддерживать.

Это не инновация. Это технический долг, нанесенный себе самому в промышленных масштабах.

Обычно технический долг накапливается постепенно. Здесь поспешный релиз, там обходной путь, старый зависимый компонент, к которому никто не хочет прикасаться. Но с корпоративным ПО, созданным ИИ, компании за считаные месяцы создают годы технического долга. В худшем смысле это даже впечатляет. Они сжимают целые циклы провала, потому что ИИ позволяет им строить быстрее, чем они успевают думать.

И вот начинаются панические звонки. Почему приложение работает медленно? Почему пользователи жалуются? Почему сбои труднее диагностировать? Почему облачные расходы вышли из-под контроля? Почему никто не может это исправить, не вызвав сбой чего-то еще? Почему обещание кодинга с ИИ совсем не похоже на рекламные речи?

Знайте плюсы и минусы ИИ

Это не значит, что ИИ бесполезен — далеко не так. ИИ вполне может помочь командам разработчиков двигаться быстрее. Он может помочь с каркасом приложения, документацией, повторяющимися задачами кодирования, генерацией тестов и даже с архитектурным мозговым штурмом. В руках сильных инженерных команд это легитимный ускоритель. Но где-то по пути слишком многие руководители решили, что «ускоритель» означает «замена», и начались плохие решения.

Хорошие инженеры ценны не потому, что умеют печатать код в редакторе. Хорошие инженеры ценны потому, что понимают системы. Они понимают компромиссы. Они понимают, почему одно архитектурное решение создает будущие эксплуатационные проблемы, а другое их избегает. Они понимают, как ПО ведет себя после запуска, под нагрузкой, в разных регионах, в сложных средах безопасности и соответствия требованиям, а также поверх моделей ценообразования публичного облака, которые наказывают за неэффективность. ИИ этого не заменяет. Он имитирует лишь фрагменты этого.

Еще хуже то, что слишком многие компании поощряют краткосрочность. Рынку нравятся истории о сокращении затрат. Достаточно часто объявляйте о сокращениях или говорите об «ИИ-трансформации», и вы можете получить приятный временный рост акций. Руководители это знают. Они также знают, что если реальный ущерб проявится через три-четыре квартала, всегда можно свалить все на исполнение, рыночные условия или «непредвиденные сложности». Между тем инженерный фундамент компании разрушается изнутри.

Не становитесь той компанией, которая слишком поздно понимает, что загнала себя в угол ИИ. Старые системы, созданные людьми, все еще будут существовать, но люди, которые их понимали, уже уйдут. Новые системы, созданные ИИ, дороги, хрупки и непрозрачны. Перестройка будет стоить целое состояние. Перенайм талантов будет сложным. Некоторые сотрудники не вернутся, и я бы их не осуждал.

Я уже говорил это раньше, и это по-прежнему верно: ИИ пока и близко не заменяет инженеров-программистов в обещанном масштабе. Даже рядом не стоит. Руководители, которые думают иначе, — не смелые, а легковерные. Хуже того, они рискуют своими компаниями ради маркетинговых историй, которые продвигают люди, зарабатывающие на преувеличении будущего.

В ближайшие несколько лет я ожидаю несколько непростых кейсов. Некоторые компании тихо сменят курс. Другие потратят много денег на исправление проблем. А некоторые могут закрыться совсем, потому что совершили фатальную управленческую ошибку: поверили в хайп, уволили людей, которые знали, что делают, и передали управление системами тем, кто на самом деле не мог ими управлять.

Если компании хотят избежать такого исхода, ответ прост. Сохраняйте своих инженеров, используйте ИИ для усиления их возможностей и назначайте опытных архитекторов, чтобы они руководили, обеспечивали контроль, сдерживали расходы и гарантировали сопровождаемость. Рассматривайте ИИ как инструмент, а не как замену человеческого суждения.

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

Искусственный интеллектИТ-стратегияИТ-лидерствоНовые технологииТехнологическая отрасль


David Linthicum

by
Дэвид Линтикум

  1. Подписаться на Дэвида Линтикума в X

Дэвид С. Линтикум — всемирно признанный отраслевой эксперт и мыслитель-лидер. Дэйв написал 13 книг о вычислительной технике, последняя из которых — An Insider’s Guide to Cloud Computing. Его опыт в отрасли включает должности CTO и CEO в нескольких успешных софтверных компаниях, а также руководящие позиции в компаниях из списка Fortune 100. Он выступает с основными докладами на ведущих технологических конференциях по облачным вычислениям, SOA, интеграции корпоративных приложений и корпоративной архитектуре. Дэйв ведет блог Cloud Insider для InfoWorld. Его взгляды являются его собственными.

Еще от этого автора

Покажите мне больше

feature

Начните работу с новым типом frozendict в Python

By Serdar YegulalpApr 8, 20265 mins
Языки программированияPythonРазработка ПО
Image

opinion

Проблема масштабирования Terraform: когда инфраструктура как код превращается в инфраструктуру как сложность

By Neel ShahApr 7, 202614 mins
Управление облакомИнструменты разработкиDevops
Image

news

Приобретение SchedMD компанией Nvidia ставит под пристальное внимание планирование ИИ в open source

By Gyana SwainApr 7, 20265 mins
Искусственный интеллектOpen SourceРазработка ПО
Image

video

Новый тип frozendict в Python

Apr 2, 20264 mins
Python
Image

video

Как повысить производительность приложения с помощью ленивого импорта в Python 3.15

Mar 31, 20266 mins
Python
Image

video

Как запустить свой собственный маленький локальный Claude Code (ну, вроде того!)

Mar 26, 20267 mins
Python
Image


Материал — перевод статьи с английского.

Оригинал: How to destroy a company quickly