← Предыдущая статья

Код теперь может появляться быстро. Иногда настолько быстро, что старый вопрос «кто это написал?» начинает звучать почти старомодно.

Хочется спросить иначе: кто за это отвечает?

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

Вот почему эту «дверь» лучше сразу снабдить подходящей сигнализацией.

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

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

Что должно оставаться после применения ИИ — в задаче, ревью, тестах, журнале изменений, — чтобы при сбое не приходилось снаряжать археологическую экспедицию в поисках утраченного чата?

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

Факты

По итогам АКПО-Конф 2026

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

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

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

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

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

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

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

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

А это чувство порой гораздо опаснее медленной разработки.

Что видно по российским реалиям

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

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

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

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

Что подсказывает внешний ИТ- и SAP-фон

Внешний фон здесь полезен тем, что показывает масштаб сдвига. По данным Stack Overflow Developer Survey 2025, 84% респондентов уже используют или планируют использовать ИИ-инструменты в разработке, а 51% профессиональных разработчиков используют их ежедневно. То есть это уже не экспериментальная игрушка (Stack Overflow Developer Survey 2025).

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

GitHub в документации по ответственному использованию Copilot Code Review прямо пишет, что инструмент нужно применять с пониманием его назначения, возможностей и ограничений. Это важная формулировка: даже ИИ-инструмент для проверки кода сам нуждается в понимании своих границ (GitHub Docs, Responsible use of Copilot Code Review).

NIST AI Risk Management Framework тоже полезен как общий внешний ориентир. Он не про российскую разработку напрямую и не про ERP как таковую, но задает дисциплину управления рисками ИИ на уровне людей, организаций и общества. Для корпоративного кода это переводится на простой язык: нельзя просто включить ИИ в процесс и надеяться, что риск рассосется в производительности (NIST, AI Risk Management Framework).

SAP-фон добавляет еще одну важную рамку. SAP в материалах о «responsible AI» описывает ответственный ИИ через этику, безопасность и соответствие требованиям, а среди принципов называет человеческий контроль, прозрачность, объяснимость, ответственность и подотчетность. Для SAP-аудитории это знакомая логика: чем ближе инструмент к критическим бизнес-процессам, тем меньше права на магическое мышление и на авось (SAP, AI Ethics).

Редакционное наблюдение

Если убрать шум вокруг ИИ, остается довольно приземленная картина. Код стал появляться быстрее, а ответственность за него — нет.

В этом и есть главное смещение.

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

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

И вот здесь возникает странная развилка.

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

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

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

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

Попытка объяснения

Возможно, нас сбивает с толку не сам ИИ, а скорость появления результата.

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

Вот здесь и начинается ловушка.

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

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

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

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

Иначе команда получает не помощника, а ускоритель самоуспокоения. Код появился. Объяснение есть. Демо работает. Все кивают. А потом выясняется, что никто так и не взял на себя труд задать самый скучный и самый полезный вопрос: «Мы точно понимаем, что здесь происходит?»

Гипотеза

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

Не на словах: «мы все проверили».
А по следам, которые можно предъявить.

Где видно, что фрагмент появился с участием ИИ?
Кто понял, что именно он делает?
Какие допущения проверили?
Какие сценарии покрыли тестами?
Какие данные нельзя было передавать инструменту?
Какие риски приняли осознанно?
Где зафиксировано решение о выпуске?

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

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

А как это устроено у вас? Остается ли в задачах, ревью, тестах или журналах изменений след того, что код появился с участием ИИ? Кто обязан этот след оставить и кто потом по нему идет: разработчик, тимлид, архитектор, служба безопасности, владелец продукта, комитет по изменениям? Бывали ли случаи, когда отсутствие такого следа уже мешало понять, почему решение попало в контур?

Пишите на y.nechitaylov@sappro.ru, в комментариях к соответствующим постам в сообществе в ВК или в комментариях под этими материалами на sappro.ru.

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

Продолжение следует.

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия