Привет, Хабр. На связи Александр Сахаров, директор по работе с партнерами компании «Диасофт». Про вайб-кодинг сейчас говорят так, будто индустрия уже все решила. Спойлер: не решила. Из всех разговоров осели три самых громких тезиса, и каждый при ближайшем рассмотрении ломается в конкретной точке.
Первый. Хороший промпт, и у вас в кармане готовое приложение на миллион долларов. Второй: ИИ заменяет тестировщиков, девопсов и заодно полкоманды, как у Microsoft. Ну и третий: GenAI добил лоу-код, и любой разработчик с LLM теперь пишет микросервисы быстрее, чище и без боли.
Я попросил коллег, у которых вайб-кодинг идет в боевых проектах, показать на пальцах, как все это работает на самом деле. По ходу разговора мы встретим Claude Opus 4.6, который снес у одной компании весь прод вместе с бэкапами; директора завода, в одиночку собирающего себе MES-систему через чат; студентов с завайбкоженными дипломами без единого знания и ширму ИИ-увольнений в Microsoft. И отдельно зацепили тему импортозамещения ИИ в России. И если кто-то еще верит в чудо сразу скажу — свой Anthropic (в смысле стартап с крутыми ИИ) мы уже не сделаем
Кому лень читать лонгрид, полная запись беседы лежит на Youtube. Спорить и задавать свои вопросы приходите в Telegram-канал Департамент разработки, где собирается сообщество разработчиков.
Достаточно хорошего промпта?
Юрий Прозоров, Product Engineering Lead: «У нас довольно тесная связка бизнеса и разработки, есть несколько внутренних продуктов. С одной стороны, код в последних моделях стал сильно лучше: агент часто пишет быстрее живого человека и довольно качественно, плюс с ним можно посоветоваться, когда упираешься в что-то новое. Но у меня есть пример с двумя параллельными сервисами в компании. Первый — это репозиторий, который мы специально готовили под ИИ: прописали миллиарды правил, спроектировали окружение так, чтобы агент работал в заданных рамках. Там код выходит уровня почти production-ready. С небольшим контролем мы готовы выпускать его в продакшн и понимаем, что и как сделано. Второй репозиторий под ИИ не подготовлен, и за кодом, который пишет любой агент, приходится сильно присматривать. Решения чаще усугубляют помойку внутри кода, чем приносят пользу, ускорение и ценность, которорые мы ждем, там минимальные. Так что AI-кодинг сильно помогает и ускоряет, но для этого нужна архитектурная подготовка того места, куда мы его пускаем».
Иван Иванов, «Апрель Инновации»: «Активно внедряем и используем у себя. Хорошую отдачу подход дает там, где нужен быстрый MVP: грязный, на коленке, но здесь и сейчас. Мы занимаемся заказной разработкой, и часто заказчику нужно быстро показать, в каком направлении пойдет продукт. После этого все равно нужно взять время и допилить решение до промышленного уровня. И здесь критично, чтобы это было в руках профессионалов, которые давно с разработкой на «ты», понимающих, как выстраивать архитектуру и правильно оценивать предложения ИИ в архитектурном плане. Дальше обязательное ревью и информбезопасность. В целом ИИ ускоряет рабоу сильно, но без специалистов с хорошим бэкграундом инструмент еще достаточно сырой».

