ИИ пишет код. Что теперь меняется в IT-командах, архитектуре и ответственности за результат

Экономия на коде не означает автоматического сокращения IT-бюджета

Самый очевидный эффект ИИ — ускорение разработки. В дискуссии звучали оценки прироста производительности на 20–30%, а для отдельных практических задач — и более существенного сокращения сроков и стоимости. Однако экономический эффект оказывается сложнее простой формулы «меньше времени на разработку — меньше расходов».

Всё зависит от того, о какой модели использования ИИ идёт речь. Для компании, которая пользуется готовым сервисом, основными прямыми затратами может быть подписка. В качестве одного из ориентиров называлась стоимость порядка 200 долларов в месяц за доступ к Claude. Но корпоративный on-premise-контур — совершенно другая экономика.

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

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

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

Основная работа IT не заканчивается на написании кода

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

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

Особенно заметно это становится там, где бизнес начинает самостоятельно создавать работающие решения. В дискуссии этот процесс был обозначен через образ «импортозамещения Excel»: если раньше сложные макросы и небольшие прикладные инструменты создавались отдельными специалистами, то теперь пользователь может сформулировать задачу на естественном языке, получить работающий прототип и прийти с ним в IT уже не в качестве заказчика идеи, а фактически с готовым инструментом.

Для IT-организации это принципиально меняет ситуацию. Раньше разработка в значительной степени проходила через IT: даже при привлечении подрядчика задача обычно формулировалась и координировалась этой функцией. Теперь часть разработки может переместиться непосредственно в бизнес.

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

От исполнителя – к координатору

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

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

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

Архитектура, требования и ответственность становятся важнее

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

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

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

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

Что происходит с разработчиками

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

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

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

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

ИИ может изменить экономику проектов

Наиболее убедительно экономический эффект проявляется на конкретных проектах. В дискуссии приводилась оценка ускорения разработки на 20–30%. В другом случае участники сравнивали традиционную оценку создания CRM примерно в 30 млн рублей с практическим примером, где генеральный директор компании создал аналогичное решение с использованием Claude примерно за месяц и затратами порядка 1 млн рублей.

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

В обсуждении звучала и более высокая оценка — в отдельных сценариях разработка может выполняться в 5–10 раз быстрее и в 5–10 раз дешевле. Но применимость таких цифр зависит от конкретной задачи, исходной архитектуры, квалификации команды и требований к конечному продукту.

Поэтому речь идёт не столько об универсальном сокращении стоимости разработки, сколько о расширении диапазона задач, которые можно решать при прежнем объёме ресурсов.

Отдельная проблема — поддерживаемость AI-кода

Сгенерировать работающий код сегодня зачастую проще, чем обеспечить его дальнейшую эксплуатацию.Для промышленной IT-системы важен не только результат первичной разработки, но и возможность передать решение другой команде, сопровождать его, диагностировать ошибки и изменять его через несколько лет. Код должен быть понятен специалисту, который не участвовал в его создании.

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

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

ERP и самостоятельная разработка бизнесом

Отдельный пласт дискуссии касался корпоративных систем. В качестве примера приводилась разработка небольшого ERP-решения непосредственно внутри организации. Техническое задание было сформулировано с помощью Qwen, а затем передано Claude для дальнейшей работы.

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

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

Меняется рынок разработчиков и вендоров

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

ИИ постепенно появляется непосредственно внутри прикладных продуктов. Обсуждался, например, искусственный интеллект в системах электронного документооборота. Появляется и подход, при котором продукт изначально проектируется как AI-native — с учётом того, что взаимодействие пользователя с системой будет строиться через модели.

Меняется даже такая, казалось бы, отдельная задача, как ведение сайта. В дискуссии приводился пример сервиса, позволяющего через чат-бота генерировать и изменять контент сайта, в том числе с учётом задач SEO и GEO. Таким образом, ИИ становится не отдельной функцией внутри продукта, а новым способом взаимодействия с программным обеспечением.

Меняется и бизнес-модель подрядчиков

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

В дискуссии рассматривался переход к оплате за конкретный результат — функциональный артефакт. Подрядчик получает задачу и должен передать заказчику работающий результат, а не определённое количество человеко-часов.

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

Артефакт вместо часов

В качестве практического примера обсуждался проект, в котором подрядчику требовалось обеспечить конкретный прирост производительности роботизированного оборудования. В условиях тендера был установлен показатель — увеличение производительности на 25%.

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

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

Где проходит граница готовности

Параллельно возникает вопрос о том, насколько организации готовы к такому изменению. Участники отмечали, что использование ИИ зачастую начинается не с формального корпоративного проекта.

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

