Безрассудное искушение генерации кода с помощью ИИ
мнение
7 апр. 2026 г. 6 мин
Замените всех своих инженеров ИИ и затем смотрите, как неэффективный код вызывает непомерные счета за облако, а технический долг становится необратимым.
Фото: Jag_cz / Shutterstock
Слишком многие руководители сокращают команды разработки программного обеспечения, потому что поверили в фантазию о том, что ИИ теперь может создавать и поддерживать корпоративные приложения, а рядом для надзора за машиной нужны лишь несколько человек. Эта идея не смела. Она не дальновидна. Она безрассудна, и все больше руководителей будут расплачиваться за последствия своих ошибок не только плохим кварталом.
Да, ИИ может писать код. Это ясно. Проблема в том, что многие поставщики и лидеры взяли этот факт и довели его до абсурда: до идеи, что разработка программного обеспечения стала по сути необязательной. Они считают, что если модель способна генерировать логику приложения, то опытные разработчики, архитекторы и инженеры по производительности внезапно становятся ненужными расходами. Такой образ мыслей может показаться умным в презентации для совета директоров, но в реальной эксплуатации он рушится.
Как разваливается эта история
Приложения часто работают, что делает такой подход обманчиво эффективным. Демонстрация проходит успешно, и поначалу кажется, что функция работает как надо. Все поздравляют друг друга. Но затем система разворачивается в масштабе, и счет за облако взлетает. То, что раньше стоило $10 000 в месяц на AWS, внезапно подскакивает до $300 000 или больше. В худших случаях компании сталкиваются с ежемесячными облачными расходами в миллионы долларов за системы, которые изначально вообще не следовало строить таким образом.
ИИ может генерировать код, но он не понимает эффективность так, как опытные инженеры. Он не приоритизирует экономичную архитектуру. Он не инстинктивно избегает лишних вызовов сервисов, чрезмерного перемещения данных, плохого кэширования, неудачных шаблонов параллелизма, шумного поведения баз данных или вычислительно тяжелой бессмыслицы, которая может хорошо выглядеть в примере кода, но проваливается в реальном использовании. Он создает нечто правдоподобное. Однако он не создает нечто финансово ответственное.
Потом следует мой любимый плохой аргумент от лагеря ИИ-хайпа: «Просто потом оптимизируем». Ладно. С кем? Эти компании уволили экспертов, понимавших сложные системы, оставив после себя сгенерированный ИИ код, который никто до конца не понимает. Оставшиеся люди это не создавали, не знают его структуру и не могут безопасно его изменять. Они застряли с приложениями, которые могут запускать по заоблачной цене, но не могут надежно поддерживать.
Это не инновация. Это технический долг, нанесенный себе самой, в промышленном масштабе.
Обычно технический долг накапливается постепенно. Тут поспешный релиз, там сокращение пути, старый dependency, к которому никто не хочет прикасаться. С корпоративным ПО, созданным ИИ, компании создают годы технического долга за считанные месяцы. В худшем смысле это почти впечатляет. Они сжимают целые циклы провала, потому что ИИ позволяет им строить быстрее, чем они успевают думать.
А теперь начинаются лихорадочные звонки. Почему приложение тормозит? Почему пользователи жалуются? Почему труднее диагностировать сбои? Почему счет за облако вышел из-под контроля? Почему никто не может это исправить, не сломав что-то еще? Почему обещание ИИ-кодинга совсем не похоже на рекламные обещания?
Знайте плюсы и минусы ИИ
Это не значит, что ИИ бесполезен — вовсе нет. ИИ действительно может помочь командам разработки двигаться быстрее. Он может помочь с каркасом проекта, документацией, рутинными задачами кодирования, генерацией тестов и даже с архитектурным мозговым штурмом. В руках сильных инженерных команд это законный ускоритель. Но где-то по пути слишком многие руководители решили, что «ускоритель» означает «замена», и начались плохие решения.
Хорошие инженеры ценны не потому, что умеют набирать код в редакторе. Хорошие инженеры ценны потому, что понимают системы. Они понимают компромиссы. Они понимают, почему одно архитектурное решение создает будущие операционные проблемы, а другое их избегает. Они понимают, как программное обеспечение ведет себя после запуска, под нагрузкой, в разных регионах, в сложных средах безопасности и соответствия требованиям, а также поверх моделей ценообразования публичного облака, которые наказывают за неэффективность. ИИ этого не заменяет. Он имитирует лишь фрагменты этого.
То, что делает ситуацию еще хуже, — это то, что слишком многие компании поощряют краткосрочность. Рынок любит историю о сокращении расходов. Объявляйте увольнения или говорите «ИИ-трансформация» достаточно часто, и вы можете получить приятный временный рост акций. Руководители это знают. Они также знают, что если реальный ущерб проявится через три или четыре квартала, всегда можно обвинить исполнение, рыночные условия или «неожиданные сложности». Тем временем инженерный фундамент компании выхолащивается.
Не будьте той компанией, которая слишком поздно понимает, что загнала себя в ИИ-угол. Старые системы, созданные людьми, все еще будут работать, но люди, которые их понимали, исчезнут. Новые системы, созданные ИИ, дороги, хрупки и непрозрачны. Перестройка обойдется в целое состояние. Найм талантов будет трудным. Некоторые сотрудники не вернутся, и я бы их не винил.
Я говорил это раньше, и это по-прежнему верно: ИИ и близко не заменяет разработчиков программного обеспечения в том масштабе, который обещают. Даже близко. Лидеры, которые думают иначе, наивны, а не смелы. Хуже того, они рискуют своими компаниями ради маркетинговых историй, распространяемых людьми, которые наживаются на преувеличении будущего.
В ближайшие несколько лет я ожидаю несколько трудных кейс-стади. Некоторые компании тихо сменят курс. Другие потратят много денег, пытаясь исправить проблемы. Несколько могут закрыться полностью, потому что допустили фатальную управленческую ошибку: поверили в хайп, уволили людей, которые знали, что делают, и передали контроль над системами тем, кто не мог по-настоящему ими управлять.
Если компании хотят избежать такого исхода, ответ прост. Оставьте своих инженеров, используйте ИИ для расширения их возможностей и назначайте опытных архитекторов, чтобы они руководили, обеспечивали контроль, управляли расходами и обеспечивали поддерживаемость. Рассматривайте ИИ как инструмент, а не как замену человеческому суждению.
Хайп-циклы легко порождают множество магических заявлений. Реальность менее захватывающая. Смотрите сквозь маркетинговый туман на долгосрочные последствия, потому что именно реальность оплачивает счет за облако.
Искусственный интеллектИТ-стратегияИТ-лидерствоНовые технологииТехнологическая индустрия
Дэвид С. Линтикум — всемирно признанный отраслевой эксперт и мыслитель-лидер. Дэйв написал 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Разработка ПО

news
GitHub Copilot CLI добавляет агент проверки Rubber Duck
By Paul KrillApr 7, 20263 mins
Искусственный интеллектИнструменты разработкиГенеративный ИИ

opinion
Проблема масштабирования Terraform: когда инфраструктура как код становится инфраструктурой как сложностью
By Neel ShahApr 7, 202614 mins
Управление облакомИнструменты разработкиDevops

video
Новый тип frozendict в Python
video
Как повысить производительность приложения с помощью ленивого импорта Python 3.15
video
Как запустить свой маленький локальный Claude Code (ну, почти!)
Mar 26, 20267 mins
Python
![]()
Материал — перевод статьи с английского.