Роман Кислицин, генеральный директор «Астарус»: «У нас несколько проектов, и ИИ мы стараемся применять на всех. Разработчики работают в Cursor со всеми доступными моделями. Опыт такой: кодинг действительно ускоряется, все стало сильно быстрее, но с оговорками. Архитектура приложения остается под контролем разработчиков, они постоянно проверяют, что выдает агент. Плюс мы проверяем сгенерированный код на уязвимости. Тестирование пока не отдаем ИИ, но в планах это есть».
Как карточный домик, красиво пока не дойдет до сборки
Иван Иванов: «У меня был пример с коллегой, который писал приложения, до этого вообще не занимаясь разработкой. Как говорится, взял и завайбкодил. Все было хорошо, пока он писал отдельные элементы. Система была достаточно сложная. Когда он начал собирать все целиком, все развалилось. Как карточный домик. И он сам признал: не хватает бэкграунда, не хватает знаний и понимания, как вообще строится разработка продуктов. Если в вайбкодинг заходит человек, у которого есть хотя бы минимальное представление о процессах, риски сильно сокращаются, и результат скорее всего будет приемлемым. Но даже в этом случае есть опасения по поводу стилистики и качества. Чтобы получить качественный стиль надо озадачивать агента. А для этого нужна экспертиза в отрасли. Модели еще не настолько хороши, чтобы просто переходить от идеи к реализации коммерческого продукта».
Александр Сахаров, директор по партнерствам «Диасофт»: «Голый Cursor или похожая система с простым системным промптом приводит ровно к таким сценариям с развалом на сборке. Мы поэтому трансформируем платформу, не нарушая бизнес-процесс производства: он остается тем же, со всеми этапами контроля зрелости и безопасности. Сидит начальник производства и пишет себе, например, систему документооборота или цепочку поставок. Он общается с агентом, дальше другие агенты раскладывают все написанное на стандартные артефакты: модель бизнес-процесса, модель архитектуры, свойства данных, документацию. Запускаются процессы, которые должны запускаться по регламенту безопасной разработки, прорабатывается модель угроз. Отдельный оператор сверяет агентов друг с другом: чтобы артефакты не противоречили друг другу и чтобы то, что нарисовано, действительно выполнялось. Получается полностью управляемый кокпит. Директор завода имеет ровно тот опыт, который он хочет, общается со своим агентом. Но при этом весь процесс разработки сохранен, все артефакты сохранены, можно открыть, посмотреть, запустить любую проверку. Все в едином контексте и интерфейсе, там же девопс, там же проверки безопасности. Недавно я сам собрал кликабельный прототип на 13 000 строк HTML за пять минут. Руками делал бы неделю».

