Как быстро уничтожить компанию
мнение
7 апр. 2026 г. 6 мин
Замените всех своих инженеров ИИ, а затем смотрите, как неэффективный код приводит к непомерным счетам за облако, и никто толком не понимает, почему код, который хорошо выглядел на бумаге, в реальности не работает.
Источник: Jag_cz / Shutterstock
Слишком многие руководители сокращают команды разработки ПО, потому что поверили в фантазию, что ИИ теперь может создавать и поддерживать корпоративные приложения, если рядом будет всего несколько людей, присматривающих за машиной. Эта идея не смела. Она не дальновидна. Она безрассудна, и всё больше руководителей будут страдать от последствий своих ошибок не только из-за плохого квартала.
Да, ИИ может писать код. Это очевидно. Проблема в том, что многие поставщики и лидеры взяли этот факт и раздулли его до абсурда: до идеи, что программная инженерия стала по сути необязательной. Они считают, что если модель может генерировать логику приложения, то опытные разработчики, архитекторы и инженеры по производительности внезапно стали ненужными расходами. Такое мышление может выглядеть умно в презентации для совета директоров, но в реальной эксплуатации оно рушится.
Как разваливается эта история
Приложения часто работают, и это делает такой подход обманчиво эффективным. Демонстрация проходит успешно, и сначала кажется, что функция работает как надо. Все друг друга поздравляют. Но затем систему разворачивают в масштабе, и счёт за облако взлетает. То, что раньше стоило 10 000 долларов в месяц в AWS, внезапно подскакивает до 300 000 долларов или больше. В худших случаях компании сталкиваются с многомиллионными ежемесячными облачными расходами на системы, которые вообще не следовало строить таким образом.
ИИ может генерировать код, но он не понимает эффективность так, как это понимают опытные инженеры. Он не расставляет приоритеты в пользу экономичной архитектуры. Он инстинктивно не избегает лишних вызовов сервисов, чрезмерного перемещения данных, плохого кэширования, неудачных паттернов конкурентности, шумного поведения базы данных или вычислительно тяжёлого бессмыслия, которое может хорошо смотреться в примере кода, но проваливается в реальном использовании. Он выдаёт нечто правдоподобное. Однако он не даёт чего-то финансово ответственного.
Затем следует мой любимый плохой аргумент от сторонников ИИ-ажиотажа: «Просто оптимизируйте это потом». Хорошо. С кем? Эти компании уволили экспертов, которые понимали сложные системы, оставив после себя код, сгенерированный ИИ, который никто полностью не понимает. Оставшиеся люди это не создавали, не знают его структуры и не могут безопасно его изменять. Они оказались в ловушке приложений, которые можно запускать по непомерной цене, но нельзя надёжно поддерживать.
Это не инновация. Это нанесённый себе технический долг промышленного масштаба.
Обычно технический долг накапливается постепенно. Здесь поспешный релиз, там обходной путь, старый зависимый компонент, к которому никто не хочет прикасаться. С корпоративным ПО, сгенерированным ИИ, компании создают годы технического долга за считанные месяцы. Это почти впечатляет, но в самом худшем смысле. Они сжимают целые циклы отказов, потому что ИИ позволяет им строить быстрее, чем они успевают думать.
И вот начинаются панические звонки. Почему приложение тормозит? Почему пользователи жалуются? Почему труднее диагностировать сбои? Почему облачные расходы вышли из-под контроля? Почему никто не может это исправить, не сломав что-то ещё? Почему обещание ИИ-кодинга совсем не похоже на рекламный рассказ?
Знайте плюсы и минусы ИИ
Это не значит, что ИИ бесполезен — далеко не так. ИИ вполне может помогать командам разработки двигаться быстрее. Он может помогать с заготовками, документацией, рутинными задачами программирования, генерацией тестов и даже с архитектурным мозговым штурмом. В руках сильных инженерных команд это законный ускоритель. Но где-то по пути слишком многие руководители решили, что «ускоритель» означает «замену», и начались плохие решения.
Хорошие инженеры ценны не потому, что могут вводить код в редактор. Хорошие инженеры ценны потому, что понимают системы. Они понимают компромиссы. Они понимают, почему одно проектное решение создаёт будущие эксплуатационные проблемы, а другое их избегает. Они понимают, как ПО ведёт себя после запуска, под нагрузкой, в разных регионах, в сложных средах безопасности и соответствия требованиям и поверх моделей ценообразования публичного облака, которые наказывают за неэффективность. ИИ этого не заменяет. Он лишь имитирует фрагменты этого.
Ещё хуже то, что слишком многие компании поощряют краткосрочность. Рынок любит истории о сокращении расходов. Объявляйте о сокращениях или говорите об «ИИ-трансформации» достаточно часто — и можно получить приятный временный рост акций. Руководители это знают. Они также знают, что если реальный ущерб проявится через три-четыре квартала, всегда можно будет обвинить исполнение, рыночные условия или «неожиданные сложности». А тем временем инженерный фундамент компании выхолащивается.
Не будьте той компанией, которая слишком поздно понимает, что загнала себя в ИИ-угол. Старые системы, созданные людьми, всё ещё будут существовать, но люди, которые их понимали, исчезли. Новые системы, созданные ИИ, дороги, хрупки и непрозрачны. Перестройка обойдётся в целое состояние. Найти и нанять талант снова будет трудно. Некоторые сотрудники не вернутся, и я бы их не винил.
Я уже говорил это раньше, и это по-прежнему верно: ИИ и близко не заменяет инженеров-программистов в том масштабе, который обещают. Даже рядом не стоит. Руководители, которые думают иначе, наивны, а не смелы. Хуже того, они рискуют своими компаниями ради маркетинговых историй, которые продвигают люди, наживающиеся на преувеличении будущего.
В ближайшие несколько лет я ожидаю несколько непростых кейсов. Некоторые компании тихо сменят курс. Другие потратят много денег, пытаясь исправить проблемы. Некоторые могут закрыться полностью, потому что совершили фатальную управленческую ошибку: поверили в хайп, уволили людей, которые знали, что делают, и передали контроль над системами тем, кто по-настоящему ими управлять не мог.
Если компании хотят избежать такого исхода, ответ прост. Сохраняйте своих инженеров, используйте ИИ для усиления их возможностей и назначайте опытных архитекторов руководить, обеспечивать governance, контролировать расходы и гарантировать сопровождаемость. Относитесь к ИИ как к инструменту, а не как к замене человеческого суждения.
Хайповые циклы легко порождают множество волшебных обещаний. Реальность менее захватывающая. Смотрите сквозь маркетинговый туман на долгосрочные последствия, потому что именно реальность оплачивает счёт за облако.
Искусственный интеллектИТ-стратегияИТ-руководствоНовые технологииТехнологическая отрасль
Дэвид С. Линтхикум — международно признанный отраслевой эксперт и мыслитель-лидер. Дейв написал 13 книг о вычислительной технике, последняя из которых — Путеводитель инсайдера по облачным вычислениям. Его отраслевой опыт включает работу в должностях CTO и CEO в нескольких успешных софтверных компаниях, а также руководящие позиции в компаниях из списка Fortune 100. Он выступает с ключевыми докладами на ведущих технологических конференциях по облачным вычислениям, SOA, интеграции корпоративных приложений и корпоративной архитектуре. Дейв пишет блог Cloud Insider для InfoWorld. Его взгляды принадлежат ему самому.
Ещё от этого автора
Покажите мне больше
feature
Начните работать с новым типом frozendict в Python
By Serdar YegulalpApr 8, 20265 mins
Programming LanguagesPythonSoftware Development
opinion
Проблема масштабирования Terraform: когда инфраструктура как код становится инфраструктурой как сложность
By Neel ShahApr 7, 202614 mins
Cloud ManagementDevelopment ToolsDevops
news
Приобретение SchedMD компанией Nvidia ставит под пристальное внимание планирование ИИ с открытым исходным кодом
By Gyana SwainApr 7, 20265 mins
Artificial IntelligenceOpen SourceSoftware Development
video
Новый тип frozendict в Python
video
Как повысить производительность приложения с помощью ленивого импорта Python 3.15
video
Как запустить свой маленький локальный Claude Code (ну, почти!)
Mar 26, 20267 mins
Python
Материал — перевод статьи с английского.
Оригинал: How to destroy a company quickly