Вайб-кодинг здорового человека: как мы научили ИИ писать код по нашим правилам

В мае 2026 складывается ощущение, что уметь писать код вручную больше не обязательно — вокруг все наперегонки хвастаются, как за выходные собрали мега-сервис, на конференциях показывают слайды про х100 к продуктивности разработчиков, а в вакансиях все чаще требуют опыт ^[1] работы с ИИ-инструментами. Вайб-кодинг победил, расходимся?

Да, для личных проектов и стартапов вайб-кодинг действительно отлично работает. Проблемы начинаются, когда подход «сделай мне как у Google» пытаются занести в продукт со серьезными требованиями и крупными клиентами. 

У нас в команде возник практический вопрос: можно ли использовать вайб-кодинг в разработке пользовательских этапов автоматизации ContentCapture, платформы интеллектуальной обработки документов? Причем использовать как полноценный инструмент, который реально сократит время на интеграции, бизнес-правила и RPA-сценарии (и не создаст новых проблем).

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

Что такое скриптовая стадия в ContentCapture и почему ее сложно автоматизировать

Для начала немного контекста: ContentCapture — это конвейер обработки документов, в котором каждый шаг (классификация, извлечение полей, валидация, экспорт) клиенты регулярно кастомизируют под себя. Помимо стандартных шагов, в продукте есть пользовательские этапы — исполняемые модули на C# с заранее заданным интерфейсом, которые запускаются в отдельном процессе. На них и строятся end-to-end автоматизации, связанные не только с задачами распознавания. Например, это могут быть интеграции с учетными системами, проверки по справочникам, выгрузки в произвольные хранилища и т.д. 

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

В свежем релизе ContentCapture появилась новая функциональность — RPA. Она тоже предполагает написание скриптов, но правила игры там другие. Контракт у RPA-модулей строгий: 

Контракт у этих модулей очень строгий:

• вход — JSON в stdin;

• выход — ровно один валидный JSON-объект в stdout;

• диагностика и логи только в stderr;

• структура данных должна соответствовать заранее описанной схеме.

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

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

Главная идея: не просить ИИ написать код, а дать ему контекст продукта

Мы решили начать с простого и навайбкодить скрипт из классической функциональности ContentCapture, который меняет регионы полей на документе (задача, которая может возникнуть при попытках добиться улучшения качества извлечения полей из документа). Закинули PDF-документ с Руководством разработчика в ИИ, но ничего не получилось: ИИ не смог учесть особенности разработки, которые очевидны/известны прикладному разработчику ContentCapture.

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

Был и более коварный класс ошибок, например, агент не знал, что в C# приложении в составе нашей платформы нужна UTF-8-кодировка в консоли. Без явных инструкций он про это просто молчал, и текст с кириллицей превращался в кашу уже на стороне платформы. Найти такое в продовых логах — отдельное удовольствие, которого мы никому не желаем. 

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

1. Содержит готовые примеры кода под два типа контекста процесса обработки: пакет и документ.

2. Включает общую библиотеку Automation.Shared с контрактами, утилитами и механизмом диагностики.

3. Предоставляет JSON.schema и реальные примеры входных данных в папке TestData.