Алексей Любко: «С одной стороны, нужны ограничения для творческого хаоса. Иначе ИИ начинает выбирать фреймворки, которые потом трудно сочетать между собой — просто потому, что “умеет” с ними работать.
Сейчас у нас есть клиент — владелец завода во Франции, человек вообще не из разработки. Ему понадобилась MES-система. Он придумал её сам, а мы помогли запустить всё на базе нашей архитектуры: задали ограничения, настроили агентов и сам процесс вайб-кодинга. В итоге директор завода сидит и делает себе MES, а мы периодически проводим ревью качества и временами хватаемся за голову. Но это уже совершенно другой подход к разработке. На предприятиях всегда есть люди, которым нужен результат, а путь через классическое ТЗ — дорого и мучительно. Сейчас порог входа в автоматизацию рухнул: когда директор может сам автоматизировать работу с 1С и счетами — это выглядит почти как магия. На этом конкретном заводе всё упёрлось в базу данных: нет нормальных индексов, нет пейджинга. Пока заказов мало — система держится. Но как только растёт нагрузка, всё начинает разваливаться. И решается это зачастую элементарно: нужен человек, который придёт и скажет, где добавить ограничения и какую базу использовать. Знания всё равно задают рамку. С другой стороны, низкий порог входа уже сделал своё дело. Моему ребёнку восемь лет — он часами сидит в Qwen и пишет себе игры. Мы убрали с телефона готовые игрушки, открыли Qwen и показали, что можно создавать свои. Теперь у него и авиасимулятор, и мультиплеер на два джойстика. Даже учитель в школе это отметил. И это действительно магия».
Чем больше кода пишет агент, тем меньше контроля
Иван Иванов: «Не совсем понятно, что принципиально нового в этом подходе. По сути, это стандартная сегодня мультиагентская схема: набор агентов взаимодействует между собой и движется по заданному процессу. Вопрос не в этом, а в том, какой код получится на выходе. Кто его проверял? Кто берет на себя ответственность за риски, которые возникают при такой модели? В конечном итоге отвечает потребитель — тот, кто купил продукт и поверил, что все будет работать как надо».
Александр Сахаров: «Тут давно все сказано: доверяй, но проверяй. Огромное количество тестовых агентов тестируют буквально все подряд: уязвимости, некорректные вызовы, обращение не к тем библиотекам, обратную совместимость, соответствие тому, что нарисовано в архитектурных артефактах. У меня в Альфа-Банке было 400 команд разработки. Кто смотрит этот код? Тот же вопрос для любого крупного банка, где код генерируют пять тысяч человек, из которых половина аутсорсеры. Ответ один: смотрит процесс РБПО. На каждом этапе стоят свои модели угроз, эти модели угроз проверяются. Вот кто смотрит».
Юрий Прозоров: «Никто не застрахован от того, что наши доблестные люди пойдут, посмотрят и продолбают ровно ту же уязвимость, что и агент. Это такой же вопрос доверия: насколько мы доверяем команде, что они на 100% найдут все, чего не найдет агент?».
Алексей Любко: «Сейчас в чатах MVP с Microsoft обсуждают показательный случай. Новый Claude Opus 4.6 у компании Pocket OS фактически снес всю базу вместе с бэкапами — просто потому, что резервные копии хранились в том же тенанте.
Во время отладки агент не нашел ключи доступа к тестовой среде, полез по файлам, обнаружил токен — и оказалось, что это доступ к продакшену. В итоге он удалил все. Когда у агента спросили, что произошло, ответ был предельно прямой: “I fucked up honestly”. Я по основной специальности безопасник, и в безопасности есть четкое разделение. Есть инженерная безопасность, где действительно интересно разбираться в технологиях, а есть бумажная — где главная задача состоит в том, чтобы правильно распределить и зафиксировать ответственность. С ИИ сейчас происходит примерно то же самое: все, что он делает, нужно проверять. Но когда смотришь на крупные российские и западные компании и на объемы кода, которые там уже генерируются, становится очевидно: разработчики физически не успевают все это полноценно анализировать. Часто просто нет времени глубоко вникать.
У нас уже выстроено несколько уровней code review, отдельно работает security review, и даже при этом иногда проскакивают неожиданные вещи. Не критичные, но все же проскакивают. И самое тревожное здесь в том, что безопасность стала недетерминированной. При этом уровень риска зависит от масштаба системы. Если речь идет о платформе на сотни тысяч пользователей — это одна категория ответственности. Если же это внутреннее приложение для производства на 500 человек, риски совсем другие. В худшем случае предприятие временно вернется к бумажным процессам, как работало раньше, и это уже не выглядит катастрофой».

