Триумф намерения: что становится главным ресурсом, когда код почти ничего не стоит

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

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

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

Сегодня дорого не столько сделать, сколько понять, что именно нужно сделать

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

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

Приложение для себя теперь может сделать почти каждый

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

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

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

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

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

Пример из практики: ТехВилл / ВкусВилл

В феврале 2026 года один из лидеров стека тестирования ТехВилла рассказывал, как использует ИИ-инструменты в работе. По его словам, он не считает себя программистом и JavaScript «не знает совсем», но с помощью подхода вайб-кодинга (разработки через диалог с ИИ) собрал два собственных микропродукта. У одного из них – более 60 тысяч активных пользователей в неделю.

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

Прототип становится новой формой технического задания

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

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

Не потому, что скрывает информацию. Он просто не мыслит собственный процесс как технический регламент.

Спросите у специалиста: «Расскажи по шагам, как ты разбираешь входящий запрос». Он что-то объяснит. Потом вы сделаете систему, покажете ее – и услышите: «Ну нет, здесь я обычно еще смотрю вот это. А если клиент такой, я делаю по-другому. А вот про этот случай я вообще забыл».

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

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

Получается интересная штука: прототип становится формой постановки задачи.

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

Пример из практики: Альфа-Банк

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

При этом банк сделал внутреннее руководство, по которому минимально жизнеспособный продукт, или MVP (первая рабочая версия продукта с необходимым минимумом функций), можно собрать примерно за шесть часов. На внутреннем хакатоне по этой теме участвовали 280 сотрудников; 71 команда успела сдать работающее решение за сутки.

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

Дешевым стало «сделать». Дорогим осталось «понять»

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

Первая – произвести результат. Написать код, собрать интерфейс, изменить логику, исправить ошибку, повторить попытку.

Вторая – понять, что получилось. Подходит ли это пользователю? Решает ли исходную задачу? Что нужно изменить? Какой вариант лучше? Что делать дальше?

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

Но вторая половина никуда не делась

Модель может предложить десять вариантов. Кто-то должен выбрать один. Она может написать код. Кто-то должен понять, соответствует ли он архитектуре. Может сделать красивый экран. Кто-то должен решить, нужен ли этот экран пользователю вообще.

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

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

Что показывают исследования разработки

В отчете DORA за 2025 год, основанном почти на пяти тысячах ответов специалистов, ИИ уже связан с ростом скорости поставки изменений и результативности продукта. Но одновременно исследователи по-прежнему увидели отрицательную связь со стабильностью поставки. Их основной вывод мне близок: ИИ усиливает ту систему работы, которая уже есть. Сильные процессы становятся быстрее, слабые – быстрее проявляют свои слабости.

Есть и полезный контрапункт. Исследование METR на опытных разработчиках открытого программного обеспечения в начале 2025 года показало, что с тогдашними ИИ-инструментами участники выполняли задачи в среднем на 19% дольше. В феврале 2026 года METR сообщил, что свежие инструменты, вероятно, уже ускоряют разработчиков сильнее, но новый эксперимент оказался слишком подвержен смещению выборки, чтобы надежно назвать величину эффекта.

То есть вопрос уже не сводится к простому «ускоряет ИИ или нет?». Гораздо интереснее другое: какой процесс и какого человека он усиливает.

Новый дефицит – ясность

Отсюда мы постепенно пришли к мысли, которую я для себя называю «триумфом намерения».

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

Теперь управлять все чаще нужно другим ресурсом – ясностью.

Что вообще стоит делать? Для кого? Как поймем, что получилось хорошо? Что действительно важно бизнесу, а что просто интересно попробовать? Какую следующую итерацию делать первой?

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

Можно поручить модели написать пять вариантов коммерческого предложения. Но решение «вот это похоже на нас, а это нет» принимает человек. Можно получить три архитектуры системы. Но кто-то должен понимать ограничения заказчика. Можно за вечер собрать приложение. Но кто-то должен ответить на вопрос: зачем оно существует?

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