Для службы информационной безопасности это уже не вопрос эксперимента с новой технологией, а непосредственный риск утечки данных. В одном из приведённых примеров после обнаружения такой практики были скорректированы настройки локального NMD и закрыт соответствующий доступ на межсетевом экране.

Одновременно компания начала тестировать собственные локальные LLM. Доступ к нескольким моделям получили около 30 сотрудников. При этом качество работы с документами пока уступало возможностям публичных моделей. Полученный опыт показал, что создание собственного контура — это отдельный инженерный проект, а не просто установка модели на сервер.

Нормативная среда тоже определяет возможности

Отдельное место в дискуссии заняли вопросы регулирования. Участники ссылались на новый приказ ФСТЭК № 117 и обсуждали появление в нормативном поле понятия «доверительных решений». При этом высказывалось мнение, что для практического применения соответствующие понятия пока требуют дополнительной конкретизации.

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

Обсуждалась и зависимость от зарубежных моделей и инфраструктуры. Звучали различные оценки перспектив российских LLM и возможных ограничений доступа к передовым зарубежным системам. Эти оценки в рамках дискуссии оставались позициями участников и не сводились к единому прогнозу.

Локальные модели и цена корпоративного AI-контура

Практический опыт развёртывания локальных моделей позволил участникам перейти от общих рассуждений к конкретной инженерной проблеме. Для работы LLM on-premise требуются мощные GPU. В качестве возможных вариантов назывались L40S, H200 и Blackwell 6000. Но недостаточно просто приобрести ускоритель. Необходимо убедиться, что серверная платформа поддерживает соответствующую конфигурацию по питанию, охлаждению и физическим габаритам.

В обсуждении приводился показательный пример: оборудование, приобретённое за несколько лет до этого, могло формально не поддерживать установку современного ускорителя из-за его энергопотребления. В других случаях возникали чисто физические ограничения — карта могла просто не помещаться в существующий корпус.

Поэтому стоимость корпоративного LLM-контура быстро выходит за пределы цены самого GPU-ускорителя. Участники оценивали стоимость GPU как минимум в миллионы рублей, а всей платформы – уже в десятки миллионов. При этом возникает главный экономический вопрос: соответствует ли получаемый от локальных моделей эффект таким инвестициям. По приведённому опыту однозначного ответа пока нет.

ИИ для IT – это не только программирование

Ещё одна важная тема дискуссии — чрезмерное сведение ИИ для IT к генерации кода. У IT-функции есть отношения с заказчиками и подрядчиками, исследования, инновации, развитие, управление проектами и множество других задач. Если автоматизируется только разработка, это не означает, что вся IT-организация автоматически становится более эффективной.

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

Для IT-директора возникает задача перевести индивидуальные эксперименты в контролируемую среду: определить допустимые сценарии, обеспечить безопасность данных, выбрать инструменты и понять, где применение ИИ действительно создаёт ценность.

AI меняет отношения между заказчиком и исполнителем

В традиционной схеме взаимодействия бизнес формулирует потребность, а IT или подрядчик превращает её в техническое решение. Теперь граница между этими ролями становится менее чёткой.

В дискуссии приводился уже практический пример: заказчик с помощью ИИ самостоятельно придумал продукт или отдельную функциональность, прогнал требования через модель и передал результат подрядчику. Таким образом, ИИ начинает работать по обе стороны отношений «заказчик — исполнитель».

Это меняет саму природу требований. Если раньше от заказчика ожидалась постановка задачи, то теперь он способен принести уже частично проработанный продукт. Но ответственность за проверку требований никуда не исчезает.

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

ИИ меняет требования к IT-директору

В такой ситуации роль IT-директора всё меньше определяется личным участием в технической реализации отдельных проектов. На первый план выходят способность разбираться в новых технологиях, понимать их ограничения и оценивать применимость для конкретного бизнеса.

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

Меняется и язык разговора с бизнесом. Вместо технических показателей вроде FTE или характеристик отдельных информационных систем всё чаще приходится говорить об эффективности, снижении затрат, росте производительности и влиянии на маржу.

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

Критическое мышление становится частью технологической компетенции

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

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

Вместо одномоментной революции — постепенное изменение IT-организации

В финале дискуссии звучала мысль о том, что изменения неизбежны, но вряд ли будут одномоментными и радикальными для всей организации. Показательна аналогия с предыдущими волнами автоматизации. Когда появились ER-дизайнеры и ER-моделеры, стало возможно автоматически генерировать SQL-код, создавать таблицы, связи и тестовые данные. Это существенно изменило инструментарий разработчика и администратора баз данных, но не отменило сами профессии.

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

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

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

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

__________________________
Аналитический материал подготовлен на основе содержания докладов конференции с использованием инструментов искусственного интеллекта. Все выводы основаны исключительно на материалах представленных выступлений.

© СТА-ПРЕСС, 2026