Microsoft прикрывается ИИ
Алексей Любко: «Мы заменяем не людей на ИИ, а людей, которые ИИ не используют. Это сразу видно по эффективности: по скорости работы, по реакции, по качеству результата. С громкими увольнениями та же история. Microsoft, например, регулярно сокращает сотрудников в июне — к концу финансового года. В прошлом или позапрошлом году вышли заголовки о том, что компания уволила сотню человек из-за внедрения ИИ. Но если посмотреть статистику, примерно столько же потом и наняли обратно, может, чуть меньше. Просто раз в истории фигурирует ИИ, значит, все автоматически связывают именно с ним. Хотя причина может быть куда прозаичнее: закончился финансовый год, люди получили бонусы и ушли».
Роман Кислицин: «Во многом это красивая ширма для сокращения издержек. Главная ответственность никуда не исчезает — она по-прежнему остается на людях. Просто для компании это удобная формулировка: можно не говорить напрямую, что речь идет о сокращении расходов».
Юрий Прозоров: «По скорости разработки и time-to-market почти всегда видно, используют разработчики ИИ или нет. В какой-то момент это даже не нужно спрашивать — разница становится очевидной сама собой. Есть два одинаково сильных разработчика, которые раньше шли практически вровень. Один начал активно использовать ИИ — и теперь делает заметно больше и быстрее, чем тот, кто продолжает работать по-старому».
Иван Иванов: «Я думаю, потребность в людях, наоборот, вырастет. Просто изменится качество специалиста, которое требуется рынку. Раньше без джунов было сложно обойтись по экономическим причинам. Сейчас сеньор с хорошим набором ИИ-инструментов способен заменить целую команду начинающих разработчиков. Это позволяет брать больше проектов и резко повышать производительность. Другое дело, что сам рынок сейчас находится в сложном состоянии, и это тоже создает ограничения».
Откуда брать сеньоров через пять лет
Цикл прост: сеньоры с агентами вытесняют джунов. Только сеньоры тоже когда-то были джунами.
Иван Иванов: «Недавно смотрел стэнфордский курс по ИИ. На одной из первых лекций преподаватель приводил пример: мы начинали с перфокарт, потом появился ассемблер, потом появился КОБОЛ. И тогда все восклицали: вау, у нас есть КОБОЛ, теперь программировать научится каждый дворник и программисты станут не нужны. То есть это всего лишь еще один инструмент, еще один виток. Хуже всего сейчас советовать тем, кто только думает идти в разработку, что азы не нужны. Азы нужны, это никуда не денется. Останутся и процессы, и подходы. Просто появился новый инструмент, который значительно ускоряет производство конечного продукта. При этом полностью заменить им людей не получится. От джунов, которые иногда пишут такой же странный спагетти-код, как ИИ, конечно, можно уйти. Но без сеньоров не обойтись».
Алексей Любко: «Сейчас студенты массово используют вайб-кодинг и для учебы, и для дипломов. Ко мне регулярно обращаются: помочь устроиться на работу, что-то подсказать. И я вижу откат: они активно вайбкодят, а потом говорят, мол я понимаю, что я ничего не понимаю. Пытаются учить заново. Вуз эту ситуацию проверить не может: задачу закрыли, диплом написали, формально все сдано. А качество знаний сильно сыпется. Люди научились делать это быстро, чужими внешними мозгами, чужой внешней памятью. Я не соглашусь, что джуны за счет Claude Code легко освоят азы. Скорее наоборот, быстро поймали вау-эффект, обломали зубы и теперь пытаются это наверстать, работая параллельно в кафе. Потому что деньги нужны, а устроиться на нормальную работу с такими знаниями нереально».
«Неконтролируемые» очаги использования ИИ
Алексей Любко: «Недавно мы проводили исследование по внедрению ИИ, и там очень хорошо виден тренд снизу — история уже состоялась. Сверху все говорят, что компании нужен ИИ, приходят запросы на аудит, стратегии, какие-то концепции. Но реальное внедрение идет именно снизу. Из-за этого возникают серьезные проблемы с безопасностью. Люди загружают документы, не всегда корректно используют ИИ для корпоративных задач. Кто-то говорит: “Мне потом самому разбираться с этим кодом, проще написать вручную”. И так говорят даже не тестировщики, а разработчики. Особенно те, кто постарше и привык работать по-своему. Для личных задач они ИИ используют охотно, здесь сопротивления почти нет. А вот в рабочих процессах долгое время вовлеченность была заметно ниже. Когда начали ставить конкретные задачи внутри их специализации, дело сдвинулось. Но сопротивление все равно остается».