А потом выясняется, что данных вроде много, но использовать их нельзя

Следующая неожиданность приходит довольно быстро.

Компания говорит: «У нас все задокументировано». И действительно – есть база знаний, корпоративный портал, Jira, CRM, папки с документами, переписки, регламенты. Годы цифровизации не прошли зря.

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

Документ есть, но непонятно, актуален ли он. В соседней папке лежит другая версия. Поля заполнены наполовину. Две команды называют одну сущность по-разному. Самая важная договоренность вообще была в чате полтора года назад. Часть файлов доступна всем, часть – только отдельным группам, и эти права нельзя просто проигнорировать ради удобства модели.

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

Пример из практики: Alpina Digital

В мае 2026 года руководитель направления искусственного интеллекта Alpina Digital описал типичную проблему корпоративных проектов с поиском по знаниям. На одном из проектов заказчик передал около 12 тысяч документов с пометкой «актуальное». После аудита осталось примерно 3,8 тысячи: остальное оказалось дублями, старыми версиями, черновиками и другим мусором.

По словам команды, после чистки качество поиска выросло кратно – без смены модели и без новой строки кода.

Это прекрасная иллюстрация того, почему иногда главный инструмент ИИ-проекта – не новая нейросеть, а аккуратная уборка.

Как мы шли у себя: начинали совсем не с революции

Теперь немного о нашей практике.

Мы не начали с грандиозной программы «трансформации бизнеса искусственным интеллектом». Первые задачи были довольно простыми.

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

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

Задним числом я считаю, что стоило

Потому что главным результатом оказалась не экономия, а привыкание.

Люди перестали смотреть на ИИ как на игрушку из новостей или, наоборот, как на страшную силу, которая завтра придет за их рабочим местом. Они начали воспринимать его как еще один рабочий инструмент. Где-то удобный, где-то глупый, где-то требующий проверки – но обычный.

После этого более серьезные вещи внедрять стало намного легче.

Появился ревьюер кода. У нас разработка идет не только на 1С: есть Java, Go, Python и другие языки. Хотелось, чтобы инструмент проверял не только общие стандарты, но и нашу внутреннюю стилистику, оформление коммитов, ссылки на задачи.

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

Дальше появились другие помощники:

• транскрибатор встреч, который превращает записи из разных систем в протоколы, записи базы знаний и задачи

• анализатор запросов заказчика, который ищет непокрытые места и похожие случаи в нашей истории проектов

• помощник по документированию доработок

• анализатор загрузки специалистов по проектам

• помощник для закупок и тендеров

• инструменты для анализа собеседований и инженерных решений

Мне здесь нравится одна закономерность

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

Пример из практики: МТС

В августе 2025 года команда МТС рассказала о внутреннем DevTools Code Review – ИИ-ревьюере, который работает с учетом принятых в компании правил и помогает разработчику проверить изменения до обычного командного ревью.

По данным команды, пользователи инструмента отправляли на 20% больше запросов на слияние изменений (Merge Request), а число ошибок при выпуске версии снизилось на 8%. Финальное решение при этом остается за разработчиком.

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

День-два на агента меняют сам принцип отбора идей

Сейчас от идеи до работающего внутреннего агента у нас часто проходит день-два.

И это меняет не только стоимость разработки. Это меняет логику принятия решений.

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

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

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

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

Для руководителя это, кстати, довольно непривычная задача. Мы десятилетиями учились бороться с «самодеятельностью» пользователей. Теперь часть этой самодеятельности становится источником хороших продуктовых идей.

Пять агентов – уже не пять маленьких проектов. Это начало зоопарка

Есть, правда, обратная сторона успеха.

Пока у вас один помощник, все просто. Вот его ключ. Вот модель. Вот люди, которые им пользуются.

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

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

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

