В последние месяцы я всё чаще натыкаюсь на одну и ту же мысль.
Сначала услышал её в видеоподкасте - двое руководителей 1С-франчайзи рассуждали о трендах автоматизации и ИИ-инструментах. Потом эта же тема всплыла в одном тематическом чате: кто-то из коллег спросил, почему у них в компании никто не мотивирует разработчиков использовать ИИ-агентов...
И везде - одно и то же наблюдение: инициатива использования ИИ в 1С-разработке почти всегда идёт снизу, от рядовых программистов. Руководство если и не тормозит, то и не форсирует.
Никаких директив "с понедельника все переходят на Cursor".
Информация отложилась, но всерьёз я над этим не задумывался.
Сам последние месяцы активно практикую ИИ-агентов в разработке, но поиском ответа на этот парадокс не задавался.
Казалось бы: бизнес хочет эффективности, ИИ обещает ускорить разработку в разы — почему бы не приказать всем активно использовать?
В этой статье хочу лишь высказать предположение, которое пришло само-собой как квинтэссенция всей практики: причина не в техническом консерватизме и не в страхе перед новым.
Как мне кажется, первая причина лежит на поверхности: политика конфиденциальности архитектуры решений.
Вторая не менее весомая причина в границе ответственности. На этой причине хочется более детально остановиться.
Пока ИИ остаётся вероятностным инструментом без гарантий корректности, ожидать директив сверху маловероятно.
Попробую сформулировать предположения, почему.
Важное уточнение: статья не претендует на истину в последней инстанции, это лишь мое субъективное мнение. Истина, как обычно, где-то посередине, и я с радостью почитаю ваши альтернативные точки зрения в комментариях.
Давайте для начала разберём два главных мифа, которые мешают это понять.
ИИ - не новый уровень абстракции
Часто ИИ-агентов сравнивают с переходом от ассемблера к языкам высокого уровня. Мол, тогда программист перестал думать о регистрах и стеке — и стал думать о логике задачи. А теперь, по той же логике, - новый виток: вместо написания кода на Python или 1С пишешь промпт на естественном языке, и код рождается сам.
Но это сравнение - ложная аналогия.
Переход от ассемблера к Python изменил саму модель мышления. Программист перестал думать о регистрах, стеке и адресации. Он начал думать о бизнес-логике, структурах данных и алгоритмах на порядок выше. Это был настоящий новый уровень абстракции.
С ИИ иначе:
- На выходе - тот же самый код на том же языке (Java, Python, 1С).
- Синтаксис не изменился. Метаданные не изменились. Паттерны проектирования не изменились.
- Изменился источник написания: вместо клавиатуры разработчика — нейросеть «на стероидах».
Но артефакт остался прежним. И сложность никуда не делась — она просто сдвинулась из синтаксиса в валидацию и промпт-инжиниринг.
Но при этом "сэкономленное" время "съедается" временем на проверку.
ИИ - это не компилятор естественного языка
Метафору "компилятора естественного языка" доводилось слышать - и она, на мой взгляд, вводит в заблуждение.
Компилятор принимает на вход язык с формальной грамматикой. Промпт же, написанный на естественном языке, никак не формализован.
Отсюда и иллюзия «компилятора естественного языка»: кажется, что можно просто описать задачу словами, как будто это тот же Python, только «по-человечески».
У обычного компилятора правила жёсткие: опечатка в коде - получишь ошибку, проект не скомпилируется. Зато сразу видно, где проблема.
У ИИ-агента всё устроено иначе:
| Характеристика | Компилятор | ИИ-агент |
|---|---|---|
| Реакция на некорректный вход | Явная ошибка, сборка останавливается | Додумывает недостающее, выдаёт правдоподобный ответ |
| Связь вход-выход | Один и тот же код даёт тот же результат | На один промпт - разный код |
| Уверенность в результате | Если собралось - синтаксис точно верен | Код может быть полностью нерабочим, но выглядеть убедительно |
В этом и подвох: при плохом промпте ИИ не скажет «ошибка компиляции». Он всё равно что-то вернёт - часто аккуратный и уверенный код, который просто не делает то, что нужно.
Отсюда и главная мысль: не сам факт использования ИИ все решает, а большую роль играет навык разработчика - сформулировать задачу, проверить результат и довести код до рабочего состояния.
Миф о "вайб-кодинге" и цена дисциплины
Об истории этого термина можно было бы написать отдельную статью. Но сейчас важно отметить другое: слово "вайб-кодинг" стало настолько модным, что под него пытаются подогнать вообще любую разработку с использованием ИИ.
Этот термин приобрел взрывную популярность и теперь ошибочно используется как синоним современной продуктовой разработки.
Из-за этого создается ложная иллюзия: будто программирование с ИИ-агентами происходит «на вайбе» - расслабленно, без напряжения и глубокого погружения.
Отдельно стоит упомянуть маркетинговый шум вокруг этой темы, который особенно усилился в 2025 году.
Мне довелось услышать на одном рекламном вебинаре показательную фразу: "Нужно ли идти в разработку (по-старинке)? Пока что ещё надо, ... но еще год-два и вас, уважаемые господа разработчики, заменят люди, которые не умеют кодить, но умеют вайб-кодить" (с).
Это откровенно ложная и опасная иллюзия. Подобный посыл создаёт обманчивое впечатление, что в краткосрочной перспективе фундаментальные знания нынешних разработчиков обесценятся. Мол, скоро вчерашний бухгалтер сядет "кодить", не понимая архитектуры, навыков конфигурирования, паттернов разработки... потому что теперь ему "даже разраб не нужен".
Кто-то действительно мог поверить в эту картинку: разработка из удобного кресла, пока на втором мониторе крутится фильм, а зарплата исправно падает на карту.
Но реальность значительно отличается от того, что рисуют "продавцы иллюзий". На практике всё ровно наоборот. ИИ - это сверхэффективный инструмент, но только для тех, кто умеет:
- Чётко формализовать требования и контекст задачи.
- Задавать точные уточняющие вопросы.
- Заставлять ИИ объяснять логику своего решения.
- Требовать альтернативные варианты реализации.
- Воспринимать результат ИИ не как финишную черту, а как черновик или отправную точку.
- Относиться к сгенерированному коду с профессиональным скептицизмом и критичностью.
Очевидно, что программирование с ИИ - это новый и в то же время сложный навык.
Это мощный инструмент в руках зрелого разработчика, который обладает не только умением открыть Cursor, но и глубокими фундаментальными знаниями платформы 1С, а также жёсткой внутренней дисциплиной. Этот навык нужно целенаправленно прокачивать. Да, новый подход только начинает развиваться, и потребуется время, чтобы маркетинговые иллюзии развеялись, а на их месте сформировался зрелый, профессиональный подход.
Ответственность - это камень преткновения
А теперь перейдём к управленческому слою.
Для руководителя и для заказчика важен не инструмент, а результат:
- код работает корректно;
- соответствует стандартам разработки;
- масштабируем;
- не создаёт технического долга.
Какими средствами разработчик этого добился - десятый вопрос. Хоть пером на бумаге, хоть нейросетью.
Но есть нюанс: вся ответственность за результат лежит на разработчике. Инструмент может ускорять, но не может нести ответственность. Скорость за ИИ, ответственность за вами.
И вот тут возникает тонкий момент.
Если инициатива исходит снизу
Разработчик сам решил использовать ИИ, сэкономил время, получил свой профит. Если код "сломался", результат "кривой" - он и чинит.
Никто не может сказать: "А мне нейросеть так написала". Сам выбрал - сам отвечаешь. Граница ответственности прозрачна и незыблема.
Если инициатива исходит сверху
Давайте представим гипотетически: руководство выпускает директиву: "С понедельника все используют ИИ-агентов при разработке, хватит топтать клавиатуру, все идеи в ногу со временем".
Что происходит с психологией разработчика? Появляется пространство для перекладывания ответственности: «Вы сами мотивировали нас этим пользоваться. Я сделал промпт, скопировал сгенерированный код, он упал в проде. Виноват ИИ-агент - ну или руководство, которое обязало меня его использовать».
Да, формально ответственность всё равно на разработчике. Но неформально - размывается. Появляется удобный "козёл отпущения". И руководитель это чувствует.
Поэтому многие руководители интуитивно выбирают позицию: «Ваша инициатива - ваша ответственность. Хотите ускоряться с ИИ - пожалуйста. Но если вы скопировали неработающий код, я даже не хочу слышать слово "нейросеть".
Это не запрет. Это честное правило игры.
Риск массового внедрения "сверху": пример из головы
Давайте представим утрированный, но жизненный сценарий.
Вы руководите разработкой на 1С в ИТ-компании. Вы решаете «быть современным» и издаете директиву: все разработчики обязаны при доработке конфигурации 1С использовать корпоративный ИИ-агент.
Через месяц-два - "код-лапша". Результат практически не подлежит рефакторингу, проще снести и сделать всё заново. Вместо экономии получаем огромный технический долг и потерю человеко-часов.
На разборе полётов разработчик говорит: "Я дал агенту задание - вот промпт. Он сгенерировал код. Я его принял. У нас была установка использовать ИИ".
Вопрос на засыпку: кого вы уволите первым?
- Разработчика? Он следовал "приказу сверху" и формально он вел себя как "законопослушный гражданин".
- ИИ-агента? У него нет юрлица.
- Себя? Потому что создали систему, в которой никто не проверяет то, что раньше проверяли всегда?
Это мысленный эксперимент, но он хорошо иллюстрирует: инициатива сверху создаёт иллюзию, что ответственность можно разделить. Нельзя.
Ни суд, ни клиент не примут отговорку "нейросеть так написала".
Где же разумный подход?
Руководство, на мой взгляд, должно делать не приказ "использовать ИИ", а ровно две вещи:
1. Разрешить использование ИИ-агентов официально.
2. Закрепить документально правило: "Вы отвечаете за сгенерированный код так же, как за написанный руками".
Всё. Никакого "внедрения сверху". Дальше - инициатива снизу.
И это работает. Те разработчики, кто умеет формулировать задачи и быстро валидировать результат, получат ускорение.
Те, кто не умеет, - не получат или даже замедлятся... а если что-то и получат, то генератор "костылей".
Практика всё быстро расставит по местам.
Но будет ли когда-нибудь иначе?
А что, если появятся ИИ-агенты, которые не просто генерируют код, но и формально доказывают его корректность?
С верификацией, контрактами, автоматическим тестированием?
Тогда ситуация может измениться. Если ИИ сможет предоставить надёжную гарантию - математическую или статистическую - что его код верен, ответственность действительно может сместиться на инструмент.
Но сегодня таких агентов нет.
Сегодняшние агенты - вероятностные генераторы без гарантий корректности. Они полезны, но не дают детерминированной уверенности, как компилятор.
Пока ИИ не стал детерминированным компилятором естественного языка - инициатива должна быть снизу. Но тогда и естественный язык, на котором пишут промпты, должен стать формализованным.
Хотя, если честно, естественный язык и не может быть полностью формализован. Как только мы начнём жёстко регламентировать синтаксис промптов, вводить строгую грамматику и однозначные конструкции - он перестанет быть естественным и превратится в очередной язык программирования. А мы вернёмся туда, откуда начинали.
И напоследок. Это не просто теория. Пока я готовил эту статью, в одном из профессиональных чатов коллега поделился реальной историей:
Компания, по настойчивой просьбе сотрудников, официально предоставила разработчикам доступ по корпоративной подписке к Gemini и Claude для работы с текстами.
Через некоторое время на совещании генеральный директор услышал фразу одного из сотрудников: "Да пофиг, я не проверял даже, все через нейронку сделал".
На следующем совещании было объявлено: доступ к корпоративным ИИ-инструментам закрыт полностью.
Это идеальный пример того, как инициатива сверху (предоставление доступа) столкнулась с размыванием ответственности. Результат предсказуем: "лавочку закрыли".
Что в итоге
Руководители не форсируют ИИ не потому, что они недальновидные или консервативные. А потому что:
- ИИ не создаёт новый уровень абстракции (код остаётся тем же кодом);
- ИИ не является компилятором (отсутствует явная ошибка при некорректном промпте);
- качество результата остаётся и должно оставаться на совести разработчика;
- инициатива сверху размывает границу ответственности и создаёт риски апелляций к инструменту.
Поэтому мой совет руководителям: разрешайте, но не приказывайте. А разработчикам: берите инициативу в свои руки. Это ваш инструмент. И ваша ответственность.
Вопрос к сообществу
Внедряют ли у вас агентскую разработку "сверху"? И если да - как у вас построена политика ответственности?
Поделитесь в комментариях - тема только разгорается :).
Вступайте в нашу телеграмм-группу Инфостарт