Юрий Прозоров: «Самое опасное — когда в большой компании стихийно возникают очаги использования ИИ, которые никто не контролирует. Хотя, с другой стороны, хорошо уже то, что людям это вообще интересно. Нужен человек, который сможет собрать все это воедино, превратить в понятный фреймворк и рабочий процесс. Иначе очень быстро появятся сотни спагетти-кодов, начнутся проблемы с безопасностью, а системы будут ломаться просто потому, что все решили вайбкодить так, как им удобно. Но плохо и обратное, когда люди занимают позицию “мне и так нормально, я сам напишу код и не хочу во всем этом разбираться”».
Роман Кислицин: «У себя мы внедряем ИИ централизованно. Выделили определенное количество подписок, раздали разработчикам и смотрим на результаты. Постепенно появляются дополнительные запросы, в том числе от тех, кто изначально относился к этому скептически. У клиентов ситуация очень разная. Кто-то покупает Claude Code за свои деньги, платит по сто долларов в месяц, чтобы работать быстрее и оставаться конкурентоспособным. Кто-то втихаря поднимает на собственных серверах сервисы и внедряет их внутри компании, например для распознавания голоса. Был случай с крупной компанией, где собственник просто купил одну подписку на всех и сказал: “Пользуйтесь, автоматизируйте что-нибудь”. Пока многие находятся в режиме ожидания и скорее наблюдают, что со всем этим делать дальше».
Иван Иванов: «Когда подписка оформляется на одного человека, расходы почти не ощущаются. Но если у вас команда из 15, 20 или 50 разработчиков, которым нужны полноценные инструменты, затраты начинают расти очень быстро. Плюс практически невозможно нормально контролировать расход токенов и повторное использование запросов. В итоге увеличивается и чек, и общие издержки. Поэтому локальные модели, которые можно дообучать под свои задачи или использовать как альтернативу облачным сервисам, помогают заметно снизить стоимость и в целом расходы на вайб-кодинг».
Платформу поглощает ИИ?
Третий миф самый громкий: профессиональная разработка закрывается, любой собственник теперь сам себе платформа. Заказчики, правда, не в курсе.
Роман Кислицин: «Сейчас один из главных вопросов — остается ли место профессионалу в эпоху вайб-кодинга. В моем окружении многие предприниматели и основатели компаний уже начали использовать такие инструменты сами. Кто-то автоматизировал финансовые расчеты, кто-то — начисление зарплат, кто-то решает другие внутренние задачи. При этом клиенты, для которых мы разрабатывали системы онлайн-торговли, не отказались от профессиональной разработки и не перевели все в собственный in-house. У меня есть знакомый программист в Microsoft — там сотрудников активно заставляют использовать LLM, но команды при этом никто не распускает. Скорее формируется гибридная модель: профессиональный разработчик работает вместе с ИИ-инструментами. Поэтому место для специалистов никуда не исчезнет».