4. Фиксирует правила разработки в AGENTS.md ^[2] — что можно, что нельзя, как логировать, как тестировать. А еще есть файл README.md ^[3], который объясняет, что такое этот репозиторий. 

   Так появилась идея AI-boilerplate (мы называем его ИИ-каркасом), который является преднастроенным репозиторием для быстрой разработки пользовательских этапов автоматизации на C# для RPA-агента:

   

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

   Как это работает на практике

   Шаг 1. Формулировка задачи

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

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

   – если текст письма содержит запрос на выдачу сертификата Озон, классифицируем его как “сертификат”

   – если текст письма содержит просьбу на оплату счета, классифицируем его как “счет”

   – если письмо не содержит ни того ни другого, классифицируем его как “другое”

   Текст письма содержится в первом документе пакета в поле FullText. Составь запрос к LLM на классификацию документа и отправь его с помощью инструмента OllamaLlmQuery.

   Результат классификации запиши в свойство пакета ClassificationResult.

   Выше — фрагмент подобного промпта. В таком запросе явно зафиксированы тип этапа и бизнес-цель.

   Шаг 2. Генерация, проверка, итерация

   Дальше агент генерирует код по заданному промпту и сам же его прогоняет:

   • проверяет, что проект компилируется;

   • запускает модульные и интеграционные тесты;

   • сверяет выходной JSON со схемой.

   Здесь критически важна диагностика. В AGENTS.md ^[2] мы заранее прописали требование: подробное логирование в stderr должно быть с самого начала, а не судорожно добавляться, когда что-то сломается. 

   Когда что-то падает, текст ошибки ^[4] уходит обратно в чат, агент анализирует и предлагает фикс. Цикл «ошибка — фидбек — новая версия» сам по себе всегда был достаточно быстрым, но раньше каждая такая итерация требовала от разработчика вникнуть в лог, доработать код и заново запустить скрипт. Теперь это делает агент, а человек подключается только к нетривиальным случаям.

   Шаг 3. Интеграция

   Готовый этап выкладывается в Git-репозиторий или сетевую папку, подключается в ContentCapture как «Этап RPA-агента», и на этом разработка заканчивается. Дальше запускается обычный продуктовый цикл: тестовая среда, ревью, прод.

   Тут мы создали для себя полезный архитектурный прием: если какая-то логика ^[5] повторяется между проектами (типовая интеграция с учетной системой, проверка контрагента, выгрузка в хранилище), ее можно вынести в отдельный репозиторий и подключать на конкретных стадиях как переиспользуемый компонент. Получаются библиотеки RPA-стадий без копипаста между проектами. 

   Технические нюансы, о которых стоит знать

   Тесты должны быть обязательной частью контракта. Каркас заставляет агента генерировать не только бизнес-логику, но и модульные тесты на методы плюс интеграционный тест, который подает JSON в stdin и проверяет stdout. 

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

   Отладка на реальных данных. В TestData лежат примеры реальных входных JSON, локальная отладка на которых вылавливает проблемы до того, как этап доедет до встраивания в ContentCapture.

   Результаты 

   • Скорость разработки. Корректно замерить ускорение мы не можем, так как классические скрипты и скрипты для RPA-фичи делались в разных условиях. Но качественно эффект очевиден: разработчик тратит время не на чтение документации, изучение внутренних API и написание обвязки, а только на формулировку бизнес-логики. Все остальное берет на себя ИИ-каркас. 

   • Гибкость. ИИ-каркас не завязан на конкретную задачу. Если, например, нужно работать не с Excel, а с СЭД, меняется бизнес-логика, а правила разработки, примеры кода и др.  взаимодействия остаются прежними.

   • Качество. Шаблоны тестов и явные правила резко сокращают количество забытых краевых случаев. Ошибки контракта (невалидный JSON, неправильный тип поля) ловятся на этапе генерации, а не тестировщиками.

   • Стоимость. Расход токенов на одну стадию составляет порядка $10–20 при использовании топовых моделей. В пилоте мы работали с Claude Opus, но на с частью задач справлялись и более легкие модели. Для сравнения: час работы senior C#-разработчика стоит в 2–3 раза дороже, а часов на такую задачу уходит явно больше одного.

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

   А что с моделями и средой разработки?

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

   Архитектура ИИ-каркаса при этом изначально не привязана к конкретному провайдеру. 

   Что мы видим по средам: Cursor сейчас де-факто стандарт для агентного программирования (минимальная подписка — $20/мес), но AGENTS.md ^[2] корректно понимают и Claude Code, и Cline, и другие открытые среды. У нашего ИИ-каркаса нет привязки к конкретной среде, он работает там, где работает ваш агент. 

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

   • Топовые западные модели (Claude, GPT) дают самый стабильный результат, но не всем подходят из-за необходимости решать вопросы с передачей данных и оплатой.

   • Китайские открытые модели (GLM, DeepSeek) показывают реально хорошее качество кода на C#, не под санкциями, их можно поднять локально.

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

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

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

   Что будем делать дальше

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

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

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

——————————————————————-

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

Наш Telegram-канал со всеми новостями: https://t.me/content_ai ^[6]