Причем платформа для нас появилась не как продуктовая фантазия: «Давайте сделаем еще одну ИИ-платформу, рынок же любит платформы». Она стала ответом на очень практическую проблему. Агентов стало много, и зоопарк перестал быть смешным.

Пример из практики: Sminex

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

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

Внутренняя автоматизация неожиданно стала услугой

Самое интересное началось, когда мы стали показывать свои решения другим.

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

И реакция повторялась.

«Это вы сделали за два дня?»

Потом небольшая пауза.

«А можно нам такое же?»

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

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

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

Пример из практики: Just AI

У Just AI получилась почти учебная версия той же истории. Сначала команда собрала RAG-сервис (поиск по корпоративным данным с передачей найденного контекста языковой модели) для собственной поддержки. По их данным, бот забирал около 35% стандартных и легких вопросов и 10% сложных.

Когда внутренний прототип доказал пользу, команда превратила накопленный подход в тиражируемый продукт – Jay Knowledge Hub для корпоративных баз знаний.

То есть сначала автоматизировали собственную боль, получили работающий процесс и только потом понесли его заказчикам.

Почему первые полезные агенты обычно не похожи на фантастику

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

Но если посмотреть на реальные запросы бизнеса, то первые деньги часто лежат совсем в другом месте.

Найти ответ в нескольких тысячах документов. Сравнить Word и подписанный скан и понять, тот ли это документ. Разобрать входящее письмо и определить маршрут согласования. Достать из протокола встречи задачи. Проверить доработку на соответствие регламенту. Собрать справку из нескольких систем.

То есть лучшие ранние сценарии обычно имеют очень понятные границы:

• есть известный вход

• понятен ожидаемый результат

• есть много ручной рутины

• человек умеет проверить качество

• решение можно встроить в существующий процесс, а не перестраивать всю компанию вокруг нейросети

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

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

Демо и промышленная эксплуатация – это две разные работы

Здесь важно вовремя испортить праздник

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

Потом приходит реальный заказчик

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

И выясняется, что промышленная система – это совсем другой объем работы

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

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

Пример из практики: как растет промышленный контур

У Sminex эксперимент с локальными моделями начинался с одной RTX 5000 на 16 ГБ памяти. Затем инфраструктура выросла до узла с двумя H100, а промышленный контур – до двух H200 плюс отдельной H200 для тестирования.

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

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

Почему у автоматизаторов сейчас есть структурное преимущество

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

Это желание.

Задача начинается дальше: где именно? В каком процессе? Что сейчас делает человек? Что можно отдать машине? Какие данные для этого нужны? Как проверить результат? Куда встроить новый инструмент, чтобы он не остался красивой игрушкой в отдельной вкладке браузера?

И вот здесь навыки классической автоматизации внезапно становятся дороже, а не дешевле.

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

Модель в этой конструкции – очень мощный инструмент. Но ценность возникает не из факта наличия модели. Она возникает из правильного применения.

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

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

Что я бы сделал завтра

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

Первое – начать эксперимент

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

Второе – сразу договориться о контуре данных

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

Третье – показывать результат заказчикам

Не ждите, пока получится идеальный коробочный продукт. Если вы автоматизировали что-то для себя и это действительно работает – покажите. Очень возможно, что потребность у заказчика уже есть, просто он пока не умеет сформулировать ее на языке ИИ.

Вместо заключения

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

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

И на этом фоне резко возрастает стоимость другого ресурса – ясного человеческого намерения.

Понять, чего мы хотим. Увидеть реальную проблему. Сформулировать задачу. Отделить важное от интересного. Посмотреть на полученный результат и сказать: «Нет, это не то. Давайте еще раз, но теперь я лучше понимаю, что нужно».

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

А способность понимать, зачем ты что-то делаешь, останется.

И, похоже, теперь она становится самым дорогим ресурсом.

Если возникло желание обсудить текущую ситуацию, либо попробовать Когнитум у себя – пишите!