Алексей Любко: «Во время кризисов на рынок всегда выходило огромное количество 1С-разработчиков. А потом, примерно через год, к нам приходили компании с одинаковой проблемой: “У нас тут все перестало работать, сделайте что-нибудь”. С вайб-кодингом, думаю, будет похожая история. Появится большой рынок “воскрешения” систем, которые однажды сломались. А второй рынок — сделать так, чтобы они вообще не ломались, если у компании хватает здравого смысла задуматься об этом заранее».
Свой Anthropic мы не сделаем?
Иван Иванов: «У меня большие сомнения, что нам как стране удастся создать собственную модель уровня условного ChatGPT 5.2. Развитие идет по экспоненте, и разрыв слишком быстро увеличивается. То, что у нас пока делают люди, там уже делают машины. Модель пишет код, а другая модель помогает разрабатывать саму модель — это уже реальность. От этого никуда не деться: мы очень сильно отстали. И разница даже в полтора года здесь критична — такой разрыв практически невозможно нагнать. При этом проприетарные модели, скорее всего, полностью не закроют. Они останутся доступными, но станут заметно дороже. Я не удивлюсь, если через год-два подписки на Cursor или Claude Code вырастут в цене в десятки раз. На этом фоне ни GigaChat, ни тем более Алиса пока не выглядят конкурентоспособными».
Александр Сахаров: «Проприетарные модели, вероятно, будут постепенно закрываться, но это не означает, что не останется открытых моделей с достаточно высоким качеством. Подход с фреймворками как раз позволяет работать не только на самых сильных моделях. Если процесс выстроен правильно, задачи можно отдавать моделям уровнем чуть ниже — условно “минус один” или “минус два” от топовых. Фреймворк дробит работу на простые шаги и контролирует качество результата. Кроме того, далеко не все функции передаются ИИ — сам процесс остается детерминированным. Но важно понимать и другое: собственную модель мирового уровня мы как страна, скорее всего, не создадим. Я был на конференциях Яндекса, выступал у Сбера, и пока видно, что до западного рынка им очень далеко. Поэтому ставка должна быть не на попытку догнать любой ценой, а на процессы, контроль качества, верификацию и информационную безопасность. Скорее всего, нас ждет гетерогенная экосистема с большим количеством разных моделей. И если реализуется самый жесткий сценарий, когда облачные модели станут недоступны, придется переходить на локальные решения, пусть и менее качественные».
Алексей Любко: «Сбер выпустил свою систему Giga IDE. Я долго пытался получить к ней доступ, общался с ребятами внутри компании. Говорят, продукт пока сыроват, но сам шаг правильный. Из китайских моделей мы недавно тестировали Lingma — по сути это история на базе Qwen. Делали практику по LLM для бизнес-клуба. Видно, что модель в некоторых вещах слабее западных решений, но разрыв уже не выглядит радикальным. Для владельцев бизнеса этого вполне хватает, чтобы собрать прототип CRM, лендинг или Telegram-бота. Самый забавный случай был, когда ребята делали CRM для одной известной компании. Они удивились: “Откуда модель знает наших клиентов?” Оказалось, система сама сходила во внешние источники через инструменты и заполнила CRM данными. Это выглядело почти как магия».
Юрий Прозоров: «Сейчас хорошо заметен рост интереса к локальным моделям. В Азии уже есть сильные решения, на базе которых можно строить рабочие продукты. У нас, например, внутренняя платформа, не облачная. Часть функций мы уже переводим на локальные модели — в том числе потому, что хочется экономить на подписках и есть ощущение, что дальше они будут только дорожать. Небольшие задачи вполне можно отдавать более простым моделям, существенно слабее того же Opus. Если вокруг них выстроен жесткий фреймворк с ограничениями — что можно делать, а что нельзя, как писать код и как не писать — это работает достаточно эффективно. По сути, это уже становится новым стандартом, и, думаю, именно в эту сторону рынок постепенно движется».
Вайб-кодинг — да, вайб-релизинг — нет
Алексей Любко: «Все стандартно, мы бежим очень быстро по полю с граблями, очень весело и с улюлюканьем. Штука с одной стороны интересная, явно дает скорость и прирост производительности на старте. Вопрос в том, как дальше обуздать этот поток кода и идей, которые она позволяет создавать: систематизировать и привести в адекватное русло. Для критических систем все равно никто, я думаю, ответственность не будет передавать. Понимая уровень ответственности, будут идти к разработчикам».
Иван Иванов: «Классный инструмент. Внедрять повсеместно нужно с головой, обдуманно, понимая, к чему это ведет и к каким последствиям. Те, кто его игнорирует, а есть такие староверы, достаточно скоро будут вынуждены к этому обратиться. Просто к тому моменту они уже упустят время».
Роман Кислицин: «Профессионала не заменить, но и вайб-кодинг исключать не нужно. Непрофессионалы тоже будут использовать вайб-кодинг, с этим ничего не поделать. Инструмент универсальный».
Юрий Прозоров: «Вайб-кодинг — да, вайб-релизинг — нет. Если от кода зависит жизнь людей, как с ракетами или атомными электростанциями, то на данный момент скорее нет, чем да. В целом я за то, чтобы вайб-кодинг был везде, в правильном миксе с людьми. Чтобы были архитекторы, которые правильно выстроят и направят. Чтобы были сеньоры, которые помогут собрать фреймворк и направить агента. А ИИ просто даст возможность делать работу быстрее, а не заменять людей на спагетти-код».
ссылка на оригинал статьи https://habr.com/ru/articles/1042342/